From ghc-devs at haskell.org Fri Nov 1 05:06:14 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Nov 2013 05:06:14 -0000 Subject: [GHC] #8494: Warn if a pattern guard obviates all others Message-ID: <050.b38ec9352f874d8f0bd116750e0ba6ca@haskell.org> #8494: Warn if a pattern guard obviates all others -------------------------+------------------------------------------------- Reporter: | Owner: JohnWiegley | Status: new Type: | Milestone: feature request | Version: 7.6.3 Priority: | Operating System: Unknown/Multiple normal | Type of failure: Incorrect warning at Component: | compile-time Compiler | Test Case: Keywords: | Blocking: Architecture: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- The following code, when compiled with `-Wall`, gives no warnings: {{{ module Main where main :: IO () main = print $ foo (10 :: Int) where foo x | True = (20 :: Int) | x == 10 = (30 :: Int) }}} I would expect that since the pattern guard `| True` obviates the following guards, that it would warn about unreachable code. There was a bug in my code today which I tracked down to a code transposition that would have been easily spotted with such a warning. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 1 08:24:38 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Nov 2013 08:24:38 -0000 Subject: [GHC] #8493: Can't compile happy + ghc with clang's CPP In-Reply-To: <043.76042121dcfd6c3f0cfaaefb2e590cc6@haskell.org> References: <043.76042121dcfd6c3f0cfaaefb2e590cc6@haskell.org> Message-ID: <058.e006689f26fb3cad08fb5b75cad89b18@haskell.org> #8493: Can't compile happy + ghc with clang's CPP ----------------------------------------+---------------------------------- Reporter: maxs | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: libraries (other) | Version: 7.7 Resolution: | Keywords: happy clang Operating System: MacOS X | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Changes (by hvr): * keywords: happy => happy clang -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 1 08:26:11 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Nov 2013 08:26:11 -0000 Subject: [GHC] #8444: Fix CPP issue with Xcode5 in integer-simple In-Reply-To: <045.e49e40e4f84743d5cf2dca86128382ee@haskell.org> References: <045.e49e40e4f84743d5cf2dca86128382ee@haskell.org> Message-ID: <060.e9b1c4b2bc3177b12ab83c3d57553bd4@haskell.org> #8444: Fix CPP issue with Xcode5 in integer-simple -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: libraries | Version: 7.7 (other) | Keywords: clang Resolution: fixed | Architecture: Unknown/Multiple Operating System: Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: Building GHC | hour) failed | Blocked By: Test Case: | Related Tickets: Blocking: | -------------------------------------+------------------------------------- Changes (by hvr): * keywords: => clang -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 1 08:27:30 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Nov 2013 08:27:30 -0000 Subject: [GHC] #8480: ghc 7.6.3 + clang-compatibility patches In-Reply-To: <052.478dfdb0b5fabbeb361804f90f4df852@haskell.org> References: <052.478dfdb0b5fabbeb361804f90f4df852@haskell.org> Message-ID: <067.f24a5ec4d6489b188817117996f7b493@haskell.org> #8480: ghc 7.6.3 + clang-compatibility patches ----------------------------+---------------------------------------------- Reporter: | Owner: darinmorrison | Status: new Type: task | Milestone: Priority: high | Version: 7.6.3 Component: | Keywords: clang Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less than a day) Operating System: MacOS X | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Changes (by hvr): * keywords: => clang Comment: Does this address #8493 as well? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 1 08:28:44 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Nov 2013 08:28:44 -0000 Subject: [GHC] #8197: telling people how to use GHC 7.6 correctly with Xcode 5/ OS X Mavericks In-Reply-To: <045.1e967ff64efa7a75edbb04c17766d7fe@haskell.org> References: <045.1e967ff64efa7a75edbb04c17766d7fe@haskell.org> Message-ID: <060.ee0fc9b69bd373e8e11ecb5caa64e436@haskell.org> #8197: telling people how to use GHC 7.6 correctly with Xcode 5/ OS X Mavericks ---------------------------------+---------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: clang Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8480 ---------------------------------+---------------------------------- Changes (by hvr): * keywords: => clang * related: => #8480 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 1 08:30:36 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Nov 2013 08:30:36 -0000 Subject: [GHC] #8148: ./configure IGNORES --with-gcc=gcc-4.8, can't build head on os x 10.8 with xcode 5 installed In-Reply-To: <045.032fb4464ed0b18eaa99793f4a167bc4@haskell.org> References: <045.032fb4464ed0b18eaa99793f4a167bc4@haskell.org> Message-ID: <060.0e6e4a721c4ca8585703448ce1d89922@haskell.org> #8148: ./configure IGNORES --with-gcc=gcc-4.8, can't build head on os x 10.8 with xcode 5 installed ---------------------------------+---------------------------------- Reporter: carter | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: clang Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+---------------------------------- Changes (by hvr): * keywords: => clang -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 1 08:33:13 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Nov 2013 08:33:13 -0000 Subject: [GHC] #8139: ghc 7.6.3 and ghc HEAD fails to build on OS X 10.9 In-Reply-To: <052.92009bd3b6836bd26916c16cd983224b@haskell.org> References: <052.92009bd3b6836bd26916c16cd983224b@haskell.org> Message-ID: <067.a31d714ec52196e67cdd72ed0e933df2@haskell.org> #8139: ghc 7.6.3 and ghc HEAD fails to build on OS X 10.9 -------------------------------------+------------------------------------- Reporter: darinmorrison | Owner: darinmorrison Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: clang Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by hvr): * keywords: => clang -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 1 08:33:48 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Nov 2013 08:33:48 -0000 Subject: [GHC] #8445: Fix Xcode5 CPP issue with compiler/deSugar/DsBinds.lhs and compiler/utils/FastString.lhs In-Reply-To: <045.a0d4b585276ca39919916fbc7191abc1@haskell.org> References: <045.a0d4b585276ca39919916fbc7191abc1@haskell.org> Message-ID: <060.699d2ef3e189ac0e0a615d1b5be78472@haskell.org> #8445: Fix Xcode5 CPP issue with compiler/deSugar/DsBinds.lhs and compiler/utils/FastString.lhs -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: clang Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by hvr): * keywords: => clang * os: Unknown/Multiple => MacOS X * architecture: Unknown/Multiple => x86_64 (amd64) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 1 08:41:06 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Nov 2013 08:41:06 -0000 Subject: [GHC] #8494: Warn if a pattern guard obviates all others In-Reply-To: <050.b38ec9352f874d8f0bd116750e0ba6ca@haskell.org> References: <050.b38ec9352f874d8f0bd116750e0ba6ca@haskell.org> Message-ID: <065.a45e81458684e907a1255e7bb5d5e607@haskell.org> #8494: Warn if a pattern guard obviates all others -------------------------------------------------+------------------------- Reporter: JohnWiegley | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect warning at | Unknown/Multiple compile-time | Difficulty: Test Case: | Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by hvr): Are you just interested in warning for the case of a reduced constant expression (such as `True`)? Or shall the compiler warn about dead code in general as soon as it is detected (in the case above, when compiling with -O, the following guards are optimized away when looking at Core)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 1 08:46:11 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Nov 2013 08:46:11 -0000 Subject: [GHC] #8494: Warn if a pattern guard obviates all others In-Reply-To: <050.b38ec9352f874d8f0bd116750e0ba6ca@haskell.org> References: <050.b38ec9352f874d8f0bd116750e0ba6ca@haskell.org> Message-ID: <065.6e4a4a81594956a81479c84d8b0e3aa6@haskell.org> #8494: Warn if a pattern guard obviates all others -------------------------------------------------+------------------------- Reporter: JohnWiegley | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect warning at | Unknown/Multiple compile-time | Difficulty: Test Case: | Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by JohnWiegley): The ticket is only about the case of reduced constant expressions, although dead code in general would be interesting to know about. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 1 11:06:15 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Nov 2013 11:06:15 -0000 Subject: [GHC] #8495: Infinite loop when using Data.HashTable.newHint and Data.HashTable.update Message-ID: <045.55e270549b2807cd70f226c42d95a07a@haskell.org> #8495: Infinite loop when using Data.HashTable.newHint and Data.HashTable.update ------------------------------------+------------------------------------- Reporter: erszcz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.4.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- When using Data.!HashTable.newHint and Data.!HashTable.update to read a big (~1.5mln words) file into a !HashTable the program seems to fall into an infinite loop. "Seems to" since I couldn't wait long enough for it to finish computation. At least the execution time is way bigger than expected (orders of magnitude, like hours vs. expected seconds). Data.!HashTable.new doesn't cause the same issue. Attached to the report is an example program reproducing the bug along with a data file the issue occurs with. The bug was discussed on haskell-beginners mailing list quite a while ago, though I've summarized the findings in this bug report. See: - http://article.gmane.org/gmane.comp.lang.haskell.beginners/9811 - http://article.gmane.org/gmane.comp.lang.haskell.beginners/9828 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 1 11:15:12 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Nov 2013 11:15:12 -0000 Subject: [GHC] #8495: Infinite loop when using Data.HashTable.newHint and Data.HashTable.update In-Reply-To: <045.55e270549b2807cd70f226c42d95a07a@haskell.org> References: <045.55e270549b2807cd70f226c42d95a07a@haskell.org> Message-ID: <060.15f86c0dc448edee327a0a9908c61b81@haskell.org> #8495: Infinite loop when using Data.HashTable.newHint and Data.HashTable.update -------------------------------------+------------------------------------ Reporter: erszcz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by erszcz): The file size limit is too small to attach the original data file causing the problem. It's available here: https://dl.dropboxusercontent.com/u/1169871/formy.utf8.xz -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 1 12:21:08 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Nov 2013 12:21:08 -0000 Subject: [GHC] #8170: Remove _scc_ In-Reply-To: <047.7f6701e7774fc31251fca4a484c23de1@haskell.org> References: <047.7f6701e7774fc31251fca4a484c23de1@haskell.org> Message-ID: <062.6372998edcd3486c9ad6d3c51ac84d5c@haskell.org> #8170: Remove _scc_ -------------------------------------+------------------------------------ Reporter: monoidal | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Krzysztof Gogolewski ): In [changeset:"61c855803f9d4319e2394e151ddd46089192d84a/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="61c855803f9d4319e2394e151ddd46089192d84a" Remove remains of _scc_ (#8170) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 1 12:21:08 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Nov 2013 12:21:08 -0000 Subject: [GHC] #8356: Strangeness with FunDeps In-Reply-To: <042.e3202299281602befe025c334253735b@haskell.org> References: <042.e3202299281602befe025c334253735b@haskell.org> Message-ID: <057.db6283a442d6e5e5d0f6a5dfb9661281@haskell.org> #8356: Strangeness with FunDeps -------------------------------------------------+------------------------- Reporter: ksf | Owner: Type: bug | Status: Priority: normal | closed Component: Compiler | Milestone: Resolution: fixed | Version: 7.7 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple typecheck/should_fail/tcfail170 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"eaa4682b68348eb3b49a0bf2700abc58be820555/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="eaa4682b68348eb3b49a0bf2700abc58be820555" Remove debugging output (#8356) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 1 12:22:07 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Nov 2013 12:22:07 -0000 Subject: [GHC] #8492: Exception: expectJust cpeBody:collect_args In-Reply-To: <051.2f06a8a224aa407ed8a6543897052bed@haskell.org> References: <051.2f06a8a224aa407ed8a6543897052bed@haskell.org> Message-ID: <066.8f82f63f85be8382be7bee562c664825@haskell.org> #8492: Exception: expectJust cpeBody:collect_args ----------------------------------+---------------------------------- Reporter: CoreyOConnor | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"d5872bb88d77ecc579f0e2feb95a2ffcfeea9bbb/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="d5872bb88d77ecc579f0e2feb95a2ffcfeea9bbb" Test #8492 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 1 12:23:04 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Nov 2013 12:23:04 -0000 Subject: [GHC] #8492: Exception: expectJust cpeBody:collect_args In-Reply-To: <051.2f06a8a224aa407ed8a6543897052bed@haskell.org> References: <051.2f06a8a224aa407ed8a6543897052bed@haskell.org> Message-ID: <066.132fd058b8ce37b308e58f44eeb2fceb@haskell.org> #8492: Exception: expectJust cpeBody:collect_args -----------------------------------------------+--------------------------- Reporter: CoreyOConnor | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime crash | (amd64) Test Case: typecheck/should_run/T8492 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: -----------------------------------------------+--------------------------- Changes (by monoidal): * testcase: => typecheck/should_run/T8492 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 1 12:44:29 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Nov 2013 12:44:29 -0000 Subject: [GHC] #8483: Use addDependentFile in Language.Haskell.TH.Syntax.quoteFile In-Reply-To: <045.6dbb71c2d7b66ab1567be68a53026d80@haskell.org> References: <045.6dbb71c2d7b66ab1567be68a53026d80@haskell.org> Message-ID: <060.1fbead2511e16279c8ae7d0b7931d294@haskell.org> #8483: Use addDependentFile in Language.Haskell.TH.Syntax.quoteFile --------------------------------------+------------------------------------ Reporter: aavogt | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: libraries (other) | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Changes (by monoidal): * status: new => patch Comment: Hm. Generally looks good, but do you know whether there's an issue with relative paths? See http://stackoverflow.com/questions/16163948. If this is not a problem, I'll commit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 1 13:27:26 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Nov 2013 13:27:26 -0000 Subject: [GHC] #7263: Add derived Show instances to GHC.Generics In-Reply-To: <042.536f882060c165e1b057735244b60fda@haskell.org> References: <042.536f882060c165e1b057735244b60fda@haskell.org> Message-ID: <057.8e0e108822fd3ba6bb5ff2fe6664a542@haskell.org> #7263: Add derived Show instances to GHC.Generics -------------------------------------+------------------------------------ Reporter: dag | Owner: dreixel Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: GHC API | Version: 7.7 Resolution: | Keywords: generics Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by monoidal): So the main part is already pushed, and the only remaining part is possibly adding `Ord` (comment:5). Let's finish the ticket. dreixel, spl: what's the decision - do we want `Ord` for `U1` only, or for all types which got Eq/Show/Read in [219ea0e539aca217fe1819baf02d4cdd1d670f51/base], or something else? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 1 13:44:51 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Nov 2013 13:44:51 -0000 Subject: [GHC] #7263: Add derived Show instances to GHC.Generics In-Reply-To: <042.536f882060c165e1b057735244b60fda@haskell.org> References: <042.536f882060c165e1b057735244b60fda@haskell.org> Message-ID: <057.605e0b66f06e518990f43c5c4df5acd0@haskell.org> #7263: Add derived Show instances to GHC.Generics -------------------------------------+------------------------------------ Reporter: dag | Owner: dreixel Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: GHC API | Version: 7.7 Resolution: | Keywords: generics Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by dreixel): It can be added to all of them, as far as I'm concerned. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 1 14:32:12 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Nov 2013 14:32:12 -0000 Subject: [GHC] #7263: Add derived Show instances to GHC.Generics In-Reply-To: <042.536f882060c165e1b057735244b60fda@haskell.org> References: <042.536f882060c165e1b057735244b60fda@haskell.org> Message-ID: <057.9303e44569d4d8c8bf4c99ec46a857f7@haskell.org> #7263: Add derived Show instances to GHC.Generics -------------------------------------+------------------------------------ Reporter: dag | Owner: dreixel Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: GHC API | Version: 7.7 Resolution: | Keywords: generics Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Krzysztof Gogolewski ): In [changeset:"fe70999f28f0f658ba00647c1178138eeaf4462c/base"]: {{{ #!CommitTicketReference repository="base" revision="fe70999f28f0f658ba00647c1178138eeaf4462c" Add Ord instances for GHC.Generics (#7263) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 1 14:32:46 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Nov 2013 14:32:46 -0000 Subject: [GHC] #7263: Add derived Show instances to GHC.Generics In-Reply-To: <042.536f882060c165e1b057735244b60fda@haskell.org> References: <042.536f882060c165e1b057735244b60fda@haskell.org> Message-ID: <057.2bd5f48429f7e778a75121c64f4bbb19@haskell.org> #7263: Add derived Show instances to GHC.Generics -------------------------------------+------------------------------------ Reporter: dag | Owner: dreixel Type: feature request | Status: closed Priority: normal | Milestone: 7.8.1 Component: GHC API | Version: 7.7 Resolution: fixed | Keywords: generics Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by monoidal): * status: new => closed * resolution: => fixed Comment: Done. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 1 15:14:55 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Nov 2013 15:14:55 -0000 Subject: [GHC] #8496: Minor typos in STM.c Message-ID: <043.479c3df9b21c0964a84c71c3810d535d@haskell.org> #8496: Minor typos in STM.c -------------------------------------------+------------------------------- Reporter: aske | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- STM.c has a few small typos in the description. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 1 15:15:54 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Nov 2013 15:15:54 -0000 Subject: [GHC] #8496: Minor typos in STM.c In-Reply-To: <043.479c3df9b21c0964a84c71c3810d535d@haskell.org> References: <043.479c3df9b21c0964a84c71c3810d535d@haskell.org> Message-ID: <058.75c477bab3838f8182a50772b4f0b3e3@haskell.org> #8496: Minor typos in STM.c -------------------------------+------------------------------------------- Reporter: aske | Owner: aske Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by aske): * owner: => aske -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 1 15:32:06 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Nov 2013 15:32:06 -0000 Subject: [GHC] #8496: Minor typos in STM.c In-Reply-To: <043.479c3df9b21c0964a84c71c3810d535d@haskell.org> References: <043.479c3df9b21c0964a84c71c3810d535d@haskell.org> Message-ID: <058.3b360dbf6bbfc260f5566280d9272c17@haskell.org> #8496: Minor typos in STM.c -------------------------------+------------------------------------------- Reporter: aske | Owner: aske Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"d943affc9121b91bc14e3798c6a2f1a5da38aef0/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="d943affc9121b91bc14e3798c6a2f1a5da38aef0" Minor typos (fixes #8496) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 1 15:32:33 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Nov 2013 15:32:33 -0000 Subject: [GHC] #8496: Minor typos in STM.c In-Reply-To: <043.479c3df9b21c0964a84c71c3810d535d@haskell.org> References: <043.479c3df9b21c0964a84c71c3810d535d@haskell.org> Message-ID: <058.b5500f0baeb3bec41331697e6cf5eeff@haskell.org> #8496: Minor typos in STM.c -------------------------------+------------------------------------------- Reporter: aske | Owner: aske Type: bug | Status: closed Priority: lowest | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by monoidal): * status: new => closed * resolution: => fixed Comment: Applied, thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 1 15:40:52 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Nov 2013 15:40:52 -0000 Subject: [GHC] #7768: "untracked content" in fresh clone of haskeline In-Reply-To: <047.7e669fa3fa6b0d1741ee8c733abe83e7@haskell.org> References: <047.7e669fa3fa6b0d1741ee8c733abe83e7@haskell.org> Message-ID: <062.ce24112c2217e60d76f9745222edd009@haskell.org> #7768: "untracked content" in fresh clone of haskeline ---------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.7 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Changes (by judahj): * status: new => closed * resolution: => fixed Comment: It seems there was a bad import of the filenames from darcs into git. I've fixed the issue by renaming the files in git to their proper UTF-8 encoding: https://github.com/judah/haskeline/commit/6d890a6bb263999cd3967cb05c1034f66f570ecf -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 1 17:14:34 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Nov 2013 17:14:34 -0000 Subject: [GHC] #8483: Use addDependentFile in Language.Haskell.TH.Syntax.quoteFile In-Reply-To: <045.6dbb71c2d7b66ab1567be68a53026d80@haskell.org> References: <045.6dbb71c2d7b66ab1567be68a53026d80@haskell.org> Message-ID: <060.1dcc075e233c160a8911992ec96ddc49@haskell.org> #8483: Use addDependentFile in Language.Haskell.TH.Syntax.quoteFile --------------------------------------+------------------------------------ Reporter: aavogt | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: libraries (other) | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by aavogt): I think there is no problem. You get a listing of the directory you call ghc from here: {{{ {-# LANGUAGE TemplateHaskell #-} import Language.Haskell.TH import System.Cmd do runIO (system "ls") [d| () = () |] }}} If `addDependentFile` also looks relative to the path ghc is called from, then it seems like you will only have one file referenced using my patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 1 18:30:44 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Nov 2013 18:30:44 -0000 Subject: [GHC] #8480: ghc 7.6.3 + clang-compatibility patches In-Reply-To: <052.478dfdb0b5fabbeb361804f90f4df852@haskell.org> References: <052.478dfdb0b5fabbeb361804f90f4df852@haskell.org> Message-ID: <067.f6f208488222434c8988fe551e594894@haskell.org> #8480: ghc 7.6.3 + clang-compatibility patches ----------------------------+---------------------------------------------- Reporter: | Owner: darinmorrison | Status: new Type: task | Milestone: Priority: high | Version: 7.6.3 Component: | Keywords: clang Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less than a day) Operating System: MacOS X | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Comment (by carter): I don't think it addresses the CPP matters yet, theres a lot of other bits that need hammering on too. the CPP bits are in the roadmap though -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 1 23:19:18 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Nov 2013 23:19:18 -0000 Subject: [GHC] #7768: "untracked content" in fresh clone of haskeline In-Reply-To: <047.7e669fa3fa6b0d1741ee8c733abe83e7@haskell.org> References: <047.7e669fa3fa6b0d1741ee8c733abe83e7@haskell.org> Message-ID: <062.4494bb738b091c9f7bd191fd24010b6d@haskell.org> #7768: "untracked content" in fresh clone of haskeline ---------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.7 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Comment (by Herbert Valerio Riedel ): In [changeset:"c4d5289d1c6e453a07bc1240634579b09ef66632/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c4d5289d1c6e453a07bc1240634579b09ef66632" Sync up to `haskeline` upstream's HEAD This contains the Haskeline commit fixing #7768 Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 1 23:25:10 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Nov 2013 23:25:10 -0000 Subject: [GHC] #7263: Add derived Show instances to GHC.Generics In-Reply-To: <042.536f882060c165e1b057735244b60fda@haskell.org> References: <042.536f882060c165e1b057735244b60fda@haskell.org> Message-ID: <057.7adfec4176158b9c3660dac64e694279@haskell.org> #7263: Add derived Show instances to GHC.Generics -------------------------------------+------------------------------------ Reporter: dag | Owner: dreixel Type: feature request | Status: closed Priority: normal | Milestone: 7.8.1 Component: GHC API | Version: 7.7 Resolution: fixed | Keywords: generics Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by hvr): ...has a release notes entry for 7.8.1 been written yet? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 1 23:41:42 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Nov 2013 23:41:42 -0000 Subject: [GHC] #4900: DEPENDS pragma In-Reply-To: <046.52f138a2609bf72d7f5381a2c64d358e@haskell.org> References: <046.52f138a2609bf72d7f5381a2c64d358e@haskell.org> Message-ID: <061.a4444e9790d23b0742d3e4c1e8b0bcbc@haskell.org> #4900: DEPENDS pragma -------------------------------------+------------------------------------ Reporter: cdsmith | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: TH_Depends | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * cc: simonmar (added) Comment: This patch looks good to me. SimonM - if it passes your glance, then I'll merge ASAP. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 1 23:44:06 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Nov 2013 23:44:06 -0000 Subject: [GHC] #8322: Report all missing module, not just the first or last In-Reply-To: <046.b88d1a6a055419055d0d7b0e1ef0a4fe@haskell.org> References: <046.b88d1a6a055419055d0d7b0e1ef0a4fe@haskell.org> Message-ID: <061.0cc4e970bea1de2625baa2e4908e9b2d@haskell.org> #8322: Report all missing module, not just the first or last -------------------------------------+------------------------------------ Reporter: nomeata | Owner: nomeata Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by thoughtpolice): LGTM. Joachim, I'll go ahead and merge this for you. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 2 05:59:28 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Nov 2013 05:59:28 -0000 Subject: [GHC] #8497: clang/wrapper cannot build GHC head with integer-gmp on Mavericks Message-ID: <052.a945a4fdb4d0e9bf62bd4d9ed8afe8eb@haskell.org> #8497: clang/wrapper cannot build GHC head with integer-gmp on Mavericks ----------------------------------+---------------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: clang | Operating System: MacOS X Architecture: | Type of failure: Building GHC failed Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ----------------------------------+---------------------------------------- I'm using GHC 7.6.3 with clang/wrapper (setting is modified). This GHC cannot build GHC head with integer-gmp: {{{ checking for assembler byte directive... .byte checking how to define a 32-bit word... /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/nm: can't open file: conftest.o (No such file or directory) /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/nm: can't open file: conftest.o (No such file or directory) /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/nm: can't open file: conftest.o (No such file or directory) configure: error: cannot determine how to define a 32-bit word make[1]: *** [libraries/integer-gmp/gmp/gmp.h] Error 1 make: *** [all] Error 2 }}} With integer-simple, build is OK. For more information, please see http://d.hatena.ne.jp/kazu- yamamoto/20131028/1382921924 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 2 11:21:01 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Nov 2013 11:21:01 -0000 Subject: [GHC] #8497: clang/wrapper cannot build GHC head with integer-gmp on Mavericks In-Reply-To: <052.a945a4fdb4d0e9bf62bd4d9ed8afe8eb@haskell.org> References: <052.a945a4fdb4d0e9bf62bd4d9ed8afe8eb@haskell.org> Message-ID: <067.1e59b6f940e017fff57a61e6189d7181@haskell.org> #8497: clang/wrapper cannot build GHC head with integer-gmp on Mavericks ----------------------------------------+---------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: clang Operating System: MacOS X | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by hvr): could you please attach the resulting `libraries/integer-gmp/config.log` log file to this ticket? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 2 11:23:35 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Nov 2013 11:23:35 -0000 Subject: [GHC] #8305: ghci macros override built-ins for command expansion In-Reply-To: <047.fc409110f08eee40d2b732450d9304f1@haskell.org> References: <047.fc409110f08eee40d2b732450d9304f1@haskell.org> Message-ID: <062.0a3808f2b212694b512491a65a15bf40@haskell.org> #8305: ghci macros override built-ins for command expansion -------------------------------------+------------------------------------ Reporter: rwbarton | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8113 -------------------------------------+------------------------------------ Changes (by hvr): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 2 11:24:10 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Nov 2013 11:24:10 -0000 Subject: [GHC] #8497: clang/wrapper cannot build GHC head with integer-gmp on Mavericks In-Reply-To: <052.a945a4fdb4d0e9bf62bd4d9ed8afe8eb@haskell.org> References: <052.a945a4fdb4d0e9bf62bd4d9ed8afe8eb@haskell.org> Message-ID: <067.67545cb716dba331f6adfbb4d2421986@haskell.org> #8497: clang/wrapper cannot build GHC head with integer-gmp on Mavericks ----------------------------------------+---------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: clang Operating System: MacOS X | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by kazu-yamamoto): Attached. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 2 11:41:12 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Nov 2013 11:41:12 -0000 Subject: [GHC] #8156: amd64 + in-tree gmp build broken In-Reply-To: <044.8d3c89c3b747f5cbec4467ee5ef43a21@haskell.org> References: <044.8d3c89c3b747f5cbec4467ee5ef43a21@haskell.org> Message-ID: <059.485aa3039ada9f749397469462879db8@haskell.org> #8156: amd64 + in-tree gmp build broken -------------------------------------+------------------------------------- Reporter: errge | Owner: Type: bug | Status: patch Priority: low | Milestone: 7.10.1 Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: #4022 #4366 #4374 -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:7 carter]: > @Jan, LGPL is only compatible with BSD when we dynamically link it, statically linked LGPL forces the rest of the project (allegedly) to be GPL, which is incompatible with a parent project that is BSD, at least according to the FSF's overly aggressive reading of (L)GPL. ...are you sure? Can you provide examples where the FSF used "overly agressive reading of the LGPL"? Afaik, simply stated, the LGPL just requires you to provide some mechanism (using dynamic linking is the most common way to achieve this) to allow ppl to replace the linked LGPL'ed library with a modified version. It does not force you to release or relicense the source code of the non-LGPLed components you used for the combined work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 2 11:54:10 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Nov 2013 11:54:10 -0000 Subject: [GHC] #8497: clang/wrapper cannot build GHC head with integer-gmp on Mavericks In-Reply-To: <052.a945a4fdb4d0e9bf62bd4d9ed8afe8eb@haskell.org> References: <052.a945a4fdb4d0e9bf62bd4d9ed8afe8eb@haskell.org> Message-ID: <067.56c63712bc45e80ca461e01178e91fe1@haskell.org> #8497: clang/wrapper cannot build GHC head with integer-gmp on Mavericks ----------------------------------------+---------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: clang Operating System: MacOS X | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by hvr): Ah, now I see.. that error is generated by the GMP source code included in the tarball; could you try installing a GMP library (or is that called Framework in OSX?) in your Xcode environment, so GHC doesn't have to compile its own GMP library? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 2 20:58:20 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Nov 2013 20:58:20 -0000 Subject: [GHC] #8322: Report all missing module, not just the first or last In-Reply-To: <046.b88d1a6a055419055d0d7b0e1ef0a4fe@haskell.org> References: <046.b88d1a6a055419055d0d7b0e1ef0a4fe@haskell.org> Message-ID: <061.bd95fab56999a0729c2cffc2663b2ad3@haskell.org> #8322: Report all missing module, not just the first or last -------------------------------------+------------------------------------ Reporter: nomeata | Owner: nomeata Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Austin Seipp ): In [changeset:"63b8147f01bd7bd4a46fb013998f138bce3139be/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="63b8147f01bd7bd4a46fb013998f138bce3139be" Load all modules before reporting errors (#8322) Instead of reporting only one "module not found"" error. Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 2 20:58:21 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Nov 2013 20:58:21 -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.1e61f689a017a4ba8d252dd2484aab36@haskell.org> #1480: Template Haskell should allow reification of modules ----------------------------+---------------------------------------------- Reporter: igloo | Owner: Type: feature | Status: patch request | Milestone: 7.8.1 Priority: highest | Version: 7.7 Component: | Keywords: Template Haskell | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less than a day) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: 8398 | ----------------------------+---------------------------------------------- Comment (by Austin Seipp ): In [changeset:"69fa2e558d56178d33950df815c3233606b0d44e/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="69fa2e558d56178d33950df815c3233606b0d44e" Add support for module reification (#1480) Authored-by: Gergely Risko Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 2 20:58:21 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Nov 2013 20:58:21 -0000 Subject: [GHC] #8453: segfault/assertion failure with multi-threaded profiling In-Reply-To: <043.88830003a4aab2e0f30d4506087b121b@haskell.org> References: <043.88830003a4aab2e0f30d4506087b121b@haskell.org> Message-ID: <058.8518957d1dd20f4dd0364087f6cf8f42@haskell.org> #8453: segfault/assertion failure with multi-threaded profiling ----------------------------------+---------------------------------- Reporter: akio | Owner: akio Type: bug | Status: patch Priority: normal | Milestone: Component: Profiling | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: 8402 Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by Austin Seipp ): In [changeset:"1082f21b1eaf7b380daefb864959e6cfad1aeec7/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="1082f21b1eaf7b380daefb864959e6cfad1aeec7" Fix a race condition when PROFILING (#8453) Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 2 20:58:22 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Nov 2013 20:58:22 -0000 Subject: [GHC] #8134: ghc enters a loop while building 7.6.3 for powerpc64 platform. In-Reply-To: <043.0289be94f89f3f22e5a1a6cc61dcce1b@haskell.org> References: <043.0289be94f89f3f22e5a1a6cc61dcce1b@haskell.org> Message-ID: <058.e6e92c152464c54ca5273ec934840090@haskell.org> #8134: ghc enters a loop while building 7.6.3 for powerpc64 platform. -------------------------------------+----------------------------- Reporter: k0da | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.6.3 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+----------------------------- Comment (by Austin Seipp ): In [changeset:"a4b1a43542b11d09dd3b603d82c5a0e99da67d74/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a4b1a43542b11d09dd3b603d82c5a0e99da67d74" Fix loop on 64bit Big-Endian platforms (#8134) This is a fun one. In the RTS, `cas` expects a pointer to StgWord which will translate to unsigned long (8 bytes under LP64.) But we had previously declared token_locked as *StgBool* - which evaluates to 'int' (4 bytes under LP64.) That means we fail to provide enough storage for the cas primitive, causing it to corrupt memory on a 64bit platform. Hilariously, this somehow did not affect little-endian platforms (ARM, x86, etc) before. That's because to clear our lock token, we would say: token_locked = 0; But because token_locked is 32bits technically, this only writes to half of the 64bit quantity. On a Big-Endian machine, this won't do anything. That is, token_locked starts as 0: / token_locked | v 0x00000000 and the first cas modifies the memory to: / valid / corrupted | | v v 0x00000000 0x00000001 We then clear token_locked, but this doesn't change the corrupted 4 bytes of memory. And then we try to lock the token again, spinning until it is released - clearly a deadlock. Related: Windows (amd64) doesn't follow LP64, but LLP64, where both int and long are 4 bytes, so this shouldn't change anything on these platforms. Thanks to Reid Barton for helping the diagnosis. Also, thanks to Jens Peterson who confirmed this also fixes building GHC on Fedora/ppc64 and Fedora/s390x. Authored-by: Gustavo Luiz Duarte Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 2 20:58:22 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Nov 2013 20:58:22 -0000 Subject: [GHC] #7753: Profiling report broken with foreign exported functions In-Reply-To: <043.cdad128df5cc1da6704a1d6046e471a1@haskell.org> References: <043.cdad128df5cc1da6704a1d6046e471a1@haskell.org> Message-ID: <058.7354158df41c49bf4651e2409b440a3a@haskell.org> #7753: Profiling report broken with foreign exported functions ---------------------------------+------------------------------------ Reporter: akio | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Profiling | Version: 7.6.2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Comment (by Austin Seipp ): In [changeset:"773365f91ff141ad38e929844c901ecd5465a000/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="773365f91ff141ad38e929844c901ecd5465a000" rts_apply uses CCS_MAIN rather than CCS_SYSTEM (#7753) Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 2 20:58:28 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Nov 2013 20:58:28 -0000 Subject: [GHC] #8322: Report all missing module, not just the first or last In-Reply-To: <046.b88d1a6a055419055d0d7b0e1ef0a4fe@haskell.org> References: <046.b88d1a6a055419055d0d7b0e1ef0a4fe@haskell.org> Message-ID: <061.f60f2146aed074cf68d944727a8409ea@haskell.org> #8322: Report all missing module, not just the first or last -------------------------------------+------------------------------------ Reporter: nomeata | Owner: nomeata Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Austin Seipp ): In [changeset:"88fd25a6085c10ec769ebd2e0b8abc0630817516/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="88fd25a6085c10ec769ebd2e0b8abc0630817516" Update tcfail082 output (#8322 fallout) Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 2 21:00:26 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Nov 2013 21:00:26 -0000 Subject: [GHC] #8256: adding locality levels to prefetch# and friends In-Reply-To: <045.bc455c21650626f3242606c828908318@haskell.org> References: <045.bc455c21650626f3242606c828908318@haskell.org> Message-ID: <060.79dcc6bce69924c0550ef0933da6c0de@haskell.org> #8256: adding locality levels to prefetch# and friends -------------------------------------+------------------------------------ Reporter: carter | Owner: carter Type: task | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8252 ,#8107 -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: The documentation patch is now merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 2 21:01:02 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Nov 2013 21:01:02 -0000 Subject: [GHC] #8322: Report all missing module, not just the first or last In-Reply-To: <046.b88d1a6a055419055d0d7b0e1ef0a4fe@haskell.org> References: <046.b88d1a6a055419055d0d7b0e1ef0a4fe@haskell.org> Message-ID: <061.35f1838b133a60965d7810a0ff23cdcc@haskell.org> #8322: Report all missing module, not just the first or last -------------------------------------+------------------------------------ Reporter: nomeata | Owner: nomeata Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged, thanks Joachim! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 2 21:01:48 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Nov 2013 21:01:48 -0000 Subject: [GHC] #8453: segfault/assertion failure with multi-threaded profiling In-Reply-To: <043.88830003a4aab2e0f30d4506087b121b@haskell.org> References: <043.88830003a4aab2e0f30d4506087b121b@haskell.org> Message-ID: <058.2dda6d5e7d6b12931705e5d67869c73f@haskell.org> #8453: segfault/assertion failure with multi-threaded profiling ----------------------------------+---------------------------------- Reporter: akio | Owner: akio Type: bug | Status: patch Priority: normal | Milestone: Component: Profiling | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: 8402 Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by thoughtpolice): Confirmed bug and that the patch fixes it - excellent work Takano, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 2 21:02:10 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Nov 2013 21:02:10 -0000 Subject: [GHC] #8134: ghc enters a loop while building 7.6.3 for powerpc64 platform. In-Reply-To: <043.0289be94f89f3f22e5a1a6cc61dcce1b@haskell.org> References: <043.0289be94f89f3f22e5a1a6cc61dcce1b@haskell.org> Message-ID: <058.f7a43e2fd93fe25414573f44870ec947@haskell.org> #8134: ghc enters a loop while building 7.6.3 for powerpc64 platform. -------------------------------------+----------------------------- Reporter: k0da | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.6.3 Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+----------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged - thanks everyone! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 2 21:02:39 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Nov 2013 21:02:39 -0000 Subject: [GHC] #7753: Profiling report broken with foreign exported functions In-Reply-To: <043.cdad128df5cc1da6704a1d6046e471a1@haskell.org> References: <043.cdad128df5cc1da6704a1d6046e471a1@haskell.org> Message-ID: <058.87bec74812e3715366be06936c19104c@haskell.org> #7753: Profiling report broken with foreign exported functions ---------------------------------+------------------------------------ Reporter: akio | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Profiling | Version: 7.6.2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Comment (by thoughtpolice): Merged, thank you Takano! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 2 21:02:53 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Nov 2013 21:02:53 -0000 Subject: [GHC] #7753: Profiling report broken with foreign exported functions In-Reply-To: <043.cdad128df5cc1da6704a1d6046e471a1@haskell.org> References: <043.cdad128df5cc1da6704a1d6046e471a1@haskell.org> Message-ID: <058.0c06e301d9670a64f68fdfa53d0f124d@haskell.org> #7753: Profiling report broken with foreign exported functions ---------------------------------+------------------------------------ Reporter: akio | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Profiling | Version: 7.6.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 2 21:03:07 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Nov 2013 21:03:07 -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.130d0800e778b100d781fdcd90c2d59a@haskell.org> #1480: Template Haskell should allow reification of modules ----------------------------+---------------------------------------------- Reporter: igloo | Owner: Type: feature | Status: closed request | Milestone: 7.8.1 Priority: highest | Version: 7.7 Component: | Keywords: Template Haskell | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Moderate (less than a day) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: 8398 | ----------------------------+---------------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 2 21:14:09 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Nov 2013 21:14:09 -0000 Subject: [GHC] #8256: adding locality levels to prefetch# and friends In-Reply-To: <045.bc455c21650626f3242606c828908318@haskell.org> References: <045.bc455c21650626f3242606c828908318@haskell.org> Message-ID: <060.0fc0b5b8cf2ad652acaf8a417fafd93d@haskell.org> #8256: adding locality levels to prefetch# and friends -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: task | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8252 ,#8107 -------------------------------------+------------------------------------ Changes (by carter): * owner: carter => * status: closed => new * resolution: fixed => Comment: urk, forgot to push the additional cleanup using the feedback simon had: I'll push that commit onto my prefetch-docs branch again in a moment. https://github.com/cartazio/ghc/compare/prefetch-docs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 2 21:48:59 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Nov 2013 21:48:59 -0000 Subject: [GHC] #8497: clang/wrapper cannot build GHC head with integer-gmp on Mavericks In-Reply-To: <052.a945a4fdb4d0e9bf62bd4d9ed8afe8eb@haskell.org> References: <052.a945a4fdb4d0e9bf62bd4d9ed8afe8eb@haskell.org> Message-ID: <067.324f669869552eba29b2a10a63be7c6a@haskell.org> #8497: clang/wrapper cannot build GHC head with integer-gmp on Mavericks ----------------------------------------+---------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: clang Operating System: MacOS X | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by kazu-yamamoto): I installed GMP by MacPorts and did: {{{ % ./configure --prefix=/ghc-head --with-gmp-includes=/opt/local/include --with-gmp-libraries=/opt/local/lib % make }}} I got the following error this time: {{{ inplace/bin/dll-split compiler/stage2/build/.depend-v-p-dyn.haskell "DynFlags" " Annotations Avail Bag BasicTypes BinIface Binary Bitmap BlockId BooleanFormula B reakArray BufWrite BuildTyCl ByteCodeAsm ByteCodeInstr ByteCodeItbls CLabel Clas s CmdLineParser Cmm CmmCallConv CmmExpr CmmInfo CmmMachOp CmmNode CmmType CmmUti ls CoAxiom CodeGen.Platform CodeGen.Platform.ARM CodeGen.Platform.NoRegs CodeGen .Platform.PPC CodeGen.Platform.PPC_Darwin CodeGen.Platform.SPARC CodeGen.Platfor m.X86 CodeGen.Platform.X86_64 Coercion Config Constants CoreArity CoreFVs CoreLi nt CoreSubst CoreSyn CoreTidy CoreUnfold CoreUtils CostCentre DataCon Demand Dig raph DriverPhases DsMonad DynFlags Encoding ErrUtils Exception ExtsCompat46 FamI nst FamInstEnv FastBool FastFunctions FastMutInt FastString FastTypes Finder Fin gerprint FiniteMap ForeignCall Hooks Hoopl Hoopl.Dataflow HsBinds HsDecls HsDoc HsExpr HsImpExp HsLit HsPat HsSyn HsTypes HsUtils HscTypes IOEnv Id IdInfo Iface Env IfaceSyn IfaceType InstEnv InteractiveEvalTypes Kind ListSetOps Literal Load Iface Maybes MkCore MkGraph MkId Module MonadUtils Name NameEnv NameSet OccName OccurAnal OptCoercion OrdList Outputable PackageConfig Packages Pair Panic Pipel ineMonad Platform PlatformConstants PprCmm PprCmmDecl PprCmmExpr PprCore PrelInf o PrelNames PrelRules Pretty PrimOp RdrName Reg RegClass Rules SMRep Serialized SrcLoc StaticFlags StgCmmArgRep StgCmmClosure StgCmmEnv StgCmmLayout StgCmmMonad StgCmmProf StgCmmTicky StgCmmUtils StgSyn Stream StringBuffer TcEvidence TcIfac e TcMType TcRnMonad TcRnTypes TcType TcTypeNats TrieMap TyCon Type TypeRep TysPr im TysWiredIn Unify UniqFM UniqSet UniqSupply Unique Util Var VarEnv VarSet" dyld: lazy symbol binding failed: Symbol not found: _locale_charset Referenced from: /Users/kazu/work/ghc/libraries/base/dist- install/build/libHSb ase-4.7.0.0-ghc7.7.20131102.dylib Expected in: flat namespace dyld: Symbol not found: _locale_charset Referenced from: /Users/kazu/work/ghc/libraries/base/dist- install/build/libHSb ase-4.7.0.0-ghc7.7.20131102.dylib Expected in: flat namespace make[1]: *** [compiler/stage2/dll-split.stamp] Trace/BPT trap: 5 make: *** [all] Error 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 2 21:50:36 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Nov 2013 21:50:36 -0000 Subject: [GHC] #8497: clang/wrapper cannot build GHC head with integer-gmp on Mavericks In-Reply-To: <052.a945a4fdb4d0e9bf62bd4d9ed8afe8eb@haskell.org> References: <052.a945a4fdb4d0e9bf62bd4d9ed8afe8eb@haskell.org> Message-ID: <067.6df425951e6085f04edc3ab47752f945@haskell.org> #8497: clang/wrapper cannot build GHC head with integer-gmp on Mavericks ----------------------------------------+---------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: clang Operating System: MacOS X | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by kazu-yamamoto): My GMP is version 5.1.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 2 22:16:44 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Nov 2013 22:16:44 -0000 Subject: [GHC] #8498: gcc hardcoded in build scripts! (ignores the --with-gcc= flag in configure) Message-ID: <045.6e47836af0f0e307f79949999a773a19@haskell.org> #8498: gcc hardcoded in build scripts! (ignores the --with-gcc= flag in configure) ------------------------------------+--------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+--------------------------------- NB: this may be a dupe of another issue, but reporting is separately for now i'm on OS X 10.8 (mountain lion) with xcode 5, ghc comit 23fb7f3b7987d7b3fa445e54680a8a00a37e714d, I've got a gcc-4.8 installed, though gcc in my path is actually clang (as is typical for xcode 5), so I configured as {{{ ./configure --with-gcc=gcc-4.8 }}} and then I noticed as i'm building, some warnings that mean clang is being called rather than gcc! heres a relevant snippet of the build transcript {{{ cp" utils/hsc2hs/template-hsc.h inplace/lib/template-hsc.h "/usr/bin/ghc" -hisuf hi -osuf o -hcsuf hc -static -H64m -O -fasm -package process -package containers -package-db libraries/bootstrapping.conf -i -iutils/deriveConstants/. -iutils/deriveConstants/dist/build -iutils/deriveConstants/dist/build/autogen -Iutils/deriveConstants/dist/build -Iutils/deriveConstants/dist/build/autogen -no-user-package-db -rtsopts -odir utils/deriveConstants/dist/build -hidir utils/deriveConstants/dist/build -stubdir utils/deriveConstants/dist/build -c utils/deriveConstants/./DeriveConstants.hs -o utils/deriveConstants/dist/build/DeriveConstants.o "inplace/bin/mkdirhier" utils/deriveConstants/dist/build/tmp//. "inplace/bin/mkdirhier" rts/dist/build//. gcc -E -m64 -undef -traditional -P -Iincludes -Iincludes/dist -Iincludes /dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Icompiler/stage1 -x c compiler/prelude/primops.txt.pp | grep -v '^#pragma GCC' > compiler/stage1/build/primops.txt compiler/prelude/primops.txt.pp:35:55: warning: missing terminating ' character [-Winvalid-pp-token] -- The default attribute values which apply if you don't specify ^ compiler/prelude/primops.txt.pp:1310:19: warning: missing terminating ' character [-Winvalid-pp-token] difference doesn't fit in an {\tt Int\#}.} ^ compiler/prelude/primops.txt.pp:1591:41: warning: missing terminating ' character [-Winvalid-pp-token] -- not really the right type, but we don't know about pairs here. The ^ compiler/prelude/primops.txt.pp:1620:15: warning: missing terminating ' character [-Winvalid-pp-token] -- but we don't want to tell the strictness ^ compiler/prelude/primops.txt.pp:1634:30: warning: missing terminating ' character [-Winvalid-pp-token] -- must be *precise* - we don't want the strictness analyser turning ^ compiler/prelude/primops.txt.pp:1690:14: warning: missing terminating ' character [-Winvalid-pp-token] -- NB: retry#'s strictness information specifies it to return bottom. ^ compiler/prelude/primops.txt.pp:1811:47: warning: missing terminating ' character [-Winvalid-pp-token] Otherwise, store value arg as {\tt MVar\#}'s new contents, and return with integer 1.} ^ compiler/prelude/primops.txt.pp:1906:21: warning: missing terminating ' character [-Winvalid-pp-token] {\tt RealWorld}; it's only used in the type system, to parameterise {\tt State\#}. } ^ compiler/prelude/primops.txt.pp:2084:67: warning: missing terminating ' character [-Winvalid-pp-token] -- why return the value? So that we can control sharing of seq'd ^ compiler/prelude/primops.txt.pp:2087:13: warning: missing terminating ' character [-Winvalid-pp-token] -- we don't want to inline x, so better to represent it as ^ compiler/prelude/primops.txt.pp:2108:48: warning: missing terminating ' character [-Winvalid-pp-token] -- `the processor containing the expression v'; it is not evaluated ^ compiler/prelude/primops.txt.pp:2206:20: warning: missing terminating ' character [-Winvalid-pp-token] {These aren't nearly as wired in as Etc...} ^ compiler/prelude/primops.txt.pp:2236:57: warning: missing terminating ' character [-Winvalid-pp-token] * It does not claim to be a {\it data} type, and that's important for ^ compiler/prelude/primops.txt.pp:2240:4: warning: missing terminating ' character [-Winvalid-pp-token] It's also used to instantiate un-constrained type variables after type ^ compiler/prelude/primops.txt.pp:2278:86: warning: missing terminating ' character [-Winvalid-pp-token] used when you want to write a program that you know is well-typed, but where Haskell's ^ compiler/prelude/primops.txt.pp:2301:28: warning: missing terminating ' character [-Winvalid-pp-token] have to do with GHC's internal representation details (for the congnoscenti, data values ^ compiler/prelude/primops.txt.pp:2307:76: warning: missing terminating ' character [-Winvalid-pp-token] -- NB. It is tempting to think that casting a value to a type that it doesn't have is safe ^ compiler/prelude/primops.txt.pp:2308:22: warning: missing terminating ' character [-Winvalid-pp-token] -- as long as you don't "do anything" with the value in its cast form, such as seq on it. This ^ compiler/prelude/primops.txt.pp:2309:7: warning: missing terminating ' character [-Winvalid-pp-token] -- isn't the case: the compiler can insert seqs itself, and if these happen at the wrong type, ^ compiler/prelude/primops.txt.pp:2344:17: warning: missing terminating ' character [-Winvalid-pp-token] the newtype's concrete type to the abstract type. But it also works in ^ compiler/prelude/primops.txt.pp:2367:67: warning: missing terminating ' character [-Winvalid-pp-token] {\tt instance Coercible b b' => Coercible (D a b c) (D a b' c')} ^ compiler/prelude/primops.txt.pp:2389:43: warning: missing terminating ' character [-Winvalid-pp-token] you need to set the role of {\tt Set}'s type parameter to Nominal. }}} notice the hard coded gcc call {{{ gcc -E -m64 -undef -traditional -P -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist- ghcconstants/header -Icompiler/stage1 -x c compiler/prelude/primops.txt.pp | grep -v '^#pragma GCC' > compiler/stage1/build/primops.txt }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 2 22:27:25 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Nov 2013 22:27:25 -0000 Subject: [GHC] #8498: gcc hardcoded in build scripts! (ignores the --with-gcc= flag in configure) In-Reply-To: <045.6e47836af0f0e307f79949999a773a19@haskell.org> References: <045.6e47836af0f0e307f79949999a773a19@haskell.org> Message-ID: <060.2c672cf7f87b17c75af9bad8eff2abf1@haskell.org> #8498: gcc hardcoded in build scripts! (ignores the --with-gcc= flag in configure) ---------------------------------+------------------------------------ Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Comment (by carter): heres another offending line {{{ gcc -E -m64 -undef -traditional -P -DTOP='"/Users/carter/Desktop/repoScratcher/ghc"' -DPAPI_INCLUDE_DIR="" -DPAPI_LIB_DIR="" -DFFI_INCLUDE_DIR= -DFFI_LIB_DIR= '-DFFI_LIB="Cffi"' -x c -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header rts/package.conf.in -o rts/dist/package.conf.inplace.raw }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 2 23:15:50 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Nov 2013 23:15:50 -0000 Subject: [GHC] #8256: adding locality levels to prefetch# and friends In-Reply-To: <045.bc455c21650626f3242606c828908318@haskell.org> References: <045.bc455c21650626f3242606c828908318@haskell.org> Message-ID: <060.a8d796ab079e77233c1edbdf42ac2216@haskell.org> #8256: adding locality levels to prefetch# and friends -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: task | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8252 ,#8107 -------------------------------------+------------------------------------ Comment (by carter): https://github.com/cartazio/ghc/compare/prefetch-docs should point to the updated branch now, https://github.com/cartazio/ghc/commit/691fcd997ab5815ccc1d448f8e30e0ac07a9faee in particular -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 2 23:20:46 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Nov 2013 23:20:46 -0000 Subject: [GHC] #8256: adding locality levels to prefetch# and friends In-Reply-To: <045.bc455c21650626f3242606c828908318@haskell.org> References: <045.bc455c21650626f3242606c828908318@haskell.org> Message-ID: <060.a74c5678651a78012271f1bde39c51ea@haskell.org> #8256: adding locality levels to prefetch# and friends -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8252 ,#8107 -------------------------------------+------------------------------------ Changes (by carter): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 3 03:43:32 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Nov 2013 03:43:32 -0000 Subject: [GHC] #8497: clang/wrapper cannot build GHC head with integer-gmp on Mavericks In-Reply-To: <052.a945a4fdb4d0e9bf62bd4d9ed8afe8eb@haskell.org> References: <052.a945a4fdb4d0e9bf62bd4d9ed8afe8eb@haskell.org> Message-ID: <067.a408a156d07eefbe5eed0fb6ac3a25cb@haskell.org> #8497: clang/wrapper cannot build GHC head with integer-gmp on Mavericks ----------------------------------------+---------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: clang Operating System: MacOS X | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by kazu-yamamoto): _locale_charset is a libiconv issue. It's very strange that --with-gmp-xxx influences iconv. Anyway, I tried: {{{ % ./configure --prefix=/ghc-head --with-gmp-includes=/opt/local/include --with-gmp-libraries=/opt/local/lib --with-iconv-includes=/usr/include --with-iconv-libraries=/usr/lib }}} But this time, the version of FFI mismatched. So, I did: {{{ % ./configure --prefix=/ghc-head --with-gmp-includes=/opt/local/include --with-gmp-libraries=/opt/local/lib --with-iconv-includes=/usr/include --with-iconv-libraries=/usr/lib --with-system-libffi --with-ffi- includes=/usr/include/ffi --with-ffi-libraries=/usr/lib }}} This configuration can build GHC head on Mavericks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 3 10:23:17 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Nov 2013 10:23:17 -0000 Subject: [GHC] #7359: unix-2.6.0.0 fails to install on mac os x with 7.4.* (works with 7.6.1) In-Reply-To: <053.15621419a346036f18a12d432abb18a5@haskell.org> References: <053.15621419a346036f18a12d432abb18a5@haskell.org> Message-ID: <068.c1bab0a4aa890d4fd10c4acd1a636513@haskell.org> #7359: unix-2.6.0.0 fails to install on mac os x with 7.4.* (works with 7.6.1) -----------------------------------+---------------------------------- Reporter: AndreasVoellmy | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.6.3 Component: libraries/unix | Version: 7.4.1 Resolution: | Keywords: unix package Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+---------------------------------- Comment (by hvr): Replying to [comment:10 MtnViewMark]: > The unix package is supplied with GHC. You can't, in general, just use a different version. Haskell Platform 2012.4 ships with GHC 7.4.1, which includes unix-2.5.1.1. I wouldn't expect unix-2.6.x.y to work with GHC 7.4.1 at all. Fwiw, the soon to be released `unix-2.7.0.0` package should work with GHC 7.4.x, GHC 7.6.x, and (obviously) GHC 7.8.x (See also [https://travis- ci.org/ghc/packages-unix current TravisCI build status]) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 3 11:01:21 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Nov 2013 11:01:21 -0000 Subject: [GHC] #8498: gcc hardcoded in build scripts! (ignores the --with-gcc= flag in configure) In-Reply-To: <045.6e47836af0f0e307f79949999a773a19@haskell.org> References: <045.6e47836af0f0e307f79949999a773a19@haskell.org> Message-ID: <060.c5133fe428022cccc27916f737a16597@haskell.org> #8498: gcc hardcoded in build scripts! (ignores the --with-gcc= flag in configure) ---------------------------------+------------------------------------ Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Comment (by hvr): My first guess would be that `--with-gcc` isn't passed to all sub-packages properly so that they fall-back to an autodetected `gcc`, as the actual use of `gcc` doesn't seem to be hardcoded in the build scripts. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 4 01:06:21 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Nov 2013 01:06:21 -0000 Subject: [GHC] #8305: ghci macros override built-ins for command expansion In-Reply-To: <047.fc409110f08eee40d2b732450d9304f1@haskell.org> References: <047.fc409110f08eee40d2b732450d9304f1@haskell.org> Message-ID: <062.f39d1c99e3a60b8bef31caa0e6a3389a@haskell.org> #8305: ghci macros override built-ins for command expansion -------------------------------------+------------------------------------ Reporter: rwbarton | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8113 -------------------------------------+------------------------------------ Comment (by thoughtpolice): Thank you Herbert. This patch looks nice - please commit and add documentation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 4 01:06:58 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Nov 2013 01:06:58 -0000 Subject: [GHC] #8256: adding locality levels to prefetch# and friends In-Reply-To: <045.bc455c21650626f3242606c828908318@haskell.org> References: <045.bc455c21650626f3242606c828908318@haskell.org> Message-ID: <060.d4bd78ea7ebe7432a2aa2e67ba1037b2@haskell.org> #8256: adding locality levels to prefetch# and friends -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8252 ,#8107 -------------------------------------+------------------------------------ Comment (by Austin Seipp ): In [changeset:"37ae422fc1131245705a686d1e3144b3f9e9aa81/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="37ae422fc1131245705a686d1e3144b3f9e9aa81" Update documentation concerning prefetch ops Also remove can_fail=True since it's likely unnecessary upon discussion (see #8256.) Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 4 01:07:43 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Nov 2013 01:07:43 -0000 Subject: [GHC] #8256: adding locality levels to prefetch# and friends In-Reply-To: <045.bc455c21650626f3242606c828908318@haskell.org> References: <045.bc455c21650626f3242606c828908318@haskell.org> Message-ID: <060.f2c90c1c533e7a2dc978abb7ef831181@haskell.org> #8256: adding locality levels to prefetch# and friends -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: task | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8252 ,#8107 -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 4 01:08:53 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Nov 2013 01:08:53 -0000 Subject: [GHC] #8483: Use addDependentFile in Language.Haskell.TH.Syntax.quoteFile In-Reply-To: <045.6dbb71c2d7b66ab1567be68a53026d80@haskell.org> References: <045.6dbb71c2d7b66ab1567be68a53026d80@haskell.org> Message-ID: <060.4409bf059bda5075a936370bab9ff12e@haskell.org> #8483: Use addDependentFile in Language.Haskell.TH.Syntax.quoteFile --------------------------------------+------------------------------------ Reporter: aavogt | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries (other) | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 4 01:26:07 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Nov 2013 01:26:07 -0000 Subject: [GHC] #8499: Template Haskell: newName not new enough Message-ID: <047.8acb3e68d5dc0fc3d9ad54c8933fb55e@haskell.org> #8499: Template Haskell: newName not new enough ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- When I compile this: {{{ {-# LANGUAGE TemplateHaskell, PolyKinds, DataKinds #-} {-# OPTIONS_GHC -Wall #-} import Language.Haskell.TH $( do TyConI (DataD _ _ [PlainTV tvb_a] _ _) <- reify ''Maybe my_a <- newName "a" return [TySynD (mkName "SMaybe") [KindedTV my_a (AppT (ConT ''Maybe) (VarT tvb_a))] (TupleT 0)] ) }}} I get this: {{{ /Users/rae/temp/Bug.hs:6:4: Warning: This binding for ?a? shadows the existing binding bound at /Users/rae/temp/Bug.hs:6:4 }}} The problem is that, in the library definition for `Maybe`, the name of its type variable is `a`. In my Template Haskell code, I read in `Maybe`'s definition (using `reify`) to extract the name of `Maybe`'s type variable. I then create a new name, also seeded with `"a"`. Then, I create a type synonym definition {{{ type SMaybe (a_newName :: Maybe a_Maybe) = () }}} where `a_newName` is the variable I `newName`d, and `a_Maybe` is the name I slurped from `Maybe`'s definition. These variables print with different uniques, but the warning comes up anyway. This problem actually came up in real code (singletons library), where I'm trying to get the generated code to be warning-free. This was tested on 7.7.20131031. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 4 01:30:46 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Nov 2013 01:30:46 -0000 Subject: [GHC] #8500: Default associated type instances not instantiated Message-ID: <047.cfe60fb3dd185127d3393afe6f012f1a@haskell.org> #8500: Default associated type instances not instantiated ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I have these modules: {{{ {-# LANGUAGE TypeFamilies #-} module A where class C a where type F a type F a = [a] }}} {{{ {-# LANGUAGE TypeFamilies #-} module B where import A instance C Int where type F Int = Double instance C Bool }}} When I say `ghc A.hs B.hs`, all works just fine. But, if I say `ghc A.hs` and then `ghc B.hs`, I get this: {{{ B.hs:8:8: Conflicting family instance declarations: F Int -- Defined at B.hs:8:8 F a1 -- Defined in ?B? }}} For some reason, when GHC reads in default type instances from an interface file, it doesn't instantiate them properly when they get used. This was tested on 7.7.20131031. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 4 01:38:21 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Nov 2013 01:38:21 -0000 Subject: [GHC] #8493: Can't compile happy + ghc with clang's CPP In-Reply-To: <043.76042121dcfd6c3f0cfaaefb2e590cc6@haskell.org> References: <043.76042121dcfd6c3f0cfaaefb2e590cc6@haskell.org> Message-ID: <058.ac98d43db3d93477c445e9403632068e@haskell.org> #8493: Can't compile happy + ghc with clang's CPP ----------------------------------------+---------------------------------- Reporter: maxs | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: libraries (other) | Version: 7.7 Resolution: | Keywords: happy clang Operating System: MacOS X | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by maxs): I don't think we have a problem with indentation if you use happy 1.18.10 or happy HEAD (2cfc3b70cd). If you use happy 1.19 to compile happy, you may have indentation problems with clang. But HEAD fixed that. We do however have a problem with some lines with preprocessor "comments". Happy Version 1.18.10 can compile happy HEAD (with clang). But if you then try to compile a happy program (like GHC or happy HEAD) with happy HEAD, it will error on: {{{ :2:2: Not in scope: `#' }}} Which is from the happy processed files. They look like: {{{ {-# LINE 1 "templates/GenericTemplate.hs" #-} # 1 "templates/GenericTemplate.hs" # 1 "" 1 # 1 "templates/GenericTemplate.hs" 2 -- $Id: GenericTemplate.hs,v 1.26 2005/01/14 14:47:22 simonmar Exp $ ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 4 01:42:37 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Nov 2013 01:42:37 -0000 Subject: [GHC] #8493: Can't compile happy + ghc with clang's CPP In-Reply-To: <043.76042121dcfd6c3f0cfaaefb2e590cc6@haskell.org> References: <043.76042121dcfd6c3f0cfaaefb2e590cc6@haskell.org> Message-ID: <058.013633433da62f7308338d64fb0175c0@haskell.org> #8493: Can't compile happy + ghc with clang's CPP ----------------------------------------+---------------------------------- Reporter: maxs | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: libraries (other) | Version: 7.7 Resolution: | Keywords: happy clang Operating System: MacOS X | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Changes (by kazu-yamamoto): * cc: kazu@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 4 01:49:12 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Nov 2013 01:49:12 -0000 Subject: [GHC] #8493: Can't compile happy + ghc with clang's CPP In-Reply-To: <043.76042121dcfd6c3f0cfaaefb2e590cc6@haskell.org> References: <043.76042121dcfd6c3f0cfaaefb2e590cc6@haskell.org> Message-ID: <058.2b2eed32bc3ff579ae2d97c02c776ec6@haskell.org> #8493: Can't compile happy + ghc with clang's CPP ----------------------------------------+---------------------------------- Reporter: maxs | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: libraries (other) | Version: 7.7 Resolution: | Keywords: happy clang Operating System: MacOS X | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by kazu-yamamoto): I'm using GHC 7.6.3 with the wrapper on Mavericks. I can compile happy 1.19.0 in this environment. I can even build GHC head in this environment, too. If there is something I can verify, please tell me. P.S. I got the following warning when configuring happy 1.19.0: {{{ % cabal configure Resolving dependencies... [1 of 1] Compiling Main ( Setup.lhs, dist/setup/Main.o ) Linking ./dist/setup/setup ... Configuring happy-1.19.0... /var/folders/k0/548g5xg90jjfbrj5j09nvwv80000gq/T/4321.c:1:12: warning: control reaches end of non-void function [-Wreturn-type] int foo() {} ^ 1 warning generated. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 4 01:54:20 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Nov 2013 01:54:20 -0000 Subject: [GHC] #8493: Can't compile happy + ghc with clang's CPP In-Reply-To: <043.76042121dcfd6c3f0cfaaefb2e590cc6@haskell.org> References: <043.76042121dcfd6c3f0cfaaefb2e590cc6@haskell.org> Message-ID: <058.f908d90980c41576c310b51dca0622f7@haskell.org> #8493: Can't compile happy + ghc with clang's CPP ----------------------------------------+---------------------------------- Reporter: maxs | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: libraries (other) | Version: 7.7 Resolution: | Keywords: happy clang Operating System: MacOS X | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by maxs): is your wrapper set to use '/usr/bin/clang' or '/usr/local/bin/gcc-4.2' ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 4 02:00:47 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Nov 2013 02:00:47 -0000 Subject: [GHC] #8493: Can't compile happy + ghc with clang's CPP In-Reply-To: <043.76042121dcfd6c3f0cfaaefb2e590cc6@haskell.org> References: <043.76042121dcfd6c3f0cfaaefb2e590cc6@haskell.org> Message-ID: <058.1b48a8f193c4349a43c286f8c6b8b9ea@haskell.org> #8493: Can't compile happy + ghc with clang's CPP ----------------------------------------+---------------------------------- Reporter: maxs | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: libraries (other) | Version: 7.7 Resolution: | Keywords: happy clang Operating System: MacOS X | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by kazu-yamamoto): clang. For more information, please read: http://d.hatena.ne.jp/kazu- yamamoto/20131028/1382921924 The name of "gcc" is really important. If the name of your wrapper is not "gcc", you get some troubles. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 4 02:40:24 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Nov 2013 02:40:24 -0000 Subject: [GHC] #8493: Can't compile happy + ghc with clang's CPP In-Reply-To: <043.76042121dcfd6c3f0cfaaefb2e590cc6@haskell.org> References: <043.76042121dcfd6c3f0cfaaefb2e590cc6@haskell.org> Message-ID: <058.77bcbc97aaf5839c50766b784911864f@haskell.org> #8493: Can't compile happy + ghc with clang's CPP ----------------------------------------+---------------------------------- Reporter: maxs | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: libraries (other) | Version: 7.7 Resolution: | Keywords: happy clang Operating System: MacOS X | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by maxs): I tried replacing gcc with the wrapper, but it does not change the outcome. I am using Mountain Lion, not Mavericks, though that shouldn't matter. `lukexi` was having the same problem, I have messaged him to ask if this fixes the problem for him. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 4 02:52:56 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Nov 2013 02:52:56 -0000 Subject: [GHC] #8493: Can't compile happy + ghc with clang's CPP In-Reply-To: <043.76042121dcfd6c3f0cfaaefb2e590cc6@haskell.org> References: <043.76042121dcfd6c3f0cfaaefb2e590cc6@haskell.org> Message-ID: <058.33a056a30d1f4ce6f12e40fc5182a07d@haskell.org> #8493: Can't compile happy + ghc with clang's CPP ----------------------------------------+---------------------------------- Reporter: maxs | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: libraries (other) | Version: 7.7 Resolution: | Keywords: happy clang Operating System: MacOS X | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by carter): did you try having a wrapper like the following be "gcc" in your path? {{{ carter Desktop/repoScratcher ? cat ~/bin/gcc #!/bin/sh gcc-4.8 $@% }}} thats how i've solved most of my problems, by making sure the "gcc" in my path is actually gcc. just doing the clang wrapper *wont* resolve that, unless you've got it masquerading as "gcc" too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 4 03:04:12 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Nov 2013 03:04:12 -0000 Subject: [GHC] #8493: Can't compile happy + ghc with clang's CPP In-Reply-To: <043.76042121dcfd6c3f0cfaaefb2e590cc6@haskell.org> References: <043.76042121dcfd6c3f0cfaaefb2e590cc6@haskell.org> Message-ID: <058.c976bb4389b729bb4c230358a198c6fd@haskell.org> #8493: Can't compile happy + ghc with clang's CPP ----------------------------------------+---------------------------------- Reporter: maxs | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: libraries (other) | Version: 7.7 Resolution: | Keywords: happy clang Operating System: MacOS X | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by maxs): Replying to [comment:11 carter]: > thats how i've solved most of my problems, by making sure the "gcc" in my path is actually gcc. Yeah I could install gcc, but we should be able to build it without gcc (we could until the happy version got bumped to 1.19 recently). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 4 03:06:27 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Nov 2013 03:06:27 -0000 Subject: [GHC] #8493: Can't compile happy + ghc with clang's CPP In-Reply-To: <043.76042121dcfd6c3f0cfaaefb2e590cc6@haskell.org> References: <043.76042121dcfd6c3f0cfaaefb2e590cc6@haskell.org> Message-ID: <058.b5f82fd3449207069dbf8f6d55879581@haskell.org> #8493: Can't compile happy + ghc with clang's CPP ----------------------------------------+---------------------------------- Reporter: maxs | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: libraries (other) | Version: 7.7 Resolution: | Keywords: happy clang Operating System: MacOS X | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by carter): have you tried putting the "clang wrapper" in your path as "gcc" ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 4 03:11:19 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Nov 2013 03:11:19 -0000 Subject: [GHC] #8493: Can't compile happy + ghc with clang's CPP In-Reply-To: <043.76042121dcfd6c3f0cfaaefb2e590cc6@haskell.org> References: <043.76042121dcfd6c3f0cfaaefb2e590cc6@haskell.org> Message-ID: <058.2d927efa295659eb930f95b1289a3e6d@haskell.org> #8493: Can't compile happy + ghc with clang's CPP ----------------------------------------+---------------------------------- Reporter: maxs | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: libraries (other) | Version: 7.7 Resolution: | Keywords: happy clang Operating System: MacOS X | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by maxs): Yeah it currently is. {{{ maxs$ gcc -v Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) Target: x86_64-apple-darwin12.5.0 Thread model: posix clang: warning: argument unused during compilation: '-Wno-invalid-pp- token' clang: warning: argument unused during compilation: '-Wno-unicode' clang: warning: argument unused during compilation: '-Wno-trigraphs' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 4 07:10:44 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Nov 2013 07:10:44 -0000 Subject: [GHC] #5987: Too many symbols in ghc package DLL In-Reply-To: <044.2d87ca11391c23e0fa5f3c5418ae791f@haskell.org> References: <044.2d87ca11391c23e0fa5f3c5418ae791f@haskell.org> Message-ID: <059.9a0375a450ab28c25d11a4562375fe4c@haskell.org> #5987: Too many symbols in ghc package DLL -------------------------------------+------------------------------------ Reporter: igloo | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: 3658 | Related Tickets: -------------------------------------+------------------------------------ Changes (by shelarcy): * cc: shelarcy@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 4 07:26:42 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Nov 2013 07:26:42 -0000 Subject: [GHC] #8501: Improve error message when using rec/mdo keyword without RecursiveDo extention. Message-ID: <047.d2feb1b8bba3b3b1bbfeebc99fe25059@haskell.org> #8501: Improve error message when using rec/mdo keyword without RecursiveDo extention. -------------------------------------+------------------------------------- Reporter: shelarcy | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #3968 | -------------------------------------+------------------------------------- GHC shows unhelpful error message when using rec keyword and/or mdo keyword without RecursiveDo extention. {{{ module NoRecursiveDo where foo = do rec str <- return "foo" putStrLn str }}} {{{ $ ghc -c NoRecursiveDo.hs NoRecursiveDo1.hs:4:5: Parse error in pattern: rec }}} {{{ module NoRecursiveDo2 where bar = mdo str <- return "bar" putStrLn str }}} {{{ $ ghc -c NoRecursiveDo2.hs NoRecursiveDo2.hs:4:9: parse error on input `<-' }}} {{{ module NoRecursiveDo3 where baz = mdo putStrLn "baz" }}} {{{ $ ghc -c NoRecursiveDo3.hs NoRecursiveDo3.hs:3:7: Not in scope: `mdo' Perhaps you meant `mod' (imported from Prelude) }}} I think that GHC should suggest to use RecursiveDo extention when using mdo/rec keyword. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 4 08:14:25 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Nov 2013 08:14:25 -0000 Subject: [GHC] #8305: ghci macros override built-ins for command expansion In-Reply-To: <047.fc409110f08eee40d2b732450d9304f1@haskell.org> References: <047.fc409110f08eee40d2b732450d9304f1@haskell.org> Message-ID: <062.a516cfba7cb7abb6a5f54a620662bfc8@haskell.org> #8305: ghci macros override built-ins for command expansion -------------------------------------+------------------------------------ Reporter: rwbarton | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8113 -------------------------------------+------------------------------------ Comment (by Herbert Valerio Riedel ): In [changeset:"7e4406b282647587384981f6b5ee8d7c6309373d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="7e4406b282647587384981f6b5ee8d7c6309373d" Tweak lookup semantics for GHCi macros This changes the prefix-based lookup to prefer macros over builtins only if the macro name matches an existing builtin name. See #8305 for more details. Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 4 08:16:42 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Nov 2013 08:16:42 -0000 Subject: [GHC] #8305: ghci macros override built-ins for command expansion In-Reply-To: <047.fc409110f08eee40d2b732450d9304f1@haskell.org> References: <047.fc409110f08eee40d2b732450d9304f1@haskell.org> Message-ID: <062.43cfbd42069db9773384ea3e792b46fc@haskell.org> #8305: ghci macros override built-ins for command expansion -------------------------------------+------------------------------------ Reporter: rwbarton | Owner: rwbarton Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8113 -------------------------------------+------------------------------------ Changes (by hvr): * owner: => rwbarton Comment: ...assigning to rwbarton as he agreed to write the documentation part :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 4 09:09:04 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Nov 2013 09:09:04 -0000 Subject: [GHC] #8495: Infinite loop when using Data.HashTable.newHint and Data.HashTable.update In-Reply-To: <045.55e270549b2807cd70f226c42d95a07a@haskell.org> References: <045.55e270549b2807cd70f226c42d95a07a@haskell.org> Message-ID: <060.9412f8e55100a9af8d0aa3c17d20fbc4@haskell.org> #8495: Infinite loop when using Data.HashTable.newHint and Data.HashTable.update -------------------------------------+------------------------------------ Reporter: erszcz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): I see that the online documentation for `Data.HashTable` says "Deprecated: `Data.HashTable` will be removed in GHC 7.8. Please use an alternative, e.g. the `hashtables` package, instead." So it might be worth checking out that package? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 4 09:25:51 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Nov 2013 09:25:51 -0000 Subject: [GHC] #8134: ghc enters a loop while building 7.6.3 for powerpc64 platform. In-Reply-To: <043.0289be94f89f3f22e5a1a6cc61dcce1b@haskell.org> References: <043.0289be94f89f3f22e5a1a6cc61dcce1b@haskell.org> Message-ID: <058.a3accadfe7d936f4ccf96e5c72df6a24@haskell.org> #8134: ghc enters a loop while building 7.6.3 for powerpc64 platform. -------------------------------------+----------------------------- Reporter: k0da | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.6.3 Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+----------------------------- Comment (by simonpj): Amazing bug -- well done guys! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 4 09:37:09 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Nov 2013 09:37:09 -0000 Subject: [GHC] #8495: Infinite loop when using Data.HashTable.newHint and Data.HashTable.update In-Reply-To: <045.55e270549b2807cd70f226c42d95a07a@haskell.org> References: <045.55e270549b2807cd70f226c42d95a07a@haskell.org> Message-ID: <060.4b3bf6b7d21d7697b8a147a981d6478f@haskell.org> #8495: Infinite loop when using Data.HashTable.newHint and Data.HashTable.update -------------------------------------+------------------------------------ Reporter: erszcz | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 7.4.2 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by erszcz): * status: new => closed * resolution: => wontfix Comment: Definitely. I haven't noticed the deprecation notice and it probably wasn't there yet when I initially discovered the bug about a year ago. I guess the ticket might be closed then. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 4 10:08:22 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Nov 2013 10:08:22 -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.3765849e448de46b2ffd762591b389a7@haskell.org> #1480: Template Haskell should allow reification of modules ----------------------------+---------------------------------------------- Reporter: igloo | Owner: Type: feature | Status: closed request | Milestone: 7.8.1 Priority: highest | Version: 7.7 Component: | Keywords: Template Haskell | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Moderate (less than a day) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: 8398 | ----------------------------+---------------------------------------------- Comment (by simonmar): Regarding `mi_usages`, it does contain all the direct imports, and you can tell which entries are direct imports by the `usg_exports` field, which is `Just` for a direct import and `Nothing` otherwise. There are more comments on the `Usages` type, but feel free to reorganise the comments. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 4 13:39:43 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Nov 2013 13:39:43 -0000 Subject: [GHC] #7263: Add derived Show instances to GHC.Generics In-Reply-To: <042.536f882060c165e1b057735244b60fda@haskell.org> References: <042.536f882060c165e1b057735244b60fda@haskell.org> Message-ID: <057.8ae1e4e0a9805bf854ca086b61cd691e@haskell.org> #7263: Add derived Show instances to GHC.Generics -------------------------------------+------------------------------------ Reporter: dag | Owner: dreixel Type: feature request | Status: closed Priority: normal | Milestone: 7.8.1 Component: GHC API | Version: 7.7 Resolution: fixed | Keywords: generics Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by monoidal): I added it in 9f507c6b73470874d2e7db3abd83a21d446b4a23. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 4 13:42:47 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Nov 2013 13:42:47 -0000 Subject: [GHC] #1201: ghci runs Template Haskell splices 4 times In-Reply-To: <044.6dd33d366d8a02b3db5c895a0994c7e6@haskell.org> References: <044.6dd33d366d8a02b3db5c895a0994c7e6@haskell.org> Message-ID: <059.9e9ca246f844e1e4fee75044f0302ac7@haskell.org> #1201: ghci runs Template Haskell splices 4 times -------------------------------------+------------------------------------ Reporter: igloo | Owner: simonpj Type: bug | Status: closed Priority: low | Milestone: _|_ Component: Template Haskell | Version: 6.6 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: ghci018 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by monoidal): * status: new => closed * resolution: => fixed Comment: This is now fixed, thanks to new TH. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 4 13:58:53 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Nov 2013 13:58:53 -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.179512e91e79d7bac44ee0b842f539b9@haskell.org> #1480: Template Haskell should allow reification of modules ----------------------------+---------------------------------------------- Reporter: igloo | Owner: Type: feature | Status: closed request | Milestone: 7.8.1 Priority: highest | Version: 7.7 Component: | Keywords: Template Haskell | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Moderate (less than a day) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: 8398 | ----------------------------+---------------------------------------------- Comment (by errge): I have to experiment a bit more around this, but at a first glance, I see this in ```HscTypes.lhs```: {{{ -- | Records modules that we depend on by making a direct import from data Usage -- | Module from another package = UsagePackageModule { usg_mod :: Module, -- ^ External package module depended on usg_mod_hash :: Fingerprint, -- ^ Cached module fingerprint usg_safe :: IsSafeImport -- ^ Was this module imported as a safe import } -- | Module from the current package | UsageHomeModule { usg_mod_name :: ModuleName, -- ^ Name of the module usg_mod_hash :: Fingerprint, -- ^ Cached module fingerprint usg_entities :: [(OccName,Fingerprint)], -- ^ Entities we depend on, sorted by occurrence name and fingerprinted. -- NB: usages are for parent names only, e.g. type constructors -- but not the associated data constructors. usg_exports :: Maybe Fingerprint, -- ^ Fingerprint for the export list we used to depend on this module, -- if we depend on the export list usg_safe :: IsSafeImport -- ^ Was this module imported as a safe import } -- ^ Module from the current package -- | A file upon which the module depends, e.g. a CPP #include, or using TH's -- 'addDependentFile' | UsageFile { usg_file_path :: FilePath, -- ^ External file dependency. From a CPP #include or TH -- addDependentFile. Should be absolute. usg_file_hash :: Fingerprint -- ^ 'Fingerprint' of the file contents. -- Note: We don't consider things like modification timestamps -- here, because there's no reason to recompile if the actual -- contents don't change. This previously lead to odd -- recompilation behaviors; see #8114 } deriving( Eq ) -- The export list field is (Just v) if we depend on the export list: -- i.e. we imported the module directly, whether or not we -- enumerated the things we imported, or just imported -- everything -- We need to recompile if M's exports change, because -- if the import was import M, we might now have a name clash -- in the importing module. -- if the import was import M(x) M might no longer export x -- The only way we don't depend on the export list is if we have -- import M() -- And of course, for modules that aren't imported directly we don't -- depend on their export lists }}} As you can see, UsagePackageModule doesn't have a usg_exports field, only UsageHomeModule. So I can't decide about directness of the import based on usg_exports alone. Maybe we should make this info more explicit in Usages if we want to depend on it for TH reification. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 4 15:10:52 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Nov 2013 15:10:52 -0000 Subject: [GHC] #8502: Document a surprising {{{unsafeDupablePerformIO}}} limitation. Message-ID: <044.489edd9a621286a2f23856fcc4df99d4@haskell.org> #8502: Document a surprising {{{unsafeDupablePerformIO}}} limitation. -------------------------------------+------------------------------------- Reporter: int-e | Owner: Type: task | Status: new Priority: normal | Milestone: 7.8.1 Component: libraries/base | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Documentation Difficulty: Easy (less than 1 | bug hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- We just discussed the following code on #ghc. {{{ import System.IO.Unsafe import Control.Concurrent.MVar import Control.Concurrent import GHC.Conc (par, pseq) x :: MVar Int -> Int -> Int x m a = unsafeDupablePerformIO $ withMVar m $ \i -> do sum [1..1000000 + a] `seq` return i main1 = do m <- newMVar 42 let w = x m 0 w `par` print w {- spark: thread blocked indefinitely in an MVar operation -} main2 = do m <- newMVar 42 let w = x m 0 forkIO $ print w forkIO $ print w print w {- spark: <> spark: <> -} main = main2 }}} This is not a bug; what happens is that the RTS suspends one of the duplicated computations of {{{w}}}, effectively killing the IO action that was passed to {{{unsafeDupablePerformIO}}} in the middle. This limitation of {{{unsafeDupablePerformIO}}} should be documented. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 4 15:13:44 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Nov 2013 15:13:44 -0000 Subject: [GHC] #8502: Document a surprising {{{unsafeDupablePerformIO}}} limitation. In-Reply-To: <044.489edd9a621286a2f23856fcc4df99d4@haskell.org> References: <044.489edd9a621286a2f23856fcc4df99d4@haskell.org> Message-ID: <059.befd75f5c658bffa7aae7a62bca5d534@haskell.org> #8502: Document a surprising {{{unsafeDupablePerformIO}}} limitation. -------------------------------------+------------------------------------- Reporter: int-e | Owner: Type: task | Status: new Priority: normal | Milestone: 7.8.1 Component: libraries/base | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Documentation | Difficulty: Easy (less than 1 bug | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by int-e): The same limitation applies to {{{unsafeIOToST}}}, which is currently completely undocumented. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 4 15:15:30 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Nov 2013 15:15:30 -0000 Subject: [GHC] #8502: Document a surprising {{{unsafeDupablePerformIO}}} limitation. In-Reply-To: <044.489edd9a621286a2f23856fcc4df99d4@haskell.org> References: <044.489edd9a621286a2f23856fcc4df99d4@haskell.org> Message-ID: <059.704b54fb982a5b6a70956fafbce95b66@haskell.org> #8502: Document a surprising {{{unsafeDupablePerformIO}}} limitation. -------------------------------------+------------------------------------- Reporter: int-e | Owner: Type: task | Status: new Priority: normal | Milestone: 7.8.1 Component: libraries/base | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Documentation | Difficulty: Easy (less than 1 bug | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by simonmar): * cc: simonmar (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 4 16:07:56 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Nov 2013 16:07:56 -0000 Subject: [GHC] #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough Message-ID: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough ------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Roman Cheplyaka writes: I just tried compiling smallcheck with GHC HEAD, and it didn't work out: {{{ Test/SmallCheck/SeriesMonad.hs:41:7: Can't make a derived instance of ?MonadLogic (Series m)? (even with cunning newtype deriving): it is not type-safe to use GeneralizedNewtypeDeriving on this class; ?msplit?, at type ?forall a. m a -> m (Maybe (a, m a))?, cannot be converted safely In the newtype declaration for ?Series? }}} So GHC now looks at the methods, but the problem is still there. I would agree that `msplit`'s type is problematic (due to the nested `m`'s), but Simon and Richard previously said that it should work, so I'm confused. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 4 18:51:22 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Nov 2013 18:51:22 -0000 Subject: [GHC] #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough In-Reply-To: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> References: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> Message-ID: <062.a0241b0d5e10e202a815afe67e75eedf@haskell.org> #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): This is subtler than I thought. Let's take a simple case: {{{ class C m where meth :: m (m a) instance C Maybe where meth = Nothing newtype NT a = MkNT (Maybe a) deriving C }}} In the derived instance for `C NT`, we need this: {{{ $meth_C_NT = $meth_C_Maybe |> co where co :: forall (a :: *). Maybe (Maybe a) ~R# NT (NT a) }}} What is `co`? Ideally, it would be {{{ co = forall (a :: *). Sym NTCo:NT[0] (Sym NTCo:NT[0] ) }}} but that doesn't role-check! `NTCo:NT[0]` has type `NT ~R# Maybe`. But, to apply that coercion to another requires an `AppCo`, which in turn requires its second argument to have a nominal role. The underlying problem here is essentially that eta-reducing the newtype coercion loses information about the roles of its parameters. After all, if `Maybe`'s parameter were at a nominal role, then this deriving would be bogus. By eta-reducing, we're forgetting that `Maybe`'s parameter's role is other than nominal. What to do? One possible solution is to allow `AxiomInstCo` to be oversaturated, and then role information could be stored in an axiom (indeed, role information for all non-eta-reduced parameters is already there). This isn't a terrible plan, but perhaps it has further ramifications that I'm not currently seeing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 5 07:50:59 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Nov 2013 07:50:59 -0000 Subject: [GHC] #8504: Provide minor GC residency estimates Message-ID: <045.f5811eb3821604b8931221edb7e53e19@haskell.org> #8504: Provide minor GC residency estimates -------------------------------------------+------------------------------- Reporter: ezyang | Owner: simonmar Type: feature request | Status: new Priority: lowest | Milestone: Component: Runtime System | Version: 7.7 Keywords: easy | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- Currently, the residency statistics (e.g. max residency and current residency) are only updated when a major garbage collection occurs. While this is the only way to ensure an accurate residency count, there are times when a residency estimate would be desirable, since only taking the sample on major GC can be somewhat low resolution. We already collect and report this information on verbose GC stats, so all that needs to be done is to expose it via GHC.Stats. Should be an easy patch, good for someone who wants to play around in the RTS. Here is a simple patch that switches residency to the inaccurate version: {{{ diff --git a/rts/Stats.c b/rts/Stats.c index c19f23c..c71d0fb 100644 --- a/rts/Stats.c +++ b/rts/Stats.c @@ -449,7 +449,6 @@ stat_endGC (Capability *cap, gc_thread *gct, CAPSET_HEAP_DEFAULT, mblocks_allocated * MBLOCK_SIZE_W * sizeof(W_)); - if (gen == RtsFlags.GcFlags.generations-1) { /* major GC? */ if (live > max_residency) { max_residency = live; } @@ -459,7 +458,6 @@ stat_endGC (Capability *cap, gc_thread *gct, traceEventHeapLive(cap, CAPSET_HEAP_DEFAULT, live * sizeof(W_)); - } if (slop > max_slop) max_slop = slop; } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 5 09:26:39 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Nov 2013 09:26:39 -0000 Subject: [GHC] #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough In-Reply-To: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> References: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> Message-ID: <062.b722cc8d946ca08dcc79c3f97a53d3c9@haskell.org> #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonpj): * cc: dimitris@?, sweirich@? (added) Comment: Wait. Suppose we have `g1 : m ~R n`, and `g2 : a ~R b`. Then you might think we can conclude that `g1 g2 : m a ~R n b`. But as you point out, our current rules say not. (I'm looking in `docs/core-spec/core- spec.pdf`.) But ''why'' do they say not? What does it mean for `m` to be representationally-equal to `n` (something that really only makes intuitive sense at kind *), other than "if you apply them to representationally-equal arguments you get representationally-equal types? Another alternative would be NOT to eta-reduce the newtype coercion. See `Note [Newtype eta]` in `TyCon.lhs`. It's much less important than it was because we are no longer coercing dictionaries. But there would still be a cost, as the note points out. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 5 10:48:32 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Nov 2013 10:48:32 -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.19d14e58eebe6004effe2ae7f28084a1@haskell.org> #1480: Template Haskell should allow reification of modules ----------------------------+---------------------------------------------- Reporter: igloo | Owner: Type: feature | Status: closed request | Milestone: 7.8.1 Priority: highest | Version: 7.7 Component: | Keywords: Template Haskell | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Moderate (less than a day) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: 8398 | ----------------------------+---------------------------------------------- Comment (by simonmar): The source of truth for the design around usages and recompilation is [wiki:Commentary/Compiler/RecompilationAvoidance]. You're right that !UsagePackageModule doesn't have a usg_exports field. For package modules we record a lower resolution dependency, just the hash of the whole module. The rationale is that package modules don't change very often, so we don't need to track fine-grained dependency information about them. This does mean that we can't tell the difference between a direct import and an indirect import of a packages module from the `Usages`. Probably if you need to get a list of direct imports you should get it from somewhere else, e.g. `mg_dir_imps` from `ModGuts`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 5 11:33:12 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Nov 2013 11:33:12 -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.b31d0bdca8e9026892f058e54f8d76a7@haskell.org> #1480: Template Haskell should allow reification of modules ----------------------------+---------------------------------------------- Reporter: igloo | Owner: Type: feature | Status: closed request | Milestone: 7.8.1 Priority: highest | Version: 7.7 Component: | Keywords: Template Haskell | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Moderate (less than a day) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: 8398 | ----------------------------+---------------------------------------------- Comment (by simonpj): Gergely wants to be able walk the entire module-import tree, including deep into packages. (Correct?) So given a module M (presumably including the current one) he'd like to produce a list of all modules that M directly imported. We can get from M to M's `ModIface`, but then we need to find its direct imports. But if M uses a module X, but X is from a package, we can't tell if X is directly imported by M or not. I can see two approaches: * It would be easy enough to record a boolean flag in `UsagePackageModule` for this purpose. * Alternatively, but less satisfactorily, we could say that `reifyModule` returns a superset of the direct imports. That's what happens now I think. But that seems yukky. I prefer the first. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 5 11:34:53 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Nov 2013 11:34:53 -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.f1e5d3e069e2df65c3ae7264a9642492@haskell.org> #1480: Template Haskell should allow reification of modules ----------------------------+---------------------------------------------- Reporter: igloo | Owner: Type: feature | Status: closed request | Milestone: 7.8.1 Priority: highest | Version: 7.7 Component: | Keywords: Template Haskell | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Moderate (less than a day) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: 8398 | ----------------------------+---------------------------------------------- Comment (by simonpj): Simon, I don't understand the relationship between `mi_deps` and `mi_usages` fields of `ModIface`. Both seem implicated in the recompilation check. Can you clarify? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 5 11:55:12 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Nov 2013 11:55:12 -0000 Subject: [GHC] #8500: Default associated type instances not instantiated In-Reply-To: <047.cfe60fb3dd185127d3393afe6f012f1a@haskell.org> References: <047.cfe60fb3dd185127d3393afe6f012f1a@haskell.org> Message-ID: <062.5cf599201a56a07b35cb32bc65255a61@haskell.org> #8500: Default associated type instances not instantiated -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): Good point. I'm on it. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 5 14:07:33 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Nov 2013 14:07:33 -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.d8a14734def8d56d28abc60b3d630cf6@haskell.org> #1480: Template Haskell should allow reification of modules ----------------------------+---------------------------------------------- Reporter: igloo | Owner: Type: feature | Status: closed request | Milestone: 7.8.1 Priority: highest | Version: 7.7 Component: | Keywords: Template Haskell | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Moderate (less than a day) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: 8398 | ----------------------------+---------------------------------------------- Comment (by errge): Yes, you're correct, I want to reify not just the current module, but any module, even in packages. Therefore `ModGuts` is out of the question, and we can only depend on `ModIface`, that is actually serialized to `.hi` files. Your first option (to extend the serialization format with the Boolean) seems to be the correct way, that's what I will try first, when I sit down to do it. But first, I want to look around and get a better understanding about the whole recompilation checking stuff. This discussion and the wikipage will help a lot, I hope. The second option is unsatisfactory: as you pointed out before, it's different between different haskell implementations (or even between different versions of cabal libraries). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 5 14:08:16 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Nov 2013 14:08:16 -0000 Subject: [GHC] #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough In-Reply-To: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> References: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> Message-ID: <062.0112fce674a4972ead00378253da12e2@haskell.org> #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by sweirich): Perhaps another option is to generalize TyConAppCo so that it allows the heads to differ as long as they are (representationally) equal and we have role information for each head. That's slightly more general than changing AxiomInstCo as you'd get transititivity... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 5 14:11:20 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Nov 2013 14:11:20 -0000 Subject: [GHC] #5013: sporadic failures during compilation under solaris In-Reply-To: <045.60b676bf3753dc6058e807ea654417dd@haskell.org> References: <045.60b676bf3753dc6058e807ea654417dd@haskell.org> Message-ID: <060.d0ac748431d2383509857fedc762778c@haskell.org> #5013: sporadic failures during compilation under solaris ----------------------------------+--------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 7.0.4 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+--------------------------- Comment (by maeder): Replying to [comment:22 simonmar]: > yes, `stat` is returning `EINTR` and we're not expecting it to. Change the call to `stat` in `getFileStatus` to use `throwErrnoIfMinus1Retry` (hope I've got that right from memory). I do not see what to try out here. I'm looking at `libraries/unix/System/Posix/Files.hsc` of ghc-7.6.3 (lines 179-189) {{{ -- | @getFileStatus path@ calls gets the @FileStatus@ information (user ID, -- size, access times, etc.) for the file @path at . -- -- Note: calls @stat at . getFileStatus :: FilePath -> IO FileStatus getFileStatus path = do fp <- mallocForeignPtrBytes (#const sizeof(struct stat)) withForeignPtr fp $ \p -> withFilePath path $ \s -> throwErrnoPathIfMinus1_ "getFileStatus" path (c_stat s p) return (FileStatus fp) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 5 14:29:11 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Nov 2013 14:29:11 -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.8eff6cda8e4707871688662ce786e3ea@haskell.org> #1480: Template Haskell should allow reification of modules ----------------------------+---------------------------------------------- Reporter: igloo | Owner: Type: feature | Status: closed request | Milestone: 7.8.1 Priority: highest | Version: 7.7 Component: | Keywords: Template Haskell | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Moderate (less than a day) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: 8398 | ----------------------------+---------------------------------------------- Comment (by simonmar): Replying to [comment:24 simonpj]: > Simon, I don't understand the relationship between `mi_deps` and `mi_usages` fields of `ModIface`. Both seem implicated in the recompilation check. Can you clarify? I've just been poking around in the source tree and the wiki, and I think a concise summary is this: `mi_deps` lists everything below the module, whereas `mi_usages` lists the bits that the module actually depends on, and their fingerprints. `mi_usages` is used ''only'' by the recompilation checker, whereas `mi_deps` is used by the renamer and other places (linking?), and by the recompilation checker. The `mi_usages` of modules that we are not compiling are completely redundant, we never even load them - the interface deserializer returns a thunk for that bit of the `.hi` file, and we never look at it. There is some overlap between these two fields. As far as I know it's been this way for a long time - since before I implemented fingerprints I think. Perhaps the redundancy could be eliminated... but there are a lot of subtleties here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 5 14:31:00 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Nov 2013 14:31:00 -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.364e4a052f1972756bcda64d1bdcc8ab@haskell.org> #1480: Template Haskell should allow reification of modules ----------------------------+---------------------------------------------- Reporter: igloo | Owner: Type: feature | Status: closed request | Milestone: 7.8.1 Priority: highest | Version: 7.7 Component: | Keywords: Template Haskell | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Moderate (less than a day) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: 8398 | ----------------------------+---------------------------------------------- Comment (by simonmar): Now that I think about it, I'm wary about using `mi_usages` for reification, because that widens its scope beyond the recompilation checker. It seems more correct to add the information to `mi_deps`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 5 14:55:03 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Nov 2013 14:55:03 -0000 Subject: [GHC] #8477: Allow inferring ambiguous types In-Reply-To: <045.eba11f97886c50dcee3d55a438abd62f@haskell.org> References: <045.eba11f97886c50dcee3d55a438abd62f@haskell.org> Message-ID: <060.fd89c2a539fe2c9c92ba49c6744cf280@haskell.org> #8477: Allow inferring ambiguous types -------------------------------------+------------------------------------ Reporter: aavogt | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 8390 -------------------------------------+------------------------------------ Comment (by simonpj): I'm dubious about this * Accepting ''inferred'' ambiguous types is a recipe for planting land- mines that will only show up later. Requiring a type signature in such cases seems quite reasonable to me. * I tried [http://okmij.org/ftp/Haskell/TypeLambdaVal.hs]. The instance on line 199 seems problematic; it fails both the ambiguity check and the coverage condition. However I realise that the ambiguity check on the instance declaration should really subsume the (liberal) coverage condition. I'll fix that. * Then the `TypeLambdaVal` example gives {{{ T8477.hs:218:1: Could not deduce (Apply (HIF' (b0 -> HNothing) (HList (a0 :* xs0) -> HJust a0)) (HBool b, x) res) arising from the ambiguity check for ?hsafe_head? from the context (Apply HNull x (HBool b), Apply (HIF' (b1 -> HNothing) (HList (a :* xs) -> HJust a)) (HBool b, x) res) bound by the inferred type for ?hsafe_head?: (Apply HNull x (HBool b), Apply (HIF' (b1 -> HNothing) (HList (a :* xs) -> HJust a)) (HBool b, x) res) => x -> res at T8477.hs:(218,1)-(221,24) The type variables ?b0?, ?a0?, ?xs0? are ambiguous When checking that ?hsafe_head? has the inferred type ?forall x res b b1 a xs. (Apply HNull x (HBool b), Apply (HIF' (b1 -> HNothing) (HList (a :* xs) -> HJust a)) (HBool b, x) res) => x -> res? Probable cause: the inferred type is ambiguous }}} and one other. Indeed, writing out that type may be a bit onerous, but it really does look ambiguous to me! So I'm inclined to "won't fix" for now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 5 15:16:42 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Nov 2013 15:16:42 -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.e3c53fbab4f31c5ee2c5b5388abd5c90@haskell.org> #1480: Template Haskell should allow reification of modules ----------------------------+---------------------------------------------- Reporter: igloo | Owner: Type: feature | Status: closed request | Milestone: 7.8.1 Priority: highest | Version: 7.7 Component: | Keywords: Template Haskell | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Moderate (less than a day) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: 8398 | ----------------------------+---------------------------------------------- Comment (by simonpj): Got it. I'll add comments. I agree about not using `mi_usages` for Gergely's purposes. Maybe add `dep_dir_imps :: [Module]` to `Dependencies` to record the directly- imported modules? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 5 15:19:08 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Nov 2013 15:19:08 -0000 Subject: [GHC] #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough In-Reply-To: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> References: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> Message-ID: <062.b7a5a9d7b543b25aef8b77cb2de385a0@haskell.org> #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): Stephanie did you think about para 2 of my comment? Why not just change the typing rules? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 5 15:28:33 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Nov 2013 15:28:33 -0000 Subject: [GHC] #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough In-Reply-To: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> References: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> Message-ID: <062.ff8945c5fa821ca011e96c70dd5b5c5d@haskell.org> #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by sweirich): Simon, there is more to it than just "if you apply them to representationally-equal arguments you get representationally-equal types?" We need to also look at the roles of the parameters in the application. Consider this example: {{{ type family F a where F Moo = Char F _ = Int newtype T a = MkT (F a) newtype U a = MkU (T a) }}} So T and U are representationally equal, but their parameter has nominal role. That means that we can safely conclude {{{ T Moo ~/R U Moo }}} but it would *not* be safe to say {{{ T Moo ~/R U Int }}} because then we would have Char ~/R Int. That is why I was suggesting the change to TyConAppCo. We're not tracking the parameter roles in kinds, so the only place we can look for them is in the head of an application. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 5 15:31:23 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Nov 2013 15:31:23 -0000 Subject: [GHC] #8479: Generic1 crashes with tyConStupidTheta when using associated type families In-Reply-To: <044.0858e05d425e69eb3762e2b850b8a662@haskell.org> References: <044.0858e05d425e69eb3762e2b850b8a662@haskell.org> Message-ID: <059.afdce1cad30350cfb9dd0bf094831f3c@haskell.org> #8479: Generic1 crashes with tyConStupidTheta when using associated type families -------------------------------------+------------------------------------- Reporter: ghorn | Owner: dreixel Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Generics, Operating System: Unknown/Multiple | Generic1 Type of failure: Compile-time | Architecture: Unknown/Multiple crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by ghorn): * cc: gregmainland@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 5 15:31:43 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Nov 2013 15:31:43 -0000 Subject: [GHC] #8468: ghc panic in deriving Generic1 on Array# In-Reply-To: <044.ffb20432abcbdb672e4810bd2bb326da@haskell.org> References: <044.ffb20432abcbdb672e4810bd2bb326da@haskell.org> Message-ID: <059.d3d1d0d9bcb02e7e68040a4e8a0777a3@haskell.org> #8468: ghc panic in deriving Generic1 on Array# ---------------------------------------+----------------------------------- Reporter: ghorn | Owner: dreixel Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Changes (by ghorn): * cc: gregmainland@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 5 15:32:02 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Nov 2013 15:32:02 -0000 Subject: [GHC] #7346: Allow the use of `deriving` for GHC generics In-Reply-To: <047.98a2cadfb420a57e4024d3aaa2403f08@haskell.org> References: <047.98a2cadfb420a57e4024d3aaa2403f08@haskell.org> Message-ID: <062.02a6e7cfed2c0c6d0babb9ead097aeeb@haskell.org> #7346: Allow the use of `deriving` for GHC generics -------------------------------------+------------------------------------ Reporter: kosmikus | Owner: dreixel Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by ghorn): * cc: gregmainland@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 5 15:47:06 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Nov 2013 15:47:06 -0000 Subject: [GHC] #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough In-Reply-To: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> References: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> Message-ID: <062.5057a7ecd188bfd7ec6a575e391abee4@haskell.org> #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): Good point. Messing with `TyConAppCo` seems like a sledgehammer to crack a nut, though. Let's check one thing. Does the problem go away if we say that the axiom for U is {{{ axiom ax7 a : U a ~R T a }}} that is, if we '''refrain from eta-reducing the axiom'''? If so, I think we can re-visit our reasons for eta-reducing the axiom (see `Note [Newtype eta]` in `TyCon.lhs`). I believe the reason was 99% to do with coercing the dictionary in GND. And we aren't doing that any more. Moreover, it seems kind of odd to have '''representational''' equality at any kind other than *, doesn't it? Do we have any ''other'' source of representational equality at non-* kinds? Getting rid of the eta reduction would simplify the code a bit, too. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 5 15:48:28 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Nov 2013 15:48:28 -0000 Subject: [GHC] #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough In-Reply-To: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> References: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> Message-ID: <062.88c9724a3a00dc8dbe28ea974cfb059a@haskell.org> #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): I agree with Stephanie -- the rule Simon was looking at in core-spec (Co_AppCo, p. 10) is that way for a good reason. Why eta-reduce? Because it allows for more lifting of newtype coercions, via the `Coercible` mechanism. For example, if we don't eta-reduce {{{ newtype NTMaybe a = MkNT (Maybe a) }}} then we couldn't derive, say `StateT Int NTMaybe a ~R StateT Int Maybe a`. So, we don't need eta-reduction as much as maybe we once did, but it's still useful. One other alternative is to have the cake and eat it too: a newtype declaration like the one for `NTMaybe` can create ''two'' axioms: one eta- reduced and one not. There would have to be some logic to choose which axiom to use, but this would allow for all the constructions that we might want. (Strawman implementation: always use the eta-reduced version, except in GND and in `Coercible` code where we need the extra role info.) I'm personally not a big fan of the generalization of `TyConAppCo`. Stephanie's proposal means that the `TyConAppCo` would have to store two `TyCon`s and a coercion between them, and all the code that thinks about `TyConAppCo`s would now have to consider the possibility that the two `TyCon`s are different. But, after all this, I still think I favor my original idea: allow oversaturated `AxiomInstCo`s, and store extra role information in `CoAxiom`s accordingly. Can we think of reasons why this is bad? We already allow oversaturated `TyConAppCo`s (in fact, we require them to be oversaturated, as a `TyConAppCo` can't be on the left of an `AppCo`). We would introduce a similar invariant between `AxiomInstCo` and `AppCo`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 5 15:57:57 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Nov 2013 15:57:57 -0000 Subject: [GHC] #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough In-Reply-To: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> References: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> Message-ID: <062.39b50d182ca0311a1e26f6a6e489123d@haskell.org> #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): Can you outline the `AxiomInstCo` idea in a bit more detail? Sounds plausible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 5 16:07:11 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Nov 2013 16:07:11 -0000 Subject: [GHC] #5013: sporadic failures during compilation under solaris In-Reply-To: <045.60b676bf3753dc6058e807ea654417dd@haskell.org> References: <045.60b676bf3753dc6058e807ea654417dd@haskell.org> Message-ID: <060.11bcc6cd64c23cef54df6ef802fe2423@haskell.org> #5013: sporadic failures during compilation under solaris ----------------------------------+--------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 7.0.4 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+--------------------------- Comment (by maeder): I've replaced `throwErrnoPathIfMinus1_` with `throwErrnoPathIfMinus1Retry_` (also in `libraries/unix/System/Posix/Files/ByteString.hsc`) to see if this makes a difference. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 5 21:17:22 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Nov 2013 21:17:22 -0000 Subject: [GHC] #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough In-Reply-To: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> References: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> Message-ID: <062.e10baf1a20ad05229534ea1aab740e58@haskell.org> #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): Hold the phone! There is an easier solution to the original problem! In my first comment, I wanted a coercion `co :: forall (a :: *). Maybe (Maybe a) ~R NTMaybe (NTMaybe a)`, and then I proposed a possible value of that type that was ill-roled. But, here is a well-roled value: {{{ co = co1 ; co2 co1 :: forall (a :: *). Maybe (Maybe a) ~R Maybe (NT a) co1 = forall (a :: *). Maybe (sym NTCo _N) co2 :: forall (a :: *). Maybe (NT a) ~R NT (NT a) co2 = forall (a :: *). sym NTCo _N }}} If we convert the pieces one at a time and then use transitivity, we're all OK. I remember battling against this problem over the summer. So, now we have a new question: how to get GHC to find this solution? Luckily, we happen to have a solver lying around that does just that: the `Coercible` mechanism. I imagine we could get the GND code to just call the `Coercible` code for each method. In fact, I considered this approach when improving the GND mechanism a few weeks ago, but thought it was overkill. My guess is that this would Just Work, when implemented. It might simplify the code a bit, too, but be somewhat less efficient (at compile time) at doing GND. I think this is reasonable. Taking the idea a bit further, what if the `Coercible` mechanism can't derive a coercion for a particular method? It would have to produce unsolved `Coercible` constraints... which we could just add to the constraints on the GND instance! This would allow more GND's to work than we had hoped for, such as this example: {{{ type family F a class C a where meth :: a -> F a type instance F Int = Bool class C Int where meth = (> 0) type instance F Age = Bool newtype Age = MkAge Int deriving C -- just works, no extra constraints because F Age = F Int type instance F [a] = a class C [a] where meth = head type instance F (List a) = Int newtype List a = MkL [a] deriving C -- this would create an instance with head "instance (Coercible a Int) => C (List a) where ..." }}} This all seems quite reasonable behavior, though we would want to make sure we don't produce constraints like `Coercible Int Bool`. Thoughts? Is this a good plan? We could always, as a first pass, implement GND in terms of `Coercible` and fail if there are any unsolved constraints, working for `C Age` above but not `C (List a)`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 5 21:34:05 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Nov 2013 21:34:05 -0000 Subject: [GHC] #8505: Arrows example error Message-ID: <045.4a3e76cb1e6689edca76590e96afe352@haskell.org> #8505: Arrows example error ------------------------------------+-------------------------------------- Reporter: pdfrod | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Documentation | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Documentation bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+-------------------------------------- In the section '''7.15.2. Conditional commands''' of the User's Guide (http://www.haskell.org/ghc/docs/7.6.3/html/users_guide/arrow- notation.html#idp49515792) it is stated that: {{{ proc (x,y) -> if f x y then g -< x+1 else h -< y+2 }}} is translated to: {{{ arr (\ (x,y) -> if f x y then Left x else Right y) >>> (arr (\x -> x+1) >>> f) ||| (arr (\y -> y+2) >>> g) }}} But this translation doesn't seem correct, because the arrows ''g'' and ''h'' are not being used as in the original code (''h'' doesn't appear at all in the translation). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 5 21:35:03 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Nov 2013 21:35:03 -0000 Subject: [GHC] #8505: Arrows example error In-Reply-To: <045.4a3e76cb1e6689edca76590e96afe352@haskell.org> References: <045.4a3e76cb1e6689edca76590e96afe352@haskell.org> Message-ID: <060.3e20aa599b630db31d07e0aae9276d00@haskell.org> #8505: Arrows example error --------------------------------------+------------------------------------ Reporter: pdfrod | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Documentation bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Changes (by pdfrod): * priority: low => normal -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 5 22:03:01 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Nov 2013 22:03:01 -0000 Subject: [GHC] #8505: Arrows example error In-Reply-To: <045.4a3e76cb1e6689edca76590e96afe352@haskell.org> References: <045.4a3e76cb1e6689edca76590e96afe352@haskell.org> Message-ID: <060.aa7c05537c957d176f5a1d0ed57bf9ab@haskell.org> #8505: Arrows example error --------------------------------------+------------------------------------ Reporter: pdfrod | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Documentation | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Documentation bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Changes (by simonpj): * priority: normal => highest * status: new => patch * milestone: => 7.8.1 Comment: Thanks! Patch looks correct to me. Austin, please apply. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 5 22:27:48 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Nov 2013 22:27:48 -0000 Subject: [GHC] #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough In-Reply-To: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> References: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> Message-ID: <062.6e938f36bdc129a4b8aa298a15ce42a2@haskell.org> #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): Cool idea. I like it. For the most part, the 'deriving' mechanism generates an instance decl in `HsSyn RdrName` and feeds it through the renamer and type checker. We could do that for deriving decls too, like this: {{{ newtype Age = MkAge Int deriving( C ) }}} would generate {{{ instance C Int => C Age where meth = coerce (meth :: Int -> F Int) }}} Here we simply call `coerce`, which wakes up the `Coercible` stuff. It's a bit of a nuisance that we have to specify a type signature (in `HsType`) for `meth`, so that the from-type of the `coerce` is known, but not too bad. What you say about inferring `Coercible` constraints also makes sense. This would have another benefit: making GND much more uniform with the other instances. See `TcEnv.InstInfo`. We can probably get rid of `NewTypeDerived` altogether, by generating a `VanillaInst` instead! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 6 05:33:42 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Nov 2013 05:33:42 -0000 Subject: [GHC] #8506: misleading error message for duplicate type class instances Message-ID: <045.402f8421fe3a87bb854e369460e2a45b@haskell.org> #8506: misleading error message for duplicate type class instances -------------------------------------------+------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- In the following code I accidentally declared a type class more than once, and the error message had absolutely nothing to do with that! {{{ {-# LANGUAGE PolyKinds #-} {-# LANGUAGE BangPatterns #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE DeriveDataTypeable #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE TemplateHaskell #-} module Numerical.Types.Nat(Nat(..),nat) where import Data.Typeable import Data.Data import Language.Haskell.TH hiding (reify) data Nat = S !Nat | Z deriving (Eq,Show,Read,Typeable,Data) nat :: Int -> TypeQ nat n | n >= 0 = localNat n | otherwise = error "nat: negative" where localNat 0 = conT 'Z localNat n = conT 'S `appT` localNat (n-1) ---------------------- ---------------------- {-# LANGUAGE PolyKinds #-} {-# LANGUAGE BangPatterns #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE DeriveDataTypeable #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE StandaloneDeriving #-} {-# LANGUAGE CPP #-} {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE NoImplicitPrelude #-} module Numerical.Types.Shape where import Numerical.Types.Nat import Data.Data type N0 = Z type N1= S N0 type N2 = S N1 type N3 = S N2 type N4 = S N3 type N5 = S N4 type N6 = S N5 type N7 = S N6 type N8 = S N7 type N9 = S N8 type N10 = S N9 class Shapable (n :: Nat) where -- zero rank is boring but lets include it for completeness class Shapable Z where class Shapable One where {- I get the following error src/Numerical/Types/Shape.hs:97:17: Unexpected type `Z' where type variable expected In the declaration of `Shape Z' -} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 6 06:04:22 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Nov 2013 06:04:22 -0000 Subject: [GHC] #8506: misleading error message for duplicate type class instances In-Reply-To: <045.402f8421fe3a87bb854e369460e2a45b@haskell.org> References: <045.402f8421fe3a87bb854e369460e2a45b@haskell.org> Message-ID: <060.edffb43ce788c3cd35427f0242e527de@haskell.org> #8506: misleading error message for duplicate type class instances --------------------------------------------+------------------------------ Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by carter): GHC should give an erro about multiple class instances, but I guess the renamer phase hits the constants in the instance heads before that multiple declaration conflict would happen. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 6 08:23:47 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Nov 2013 08:23:47 -0000 Subject: [GHC] #8477: Allow inferring ambiguous types In-Reply-To: <045.eba11f97886c50dcee3d55a438abd62f@haskell.org> References: <045.eba11f97886c50dcee3d55a438abd62f@haskell.org> Message-ID: <060.6974b640ae8144e3d9c341e6e43968f0@haskell.org> #8477: Allow inferring ambiguous types -------------------------------------+------------------------------------ Reporter: aavogt | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 8390 -------------------------------------+------------------------------------ Comment (by simonpj): PS: my second bullet was wrong. The ambiguity check for instance declarations doesn't subsume the coverage check. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 6 08:31:56 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Nov 2013 08:31:56 -0000 Subject: [GHC] #8500: Default associated type instances not instantiated In-Reply-To: <047.cfe60fb3dd185127d3393afe6f012f1a@haskell.org> References: <047.cfe60fb3dd185127d3393afe6f012f1a@haskell.org> Message-ID: <062.127f435062a47d353daae00979ab30a1@haskell.org> #8500: Default associated type instances not instantiated -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"6f331d69e50f13626b65ab76de408a49caebd4f6/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="6f331d69e50f13626b65ab76de408a49caebd4f6" Fix marshalling of IfaceAt to and from interface files I had forgotten about Note [CoAxBranch type variables] in CoAxiom This patch fixes Trac #8500 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 6 08:31:56 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Nov 2013 08:31:56 -0000 Subject: [GHC] #8499: Template Haskell: newName not new enough In-Reply-To: <047.8acb3e68d5dc0fc3d9ad54c8933fb55e@haskell.org> References: <047.8acb3e68d5dc0fc3d9ad54c8933fb55e@haskell.org> Message-ID: <062.09b7a0f97a8132684b4501d10730f6b6@haskell.org> #8499: Template Haskell: newName not new enough -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"e470290f87015043af7f297425a722329f726134/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="e470290f87015043af7f297425a722329f726134" Fix checking of shadowed names (fixes Trac #8499) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 6 08:33:32 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Nov 2013 08:33:32 -0000 Subject: [GHC] #8500: Default associated type instances not instantiated In-Reply-To: <047.cfe60fb3dd185127d3393afe6f012f1a@haskell.org> References: <047.cfe60fb3dd185127d3393afe6f012f1a@haskell.org> Message-ID: <062.979a81a62da6e25d832d715d2d4ca50c@haskell.org> #8500: Default associated type instances not instantiated -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"d4da5f8e222f7271e84dfb89d84099503df41467/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="d4da5f8e222f7271e84dfb89d84099503df41467" Test Trac #8500 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 6 08:33:33 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Nov 2013 08:33:33 -0000 Subject: [GHC] #8499: Template Haskell: newName not new enough In-Reply-To: <047.8acb3e68d5dc0fc3d9ad54c8933fb55e@haskell.org> References: <047.8acb3e68d5dc0fc3d9ad54c8933fb55e@haskell.org> Message-ID: <062.f1b40ffb7cb60f4afd72a6083e385b4f@haskell.org> #8499: Template Haskell: newName not new enough -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"a019503ea3651241fa5d71fd1cdf7c8da8dbbf3a/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="a019503ea3651241fa5d71fd1cdf7c8da8dbbf3a" Test Trac #8499 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 6 08:34:25 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Nov 2013 08:34:25 -0000 Subject: [GHC] #8500: Default associated type instances not instantiated In-Reply-To: <047.cfe60fb3dd185127d3393afe6f012f1a@haskell.org> References: <047.cfe60fb3dd185127d3393afe6f012f1a@haskell.org> Message-ID: <062.252593a148b334de72a8e80751db2057@haskell.org> #8500: Default associated type instances not instantiated -------------------------------------------------+------------------------- Reporter: goldfire | Owner: Type: bug | Status: Priority: normal | closed Component: Compiler | Milestone: Resolution: fixed | Version: 7.7 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: | Unknown/Multiple indexed_types/should_compile/T8500 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by simonpj): * status: new => closed * testcase: => indexed_types/should_compile/T8500 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 6 08:34:57 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Nov 2013 08:34:57 -0000 Subject: [GHC] #8499: Template Haskell: newName not new enough In-Reply-To: <047.8acb3e68d5dc0fc3d9ad54c8933fb55e@haskell.org> References: <047.8acb3e68d5dc0fc3d9ad54c8933fb55e@haskell.org> Message-ID: <062.52f0f10994b8f27019ec1f76354cc249@haskell.org> #8499: Template Haskell: newName not new enough -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Template Haskell | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: th/T8499 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonpj): * status: new => closed * testcase: => th/T8499 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 6 08:56:36 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Nov 2013 08:56:36 -0000 Subject: [GHC] #8506: misleading error message for duplicate type class instances In-Reply-To: <045.402f8421fe3a87bb854e369460e2a45b@haskell.org> References: <045.402f8421fe3a87bb854e369460e2a45b@haskell.org> Message-ID: <060.f04d894d834d8e4c837984b004dcd4d3@haskell.org> #8506: misleading error message for duplicate type class instances --------------------------------------------+------------------------------ Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonpj): You are both right. (Poor error message, but it comes from the parser.) Is this better? {{{ T8506.hs:54:16: Unexpected type ?Z? In the class declaration for ?Shapable? A class declaration should have form class Shapable a b c where ... }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 6 09:11:13 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Nov 2013 09:11:13 -0000 Subject: [GHC] #8506: misleading error message for duplicate type class instances In-Reply-To: <045.402f8421fe3a87bb854e369460e2a45b@haskell.org> References: <045.402f8421fe3a87bb854e369460e2a45b@haskell.org> Message-ID: <060.0d619f06cec241ed1061bbe43524e862@haskell.org> #8506: misleading error message for duplicate type class instances --------------------------------------------+------------------------------ Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by carter): that'd be better. It brings attention to the whole "you wrote a class dec rather than an instance like you meant to" Also, the paste above actually gives the following Error (assuming N1 is used rather than One ). Mixed up my examples when sharing {{{ src/Numerical/Types/Shape.hs:88:16: Unexpected type `Z' where type variable expected In the declaration of `Shapable Z' }}} which is a bit inscrutable because it doesn't mention "you're declaring a class" to clarify more, here's the snippet that triggered the original error (i gave a further reduced example above) {{{ {-# LANGUAGE PolyKinds #-} {-# LANGUAGE BangPatterns #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE DeriveDataTypeable #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE TemplateHaskell #-} module Numerical.Types.Nat(Nat(..),nat) where import Data.Typeable import Data.Data import Language.Haskell.TH hiding (reify) data Nat = S !Nat | Z deriving (Eq,Show,Read,Typeable,Data) nat :: Int -> TypeQ nat n | n >= 0 = localNat n | otherwise = error "nat: negative" where localNat 0 = conT 'Z localNat n = conT 'S `appT` localNat (n-1) ---------------------- ---------------------- {-# LANGUAGE PolyKinds #-} {-# LANGUAGE BangPatterns #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE DeriveDataTypeable #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE StandaloneDeriving #-} {-# LANGUAGE CPP #-} {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE NoImplicitPrelude #-} module Numerical.Types.Shape where import Numerical.Types.Nat import Data.Data type N0 = Z type N1= S N0 type N2 = S N1 type N3 = S N2 type N4 = S N3 type N5 = S N4 type N6 = S N5 type N7 = S N6 type N8 = S N7 type N9 = S N8 type N10 = S N9 class Shapable (n :: Nat) where data (Shape n ):: * -- zero rank is boring but lets include it for completeness class Shapable Z where data Shape Z = Shape0 class Shapable (S Z) where data Shape (S Z) = Shape1 {-# UNPACK #-} !Int {- I get the following error src/Numerical/Types/Shape.hs:97:17: Unexpected type `Z' where type variable expected In the declaration of `Shape Z' -} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 6 09:14:35 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Nov 2013 09:14:35 -0000 Subject: [GHC] #8506: misleading error message for duplicate type class instances In-Reply-To: <045.402f8421fe3a87bb854e369460e2a45b@haskell.org> References: <045.402f8421fe3a87bb854e369460e2a45b@haskell.org> Message-ID: <060.b8bd698d7ebc745e39086588fe782a95@haskell.org> #8506: misleading error message for duplicate type class instances --------------------------------------------+------------------------------ Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonpj): Yes, you included the snippet when you opened the ticket. I'll commit the improved message later today. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 6 09:24:02 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Nov 2013 09:24:02 -0000 Subject: [GHC] #7831: Bad fragmentation when allocating many large objects In-Reply-To: <045.1f9dc6d6e509a58f42438bf0fc937d10@haskell.org> References: <045.1f9dc6d6e509a58f42438bf0fc937d10@haskell.org> Message-ID: <060.c072bf0bd93d11f5b6cc49325a22f0cd@haskell.org> #7831: Bad fragmentation when allocating many large objects -------------------------------------+------------------------------------ Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonmar): * cc: simonmar (added) Comment: josef: O'Caml is a bit different, the situation there is fragmentation in the heap itself because the old-generation collector doesn't move objects. We don't have that issue in GHC, at least for small objects, but there's a related issue in the layer beneath the GC (the block allocator) that Edward's program nicely illustrates here. I doubt this is ever an issue in practice. The fragmentation that arises this way is bounded: at worst the fragmentation will be equal to the amount of memory used for large objects. And in most cases (a) it will be less than this because the sizes of large objects are never exactly 0.5MB, and (b) the fragmented space will be used to store small objects, so it won't be wasted. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 6 09:42:41 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Nov 2013 09:42:41 -0000 Subject: [GHC] #8450: can't match type Bool with (), but shouldn't have to In-Reply-To: <044.6258cc11fd2886a6eb3daddcf10a5505@haskell.org> References: <044.6258cc11fd2886a6eb3daddcf10a5505@haskell.org> Message-ID: <059.e1939cbd212e823958b5927f6153aff7@haskell.org> #8450: can't match type Bool with (), but shouldn't have to -------------------------------------+------------------------------------ Reporter: dmwit | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"06aac68dee100b21dc7d304fa90d9baa423507a0/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="06aac68dee100b21dc7d304fa90d9baa423507a0" Refactor the constraint solver (again!) There are three core changes here: a) In the constraint-solver pipeline. Given a work-item 'wi', the old scheme was: let relevant = getRelevantInerts wi interact 'wi' with each constraint in 'relevant' Bu now we have a single step interact 'wi' with the inert-set This turns out to avoid duplication, between getRelevantInerts (which needs to know which are relevant) and the interact step. Simpler, cleaner. This in turn made it sensible to combine the 'spontaneous solve' stage into the 'interact with inerts' stage. b) Wanteds are no longer used to rewrite wanteds. See Trac #8450. This in turn means that the inert set may have - many CFunEqCans with the same LHS - many CTyEqCans with the same LHS Hence the EqualCtList in teh domain of inert_eqs and inert_funeqs c) Some refactoring of the representation of the inert set, Notably inert_dicts and inert_funeqs are indexed by Class and TyCon respectively, so we can easily get all the constraints relevant to that class or tycon There are many knock on effects! This started as a small job but I ended up doing qite a lot. Some error messages in the test suite really did improve as a result of (b) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 6 09:46:55 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Nov 2013 09:46:55 -0000 Subject: [GHC] #8450: can't match type Bool with (), but shouldn't have to In-Reply-To: <044.6258cc11fd2886a6eb3daddcf10a5505@haskell.org> References: <044.6258cc11fd2886a6eb3daddcf10a5505@haskell.org> Message-ID: <059.91df9dcad538b2d0b484b38477574f1c@haskell.org> #8450: can't match type Bool with (), but shouldn't have to -------------------------------------+------------------------------------ Reporter: dmwit | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"8c88d0a9b205a31b1708a7069c4aa417373f9ac3/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="8c88d0a9b205a31b1708a7069c4aa417373f9ac3" Test Trac #8450 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 6 09:47:44 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Nov 2013 09:47:44 -0000 Subject: [GHC] #8450: can't match type Bool with (), but shouldn't have to In-Reply-To: <044.6258cc11fd2886a6eb3daddcf10a5505@haskell.org> References: <044.6258cc11fd2886a6eb3daddcf10a5505@haskell.org> Message-ID: <059.173a842e4075911f1c11b5266710c403@haskell.org> #8450: can't match type Bool with (), but shouldn't have to ------------------------------------------------+-------------------------- Reporter: dmwit | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: typecheck/should_fail/T8450 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by simonpj): * status: new => closed * testcase: => typecheck/should_fail/T8450 * resolution: => fixed Comment: Thank you for the provocation. Things are much better now. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 6 09:52:40 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Nov 2013 09:52:40 -0000 Subject: [GHC] #8504: Provide minor GC residency estimates In-Reply-To: <045.f5811eb3821604b8931221edb7e53e19@haskell.org> References: <045.f5811eb3821604b8931221edb7e53e19@haskell.org> Message-ID: <060.96ee831e840a79192fedafb1b21ab1d0@haskell.org> #8504: Provide minor GC residency estimates -------------------------------+------------------------------------------- Reporter: ezyang | Owner: simonmar Type: feature | Status: new request | Milestone: Priority: lowest | Version: 7.7 Component: Runtime | Keywords: easy System | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 hour) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by simonmar): I'm not against having a higher resolution but lower accuracy residency sample, but it should be something that has to be requested explicitly (I presume your patch above isn't a serious proposal, but just to be clear I don't think it would be a good idea to apply it!). The residency you'll see by using the figures from minor collections is the saw-tooth generational GC pattern. That's fine if you understand why, but we don't want to give users the mistaken impression that their programs have a saw-tooth heap profile. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 6 10:39:26 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Nov 2013 10:39:26 -0000 Subject: [GHC] #7477: reifyInstances can't deal with polykinded type families In-Reply-To: <047.0f99aec0c8f4caa3ebd2125e9160967e@haskell.org> References: <047.0f99aec0c8f4caa3ebd2125e9160967e@haskell.org> Message-ID: <062.567bb4bcbde258874405b6eaf8a2b9b0@haskell.org> #7477: reifyInstances can't deal with polykinded type families -------------------------+------------------------------------------------- Reporter: | Owner: goldfire | Status: new Type: bug | Milestone: 7.8.1 Priority: | Version: 7.7 normal | Keywords: TemplateHaskell TypeFamilies Component: | PolyKinds Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------+------------------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"8944fd3fc5fa7d435f438c5680c8d177257d27e9/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="8944fd3fc5fa7d435f438c5680c8d177257d27e9" Zonk the type in reifyInstances (fixes Trac #7477) A simple oversight, but crucial! tcLHsType was returning F k Int where k is a unification variable that has been unified with * }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 6 10:39:26 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Nov 2013 10:39:26 -0000 Subject: [GHC] #8506: misleading error message for duplicate type class instances In-Reply-To: <045.402f8421fe3a87bb854e369460e2a45b@haskell.org> References: <045.402f8421fe3a87bb854e369460e2a45b@haskell.org> Message-ID: <060.0ef02ba9e0c107cf2cac5cc09ee396b4@haskell.org> #8506: misleading error message for duplicate type class instances --------------------------------------------+------------------------------ Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"38438e1325461f8f6d32b21378cc10584e6b012e/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="38438e1325461f8f6d32b21378cc10584e6b012e" Improve a parser error message (Trac #8506) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 6 10:40:18 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Nov 2013 10:40:18 -0000 Subject: [GHC] #7477: reifyInstances can't deal with polykinded type families In-Reply-To: <047.0f99aec0c8f4caa3ebd2125e9160967e@haskell.org> References: <047.0f99aec0c8f4caa3ebd2125e9160967e@haskell.org> Message-ID: <062.11dc0e7e2df3ad76092bfde0a3afd213@haskell.org> #7477: reifyInstances can't deal with polykinded type families -------------------------+------------------------------------------------- Reporter: | Owner: goldfire | Status: new Type: bug | Milestone: 7.8.1 Priority: | Version: 7.7 normal | Keywords: TemplateHaskell TypeFamilies Component: | PolyKinds Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------+------------------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"37158ff9ee3603c863eee8dcdfd196750fe8847a/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="37158ff9ee3603c863eee8dcdfd196750fe8847a" Test Trac #7477 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 6 10:40:19 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Nov 2013 10:40:19 -0000 Subject: [GHC] #8506: misleading error message for duplicate type class instances In-Reply-To: <045.402f8421fe3a87bb854e369460e2a45b@haskell.org> References: <045.402f8421fe3a87bb854e369460e2a45b@haskell.org> Message-ID: <060.be345805e9a5be3763b6b96fbed5ab45@haskell.org> #8506: misleading error message for duplicate type class instances --------------------------------------------+------------------------------ Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"8a4d858e9df67c35c5f59e2f6382ece02fc4c214/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="8a4d858e9df67c35c5f59e2f6382ece02fc4c214" Test Trac #8506 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 6 10:40:19 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Nov 2013 10:40:19 -0000 Subject: [GHC] #4135: Can't Quote Instance Associated Types in Template Haskell In-Reply-To: <053.188af2ea03c2f430124b5ce57806b9f1@haskell.org> References: <053.188af2ea03c2f430124b5ce57806b9f1@haskell.org> Message-ID: <068.b40ebc29b9afb5f82d165a222e2ef45d@haskell.org> #4135: Can't Quote Instance Associated Types in Template Haskell ----------------------------------------------+---------------------------- Reporter: Ashley Yakeley | Owner: Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Template Haskell | Version: 6.12.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects valid program | (amd64) Test Case: th/T4135 | Difficulty: Unknown Blocking: | Blocked By: 4230 | Related Tickets: ----------------------------------------------+---------------------------- Comment (by Simon Peyton Jones ): In [changeset:"7a318d7d3a1467251b3133c43f01c7372c32904e/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="7a318d7d3a1467251b3133c43f01c7372c32904e" Test for Trac #4135, comment 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 6 10:41:41 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Nov 2013 10:41:41 -0000 Subject: [GHC] #7477: reifyInstances can't deal with polykinded type families In-Reply-To: <047.0f99aec0c8f4caa3ebd2125e9160967e@haskell.org> References: <047.0f99aec0c8f4caa3ebd2125e9160967e@haskell.org> Message-ID: <062.5d4a25431fa9530831a648f792051f8a@haskell.org> #7477: reifyInstances can't deal with polykinded type families -------------------------+------------------------------------------------- Reporter: | Owner: goldfire | Status: closed Type: bug | Milestone: 7.8.1 Priority: | Version: 7.7 normal | Keywords: TemplateHaskell TypeFamilies Component: | PolyKinds Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown fixed | Blocked By: Operating System: | Related Tickets: Unknown/Multiple | Type of failure: | None/Unknown | Test Case: | th/T7477 | Blocking: | -------------------------+------------------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => th/T7477 * resolution: => fixed Comment: Fixed at last. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 6 10:42:20 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Nov 2013 10:42:20 -0000 Subject: [GHC] #8506: misleading error message for duplicate type class instances In-Reply-To: <045.402f8421fe3a87bb854e369460e2a45b@haskell.org> References: <045.402f8421fe3a87bb854e369460e2a45b@haskell.org> Message-ID: <060.bb1ea5b104ada4986c052566acfd6a90@haskell.org> #8506: misleading error message for duplicate type class instances ---------------------------------------------+----------------------------- Reporter: carter | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: parser/should_fail/T8506 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------------+----------------------------- Changes (by simonpj): * status: new => closed * testcase: => parser/should_fail/T8506 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 6 10:46:13 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Nov 2013 10:46:13 -0000 Subject: [GHC] #4230: Template Haskell: less type checking in quotations? In-Reply-To: <046.6e16cb755bdfe4808abc1821a0946b6d@haskell.org> References: <046.6e16cb755bdfe4808abc1821a0946b6d@haskell.org> Message-ID: <061.382af6c6dd488e37f827e7fbde952c80@haskell.org> #4230: Template Haskell: less type checking in quotations? -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: feature request | Status: closed Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: 4125, 4135 | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: Closing this because the [blog:Template%20Haskell%20Proposal TH blog post proposal] is now implemented. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 6 10:46:22 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Nov 2013 10:46:22 -0000 Subject: [GHC] #4135: Can't Quote Instance Associated Types in Template Haskell In-Reply-To: <053.188af2ea03c2f430124b5ce57806b9f1@haskell.org> References: <053.188af2ea03c2f430124b5ce57806b9f1@haskell.org> Message-ID: <068.1803c7dacfe30b4d7197d45163d1ecb4@haskell.org> #4135: Can't Quote Instance Associated Types in Template Haskell ----------------------------------------------+---------------------------- Reporter: Ashley Yakeley | Owner: Type: bug | Status: closed Priority: low | Milestone: 7.6.2 Component: Template Haskell | Version: 6.12.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects valid program | (amd64) Test Case: th/T4135, T4135a | Difficulty: Unknown Blocking: | Blocked By: 4230 | Related Tickets: ----------------------------------------------+---------------------------- Changes (by simonpj): * status: new => closed * testcase: th/T4135 => th/T4135, T4135a * resolution: => fixed Comment: Comment 2 works now, with the new Template Haskell story. I've added a new test `T4135a`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 6 11:25:25 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Nov 2013 11:25:25 -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.bdeadfac137f8a3ce1b5d8173d129bf2@haskell.org> #1480: Template Haskell should allow reification of modules ----------------------------+---------------------------------------------- Reporter: igloo | Owner: Type: feature | Status: closed request | Milestone: 7.8.1 Priority: highest | Version: 7.7 Component: | Keywords: Template Haskell | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Moderate (less than a day) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: 8398 | ----------------------------+---------------------------------------------- Comment (by simonmar): An alternative is to split `dep_mods` into two; the direct imports and the rest. That would avoid growing the `.hi` file. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 6 11:32:04 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Nov 2013 11:32:04 -0000 Subject: [GHC] #4900: DEPENDS pragma In-Reply-To: <046.52f138a2609bf72d7f5381a2c64d358e@haskell.org> References: <046.52f138a2609bf72d7f5381a2c64d358e@haskell.org> Message-ID: <061.1942b61ce18826e29d674e6ab666ab29@haskell.org> #4900: DEPENDS pragma -------------------------------------+------------------------------------ Reporter: cdsmith | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: TH_Depends | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonmar): I still need to review this patch carefully. At first glance it's not obviously right, since we don't normally modify `ModSummary` during the upsweep - the `ModSummary` is something that is supposed to be collected by the downsweep. But I don't have all the details in my head right now, I'll try to come back to this when I have more time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 6 11:55:25 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Nov 2013 11:55:25 -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.ac342f58ec6ca005eb10ba063a94f92b@haskell.org> #1480: Template Haskell should allow reification of modules ----------------------------+---------------------------------------------- Reporter: igloo | Owner: Type: feature | Status: closed request | Milestone: 7.8.1 Priority: highest | Version: 7.7 Component: | Keywords: Template Haskell | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Moderate (less than a day) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: 8398 | ----------------------------+---------------------------------------------- Comment (by simonpj): I don't think splitting `mi_deps` will work, because it lists only the ''home-package'' imports, so we would not thereby find the directly imported modules that happen to be in other packages. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 6 13:47:11 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Nov 2013 13:47:11 -0000 Subject: [GHC] #8198: One-shot mode is buggy w.r.t. hs-boot files In-Reply-To: <044.066addbaba47f1aa4fead928a038d103@haskell.org> References: <044.066addbaba47f1aa4fead928a038d103@haskell.org> Message-ID: <059.9bad133c64c42b7e2c416a7ac7c2bba2@haskell.org> #8198: One-shot mode is buggy w.r.t. hs-boot files -------------------------------------------------+------------------------- Reporter: parcs | Owner: parcs Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Driver | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect warning at | Unknown/Multiple compile-time | Difficulty: Test Case: | Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by simonpj): * cc: simonmar (added) Comment: Simon M would you care to comment? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 6 15:00:46 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Nov 2013 15:00:46 -0000 Subject: [GHC] #4900: DEPENDS pragma In-Reply-To: <046.52f138a2609bf72d7f5381a2c64d358e@haskell.org> References: <046.52f138a2609bf72d7f5381a2c64d358e@haskell.org> Message-ID: <061.d0d93058258d5d8f9465543b666a418c@haskell.org> #4900: DEPENDS pragma -------------------------------------+------------------------------------ Reporter: cdsmith | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: TH_Depends | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by parcs): Replying to [comment:63 simonmar]: > At first glance it's not obviously right, since we don't normally modify `ModSummary` during the upsweep - the `ModSummary` is something that is supposed to be collected by the downsweep. A module's list of usage files can only be determined _after_ compiling the module because the list includes files added by TH's `qAddDependencies`. So one way or another, usage-file information has to be propagated from a previous upsweep to a future downsweep (and to the stability check that follows). I proposed two independent solutions: 1. During the downsweep, look inside the HPT to extract the usage-file information from an existing HMI and stuff it into the !ModSummary. 2. During the upsweep, extract the usage-file information from the new HMI and update the module graph with this information. A future downsweep will use this updated module graph. But these solutions don't exactly satisfy the existing invariants of the downsweep and upsweep. For (1), we shouldn't read the HPT during the downsweep. For (2), we shouldn't update a !ModSummary during the upsweep. But I can't think of another solution. I personally like (1), especially since there are two independent upsweeps now. The patch that Adam attached is an updated version of (2). I think it would help review if a future patch was split into several logical patches. It's not a lot of code but it's somewhat tricky code. This is just my understanding of the state of this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 6 15:04:20 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Nov 2013 15:04:20 -0000 Subject: [GHC] #8198: One-shot mode is buggy w.r.t. hs-boot files In-Reply-To: <044.066addbaba47f1aa4fead928a038d103@haskell.org> References: <044.066addbaba47f1aa4fead928a038d103@haskell.org> Message-ID: <059.c94899e2b7f7eee68835cb41f337d33b@haskell.org> #8198: One-shot mode is buggy w.r.t. hs-boot files -------------------------------------------------+------------------------- Reporter: parcs | Owner: parcs Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Driver | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect warning at | Unknown/Multiple compile-time | Difficulty: Test Case: | Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by parcs): Here's a patch of the change I'm proposing. {{{ #!diff diff --git a/compiler/main/DriverPipeline.hs b/compiler/main/DriverPipeline.hs index 44a6fa5..b4f4844 100644 --- a/compiler/main/DriverPipeline.hs +++ b/compiler/main/DriverPipeline.hs @@ -928,7 +928,16 @@ runPhase (RealPhase (Hsc src_flavour)) input_fn dflags0 PipeState{hsc_env=hsc_env'} <- getPipeState -- Tell the finder cache about this module - mod <- liftIO $ addHomeModuleToFinder hsc_env' mod_name location + -- + -- If we're compiling an hs-boot file in one-shot mode, assume that a + -- corresponding source file exists in the same directory and add that into + -- the finder cache instead, to maintain the invariant that locations in the + -- finder cache correspond to a module's source file only. + mod <- do + src_location <- if isHsBoot src_flavour + then getLocation HsSrcFile mod_name + else return location + liftIO $ addHomeModuleToFinder hsc_env' mod_name src_location -- Make the ModSummary to hand to hscMain let }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 6 15:10:28 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Nov 2013 15:10:28 -0000 Subject: [GHC] #8507: ConstraintKinds TH regression from 7.6 -> 7.7 Message-ID: <044.279c8d9fc60344afededa9adb9a13c1a@haskell.org> #8507: ConstraintKinds TH regression from 7.6 -> 7.7 ----------------------------+---------------------------------------------- Reporter: errge | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.7 Haskell | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects valid program Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | ----------------------------+---------------------------------------------- {{{ {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE ConstraintKinds #-} module ConstraintKindUser where -- type Stringy a = (Read a, Show a) $([d|type Stringy a = (Read a, Show a) |]) }}} Results in this error message: {{{ ConstraintKindUser.hs:7:3: The first argument of a tuple should have kind ?*?, but ?Read a_a2ZZ? has kind ?Constraint? In the type ?(Read a_a2ZZ, Show a_a2ZZ)? In the type declaration for ?Stringy? }}} This is a regression compared to 7.6.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 6 16:21:29 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Nov 2013 16:21:29 -0000 Subject: [GHC] #8312: Annotations in a compiler without interpreter needs a better error message In-Reply-To: <049.9b1a06c08966dd22e1778d2c2d0ba654@haskell.org> References: <049.9b1a06c08966dd22e1778d2c2d0ba654@haskell.org> Message-ID: <064.b7041375e60a223951488b229961bd8e@haskell.org> #8312: Annotations in a compiler without interpreter needs a better error message -------------------------------+--------------------------- Reporter: ablackmore | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+--------------------------- Comment (by Simon Peyton Jones ): In [changeset:"bf3b29323d69b2c6f073885fb896dd4a5c346c02/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="bf3b29323d69b2c6f073885fb896dd4a5c346c02" Tidy up the error messages we get from TH in stage1 (Trac #8312) Instead of panic-ing we now give a sensible message. There is quite a bit of refactoring here too, removing several #ifdef GHCI things }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 6 16:34:04 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Nov 2013 16:34:04 -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.696e411e91a0cfc484a42b3c613bf073@haskell.org> #1480: Template Haskell should allow reification of modules ----------------------------+---------------------------------------------- Reporter: igloo | Owner: Type: feature | Status: closed request | Milestone: 7.8.1 Priority: highest | Version: 7.7 Component: | Keywords: Template Haskell | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Moderate (less than a day) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: 8398 | ----------------------------+---------------------------------------------- Comment (by simonmar): ah yes, good point. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 6 16:38:38 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Nov 2013 16:38:38 -0000 Subject: [GHC] #8312: Annotations in a compiler without interpreter needs a better error message In-Reply-To: <049.9b1a06c08966dd22e1778d2c2d0ba654@haskell.org> References: <049.9b1a06c08966dd22e1778d2c2d0ba654@haskell.org> Message-ID: <064.4ff4f3a5ba6a86584fc22f0b782ee746@haskell.org> #8312: Annotations in a compiler without interpreter needs a better error message -------------------------------+--------------------------- Reporter: ablackmore | Owner: Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: arm Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+--------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: I have at least eliminated the panic: {{{ T8312.hs:6:1: A annotation requires GHC with interpreter support: True Perhaps you are using a stage-1 compiler? In the annotation: {-# ANN g True #-} }}} I'm not sure it's worth a test case, and I don't know how to construct a test that uses the stage1 compiler. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 6 16:53:45 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Nov 2013 16:53:45 -0000 Subject: [GHC] #8278: Improve error message when the same type is imported from two different library versions In-Reply-To: <044.b4ff53b1f7bce9508c7f6f66eb6f72da@haskell.org> References: <044.b4ff53b1f7bce9508c7f6f66eb6f72da@haskell.org> Message-ID: <059.2440068c8fbcfcca0ca0551b23fbe147@haskell.org> #8278: Improve error message when the same type is imported from two different library versions -------------------------------------+------------------------------------ Reporter: Yuras | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"2403fa102559e81d665838a62b2a5de3229a9783/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="2403fa102559e81d665838a62b2a5de3229a9783" Improve printing of errors when the tycons look the same See Trac #8278. Example new message: Couldn't match expected type ?T8278a.Maybe? with actual type ?Maybe a0? NB: ?T8278a.Maybe? is defined in ?T8278a? ?Maybe? is defined in ?Data.Maybe? in package ?base? In the first argument of ?f?, namely ?Nothing? The "NB" is the new bit }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 6 16:56:08 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Nov 2013 16:56:08 -0000 Subject: [GHC] #8278: Improve error message when the same type is imported from two different library versions In-Reply-To: <044.b4ff53b1f7bce9508c7f6f66eb6f72da@haskell.org> References: <044.b4ff53b1f7bce9508c7f6f66eb6f72da@haskell.org> Message-ID: <059.cd10a0a97d68cd8e6fec93ec29901b2a@haskell.org> #8278: Improve error message when the same type is imported from two different library versions -------------------------------------+------------------------------------ Reporter: Yuras | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"9ca32193a82218c18a633d1ae505248d65ef17a4/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="9ca32193a82218c18a633d1ae505248d65ef17a4" Wibbles following fix to Trac #8278 The error message for ghci052 and ghci053 are (still) terrible, because there is shadowing going on in the interactive context. But that's a separate matter. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 6 16:59:35 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Nov 2013 16:59:35 -0000 Subject: [GHC] #8278: Improve error message when the same type is imported from two different library versions In-Reply-To: <044.b4ff53b1f7bce9508c7f6f66eb6f72da@haskell.org> References: <044.b4ff53b1f7bce9508c7f6f66eb6f72da@haskell.org> Message-ID: <059.0faadb553a2a4b1f60a7ef5c2a48d733@haskell.org> #8278: Improve error message when the same type is imported from two different library versions -------------------------------------------------+------------------------- Reporter: Yuras | Owner: Type: feature request | Status: Priority: normal | closed Component: Compiler | Milestone: Resolution: fixed | Version: 7.6.3 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: | Unknown/Multiple typecheck/should_fail/tcfail182 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by simonpj): * status: new => closed * testcase: => typecheck/should_fail/tcfail182 * resolution: => fixed Comment: Good idea. Much improved now I think: {{{ Couldn't match expected type ?T8278a.Maybe? with actual type ?Maybe a0? NB: ?T8278a.Maybe? is defined in ?T8278a? ?Maybe? is defined in ?Data.Maybe? in package ?base? In the first argument of ?f?, namely ?Nothing? }}} However implementing the idea in Comment 2 is much harder. If you think it's important and/or you trip over it a lot in practice, please open a new ticket. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 6 17:21:07 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Nov 2013 17:21:07 -0000 Subject: [GHC] #8198: One-shot mode is buggy w.r.t. hs-boot files In-Reply-To: <044.066addbaba47f1aa4fead928a038d103@haskell.org> References: <044.066addbaba47f1aa4fead928a038d103@haskell.org> Message-ID: <059.8cbf6768ed3afaedd8010cdb2575d21a@haskell.org> #8198: One-shot mode is buggy w.r.t. hs-boot files -------------------------------------------------+------------------------- Reporter: parcs | Owner: parcs Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Driver | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect warning at | Unknown/Multiple compile-time | Difficulty: Test Case: | Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by simonmar): shouldn't we set `ml_hs_file` to `Nothing` in this case, rather than assuming that it is in the same location as the `hs-boot` file? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 6 19:06:40 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Nov 2013 19:06:40 -0000 Subject: [GHC] #8506: misleading error message for duplicate type class instances In-Reply-To: <045.402f8421fe3a87bb854e369460e2a45b@haskell.org> References: <045.402f8421fe3a87bb854e369460e2a45b@haskell.org> Message-ID: <060.1ad651038f2298a1c0f1da45807ccf02@haskell.org> #8506: misleading error message for duplicate type class instances ---------------------------------------------+----------------------------- Reporter: carter | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: parser/should_fail/T8506 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------------+----------------------------- Comment (by carter): awesome, thanks! I merely wanted to highlight the distinction of {{{ src/Numerical/Types/Shape.hs:97:17: Unexpected type `Z' where type variable expected In the declaration of `Shape Z' }}} when theres a data family in the class vs {{{ src/Numerical/Types/Shape.hs:88:16: Unexpected type `Z' where type variable expected In the declaration of `Shapable Z' }}} because it wasn't clear to me, and that was part of why the original original snippet was especially confusing. Namely that it seemed to be saying I couldn't instantiate a data family (in addition to the whole typeclass dec needs to have variables as parameters) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 6 19:59:19 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Nov 2013 19:59:19 -0000 Subject: [GHC] #3620: The seeds generated by split are not independent In-Reply-To: <052.ef1abc8d66f675d62b108c409dd80993@haskell.org> References: <052.ef1abc8d66f675d62b108c409dd80993@haskell.org> Message-ID: <067.f050e61b7ec7248a16ce6681820aca98@haskell.org> #3620: The seeds generated by split are not independent -------------------------------------+------------------------------------ Reporter: NickSmallbone | Owner: rrnewton Type: bug | Status: new Priority: normal | Milestone: _|_ Component: libraries/random | Version: 6.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nfrisby): Are there any plans to adopt the work out of Chalmers from the tf-random package on Hackage into System.Random? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 6 19:59:36 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Nov 2013 19:59:36 -0000 Subject: [GHC] #3575: mkStdGen and split conspire to make some programs predictable In-Reply-To: <047.6485fb2275f266e278f6578e798e2d4e@haskell.org> References: <047.6485fb2275f266e278f6578e798e2d4e@haskell.org> Message-ID: <062.4e6b3dddef655c79f5b29a721d3224cb@haskell.org> #3575: mkStdGen and split conspire to make some programs predictable -------------------------------------+------------------------------------ Reporter: rwbarton | Owner: rrnewton Type: bug | Status: new Priority: normal | Milestone: _|_ Component: libraries/random | Version: 6.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nfrisby): Are there any plans to adopt the work out of Chalmers from the tf-random package on Hackage into System.Random? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 6 20:32:46 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Nov 2013 20:32:46 -0000 Subject: [GHC] #4900: DEPENDS pragma In-Reply-To: <046.52f138a2609bf72d7f5381a2c64d358e@haskell.org> References: <046.52f138a2609bf72d7f5381a2c64d358e@haskell.org> Message-ID: <061.7f37242e64cf2a33c1d4a0582da30eae@haskell.org> #4900: DEPENDS pragma -------------------------------------+------------------------------------ Reporter: cdsmith | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: TH_Depends | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonmar): I don't want to block this fix, since there's a real problem. On the other hand, the fix is not a simple one because both proposed implementations change some key assumption about the flow of data, in what is already a complicated part of the compiler. I think I'm ok with the idea of adding the usg_file information to the ModSummary during the downsweep ''after'' a previous upsweep. I think this is the first patch, correct? But what we need is some careful documentation about how it works, preferably with a worked example ("the second downsweep adds the following information to the ModSummary, but it doesn't cause recompilation because..."). I'm concerned about things like re-summarising modules unnecessarily. The other thing we need is some good tests (the recomp tests are under `driver`), testing for both too much and too little recompilation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 6 21:30:09 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Nov 2013 21:30:09 -0000 Subject: [GHC] #8061: Support for Complex Double in Foreign Function Interface In-Reply-To: <047.6f3593764824d4a0871634eea5731206@haskell.org> References: <047.6f3593764824d4a0871634eea5731206@haskell.org> Message-ID: <062.f282c7d8b44263553ded66533b34672f@haskell.org> #8061: Support for Complex Double in Foreign Function Interface -------------------------------------+------------------------------------ Reporter: dsamperi | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by dsamperi): Hello Carter, Has support for Complex Double been added to GHC/FFI (7.8.1)? What is the status of your alternative to Pat Perry's hs-linear-algebra? Does it cover BLAS and LAPACK, or just BLAS? Thanks, Dominick -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 6 22:41:36 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Nov 2013 22:41:36 -0000 Subject: [GHC] #8061: Support for Complex Double in Foreign Function Interface In-Reply-To: <047.6f3593764824d4a0871634eea5731206@haskell.org> References: <047.6f3593764824d4a0871634eea5731206@haskell.org> Message-ID: <062.1135475fd2f061adec585f4aa6239580@haskell.org> #8061: Support for Complex Double in Foreign Function Interface -------------------------------------+------------------------------------ Reporter: dsamperi | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by carter): hey, 1) nope, and wont until 7.10 at the earliest. That said, theres a pretty easy work around 2) theres a very very easy work around, just use storable instances, some tiny storable vectors and do a wee pointer wrapper! I have that for some C code I wrote for complex numbers. heres an example that does that boxing for a scalar complex double result for dot product. You'll have to write your own wee C wrapper for each thing, but its not much work and will work with a wide range of GHC versions (which is never a bad thing) {{{ /// NOTE: complex valued dot products have a different type than the real float dot products /// this is important to remember! void arrayDotProduct_complex_double(int32_t length, complex_double * left, int32_t leftStride ,complex_double * right,int32_t rightStride, complex_double * resultSingleton); void arrayDotProduct_complex_double(int32_t length, complex_double * left, int32_t leftStride ,complex_double * right,int32_t rightStride, complex_double * resultSingleton){ complex_double result = arrayDotProduct_internal_complex_double(length,left,leftStride,right,rightStride); resultSingleton[0] = result ; } void arrayDotProduct_complex_float(int32_t length, complex_float * left, int32_t leftStride ,complex_float * right,int32_t rightStride, complex_float * resultSingleton); void arrayDotProduct_complex_float(int32_t length, complex_float * left, int32_t leftStride ,complex_float * right,int32_t rightStride, complex_float * resultSingleton){ complex_float result = arrayDotProduct_internal_complex_float(length,left,leftStride,right,rightStride); resultSingleton[0] = result ; } }}} 3) asking me on a ticket is probably the most inefficient way to find out, you'll hear about the initial release very soon though :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 7 00:25:52 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Nov 2013 00:25:52 -0000 Subject: [GHC] #8198: One-shot mode is buggy w.r.t. hs-boot files In-Reply-To: <044.066addbaba47f1aa4fead928a038d103@haskell.org> References: <044.066addbaba47f1aa4fead928a038d103@haskell.org> Message-ID: <059.5d98cb58325ff1334ec3b4cd48a4a644@haskell.org> #8198: One-shot mode is buggy w.r.t. hs-boot files -------------------------------------------------+------------------------- Reporter: parcs | Owner: parcs Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Driver | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect warning at | Unknown/Multiple compile-time | Difficulty: Test Case: | Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by parcs): Replying to [comment:4 simonmar]: > shouldn't we set `ml_hs_file` to `Nothing` in this case, rather than assuming that it is in the same location as the `hs-boot` file? I think that's a fair assumption since we already assume that hi- boot/o-boot files are in the same directory as their corresponding hi/o files. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 7 11:28:24 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Nov 2013 11:28:24 -0000 Subject: [GHC] #7912: Missing symbols from termios.h when linking on Android In-Reply-To: <048.39ee67320a3b643467d3ea5b6b7b5524@haskell.org> References: <048.39ee67320a3b643467d3ea5b6b7b5524@haskell.org> Message-ID: <063.b0638452b939dbd56a40d2362e055ffe@haskell.org> #7912: Missing symbols from termios.h when linking on Android ----------------------------------------+--------------------------- Reporter: neurocyte | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/unix | Version: 7.7 Resolution: | Keywords: Android Operating System: Other | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+--------------------------- Changes (by hvr): * difficulty: => Unknown Comment: would the new `capi` calling convention help here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 7 12:25:36 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Nov 2013 12:25:36 -0000 Subject: [GHC] #7912: Missing symbols from termios.h when linking on Android In-Reply-To: <048.39ee67320a3b643467d3ea5b6b7b5524@haskell.org> References: <048.39ee67320a3b643467d3ea5b6b7b5524@haskell.org> Message-ID: <063.9d5aa1df7fbc39f7dbfda78fd8fbc7af@haskell.org> #7912: Missing symbols from termios.h when linking on Android ----------------------------------------+--------------------------- Reporter: neurocyte | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/unix | Version: 7.7 Resolution: | Keywords: Android Operating System: Other | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+--------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"7ca70fbf7b82bcca945669d043673a06973c1edf/unix"]: {{{ #!CommitTicketReference repository="unix" revision="7ca70fbf7b82bcca945669d043673a06973c1edf" Fix #7912 by using `CApiFFI` for `` imports On Android, the functions imported from `` are actually inlined functions, so we need to wrap them via the `capi` calling convention. Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 7 12:27:34 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Nov 2013 12:27:34 -0000 Subject: [GHC] #7912: Missing symbols from termios.h when linking on Android In-Reply-To: <048.39ee67320a3b643467d3ea5b6b7b5524@haskell.org> References: <048.39ee67320a3b643467d3ea5b6b7b5524@haskell.org> Message-ID: <063.6b090fbf41ebe46cc3942990b6ea53cd@haskell.org> #7912: Missing symbols from termios.h when linking on Android ----------------------------------------+--------------------------- Reporter: neurocyte | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/unix | Version: 7.7 Resolution: fixed | Keywords: Android Operating System: Other | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+--------------------------- Changes (by hvr): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 7 12:30:59 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Nov 2013 12:30:59 -0000 Subject: [GHC] #7359: unix-2.6.0.0 fails to install on mac os x with 7.4.* (works with 7.6.1) In-Reply-To: <053.15621419a346036f18a12d432abb18a5@haskell.org> References: <053.15621419a346036f18a12d432abb18a5@haskell.org> Message-ID: <068.8fc34951ce78a5f2b30711520f52babd@haskell.org> #7359: unix-2.6.0.0 fails to install on mac os x with 7.4.* (works with 7.6.1) -----------------------------------+---------------------------------- Reporter: AndreasVoellmy | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.6.3 Component: libraries/unix | Version: 7.4.1 Resolution: fixed | Keywords: unix package Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+---------------------------------- Changes (by hvr): * status: new => closed * resolution: => fixed Comment: This one is fixed by the workaround in [88bfec0cf55f8c9ad74881d48cf8756c9fe627aa/unix]; if there's still demand, I can also backport this and upload an `unix-2.6.0.2` package... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 7 13:04:14 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Nov 2013 13:04:14 -0000 Subject: [GHC] #8286: fdToHandle docs are wrong about non-blocking mode In-Reply-To: <045.429b5168c8bb34152b036618f35c431c@haskell.org> References: <045.429b5168c8bb34152b036618f35c431c@haskell.org> Message-ID: <060.160c17c8f3058859d5b15824601bb2b3@haskell.org> #8286: fdToHandle docs are wrong about non-blocking mode -------------------------------------+------------------------------------ Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/unix | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Herbert Valerio Riedel ): In [changeset:"48a72e8753a1e90ad24335db9bf241892610375b/unix"]: {{{ #!CommitTicketReference repository="unix" revision="48a72e8753a1e90ad24335db9bf241892610375b" Remove misleading paragraph in `fdToHandle`'s Haddock The removed paragraph is obsolete and does no longer apply to the implementation as noted by Duncan in #8286. Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 7 13:04:33 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Nov 2013 13:04:33 -0000 Subject: [GHC] #8286: fdToHandle docs are wrong about non-blocking mode In-Reply-To: <045.429b5168c8bb34152b036618f35c431c@haskell.org> References: <045.429b5168c8bb34152b036618f35c431c@haskell.org> Message-ID: <060.da49ae4e4230aa35131fe8ef138fca18@haskell.org> #8286: fdToHandle docs are wrong about non-blocking mode -------------------------------------+------------------------------------ Reporter: duncan | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/unix | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by hvr): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 7 13:26:14 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Nov 2013 13:26:14 -0000 Subject: [GHC] #8506: misleading error message for duplicate type class instances In-Reply-To: <045.402f8421fe3a87bb854e369460e2a45b@haskell.org> References: <045.402f8421fe3a87bb854e369460e2a45b@haskell.org> Message-ID: <060.cba54b9182dd8018073df30a5c42d5a5@haskell.org> #8506: misleading error message for duplicate type class instances ---------------------------------------------+----------------------------- Reporter: carter | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: parser/should_fail/T8506 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------------+----------------------------- Comment (by Simon Peyton Jones ): In [changeset:"384398b3eb2bc36a3e7b42a51495bd89398075b5/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="384398b3eb2bc36a3e7b42a51495bd89398075b5" Allow optional 'family' and 'instance' keywords in associated type instances This is to allow class C a where type family F a type instance F a = Bool instance C Int where type instance F Int = Char Plus minor improvements relating to Trac #8506 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 7 13:26:14 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Nov 2013 13:26:14 -0000 Subject: [GHC] #8507: ConstraintKinds TH regression from 7.6 -> 7.7 In-Reply-To: <044.279c8d9fc60344afededa9adb9a13c1a@haskell.org> References: <044.279c8d9fc60344afededa9adb9a13c1a@haskell.org> Message-ID: <059.d707fa0138f4e7bed284fe443ba2609c@haskell.org> #8507: ConstraintKinds TH regression from 7.6 -> 7.7 ----------------------------------------------+---------------------------- Reporter: errge | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by Simon Peyton Jones ): In [changeset:"fa8b20af798c85d4a0b6faf266c67d0c9ab178a9/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="fa8b20af798c85d4a0b6faf266c67d0c9ab178a9" Fix oversight in comverting tuples from TH to HsSyn (Trac #8507) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 7 13:32:14 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Nov 2013 13:32:14 -0000 Subject: [GHC] #8507: ConstraintKinds TH regression from 7.6 -> 7.7 In-Reply-To: <044.279c8d9fc60344afededa9adb9a13c1a@haskell.org> References: <044.279c8d9fc60344afededa9adb9a13c1a@haskell.org> Message-ID: <059.2a4cd2aea73db8483a4b11b5cc748544@haskell.org> #8507: ConstraintKinds TH regression from 7.6 -> 7.7 ----------------------------------------------+---------------------------- Reporter: errge | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Template Haskell | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: th/T8507 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Changes (by simonpj): * status: new => closed * testcase: => th/T8507 * resolution: => fixed Comment: Thanks -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 7 13:56:47 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Nov 2013 13:56:47 -0000 Subject: [GHC] #8305: ghci macros override built-ins for command expansion In-Reply-To: <047.fc409110f08eee40d2b732450d9304f1@haskell.org> References: <047.fc409110f08eee40d2b732450d9304f1@haskell.org> Message-ID: <062.0bd2ad604fcd6739854dbb7167eac741@haskell.org> #8305: ghci macros override built-ins for command expansion -------------------------------------+------------------------------------ Reporter: rwbarton | Owner: rwbarton Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8113 -------------------------------------+------------------------------------ Comment (by Austin Seipp ): In [changeset:"b459c35744d067ee05674012323d13a49bc09ea2/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="b459c35744d067ee05674012323d13a49bc09ea2" Add docs for #8305 Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 7 13:57:52 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Nov 2013 13:57:52 -0000 Subject: [GHC] #8089: Implementation of GHC.Event.Poll.poll is broken due to bad coercion In-Reply-To: <045.7e2f7bf1f77ecf8607cd3966531ffeb1@haskell.org> References: <045.7e2f7bf1f77ecf8607cd3966531ffeb1@haskell.org> Message-ID: <060.266d87ae8e4da3488dfb3d93e106f428@haskell.org> #8089: Implementation of GHC.Event.Poll.poll is broken due to bad coercion -------------------------------+------------------------------------------- Reporter: merijn | Owner: thoughtpolice Type: bug | Status: closed Priority: normal | Milestone: Component: | Version: 7.6.3 libraries/base | Keywords: patch Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: crash | Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: I reproduced this on my OS X machine but didn't push it, it seems. The patches to base are pushed now; thanks Merijn, sorry for the delay. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 7 13:58:14 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Nov 2013 13:58:14 -0000 Subject: [GHC] #8505: Arrows example error In-Reply-To: <045.4a3e76cb1e6689edca76590e96afe352@haskell.org> References: <045.4a3e76cb1e6689edca76590e96afe352@haskell.org> Message-ID: <060.3f635a9afe5b73140ac6c106c00e13b2@haskell.org> #8505: Arrows example error --------------------------------------+------------------------------------ Reporter: pdfrod | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: Documentation | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Documentation bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 7 13:58:34 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Nov 2013 13:58:34 -0000 Subject: [GHC] #8305: ghci macros override built-ins for command expansion In-Reply-To: <047.fc409110f08eee40d2b732450d9304f1@haskell.org> References: <047.fc409110f08eee40d2b732450d9304f1@haskell.org> Message-ID: <062.2337abe16b4b58549bb58c53eeb6bc6c@haskell.org> #8305: ghci macros override built-ins for command expansion -------------------------------------+------------------------------------ Reporter: rwbarton | Owner: rwbarton Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8113 -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: I went ahead and wrote some up myself based on Reid's examples. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 7 14:08:47 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Nov 2013 14:08:47 -0000 Subject: [GHC] #8319: Simplifier ticks exhausted (need -fsimpl-tick-factor=955) In-Reply-To: <047.52cf735ac7af61618a42a5746ffd4202@haskell.org> References: <047.52cf735ac7af61618a42a5746ffd4202@haskell.org> Message-ID: <062.779283bd13ac560580a8011e81b18a51@haskell.org> #8319: Simplifier ticks exhausted (need -fsimpl-tick-factor=955) ---------------------------------------+----------------------------------- Reporter: ruudkoot | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Comment (by simonpj): I've found out what is going on. (What follows is an aide-memoire for me.) There is a huge function of this form: {{{ f = \x -> let BIG BIG BIG in case ... of p1 -> (# a, b, c, d #) p2 -> (# a, b, c, d #) ... p2 -> (# a, b, c, d #) }}} As things stand, in `CoreUnfold`, unboxed tuples don't count towards the size of the express, but DO count towards the result discount. See `Note [Unboxed tuple size and result discount]`. As a result, functions like `f` can be very big, but have a massive result discount, and hence can be inlined like crazy. This blows up the size of the test program. The obvious solution is to nuke the discount, but I need check performance runs carefully. This comment just records my progress. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 7 14:22:34 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Nov 2013 14:22:34 -0000 Subject: [GHC] #7200: template-haskell-2.7.0.0 fails to build with GHC 7.0.4 due to missing pragma In-Reply-To: <044.3e99478eb756e411a5a6700a8a44d5a0@haskell.org> References: <044.3e99478eb756e411a5a6700a8a44d5a0@haskell.org> Message-ID: <059.85173842e0aa710be14be954c27a86ac@haskell.org> #7200: template-haskell-2.7.0.0 fails to build with GHC 7.0.4 due to missing pragma -------------------------------------+------------------------------------ Reporter: tibbe | Owner: duncan Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Template Haskell | Version: 7.0.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by hvr): * cc: hvr (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 7 15:19:57 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Nov 2013 15:19:57 -0000 Subject: [GHC] #8508: Inlining Unsaturated Function Applications Message-ID: <047.6c0b52cec482b1da0a412a581c0dd5bf@haskell.org> #8508: Inlining Unsaturated Function Applications ------------------------------+-------------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Runtime performance bug (amd64) | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- After trying a simple test, I noticed some strange performance results from stylistic changes to the code. For example, {{{#!haskell import qualified Data.Vector.Unboxed as U {-# INLINE f #-} f :: U.Vector Int -> U.Vector Int -> U.Vector Int f = U.zipWith (+) -- version 1 --f x = U.zipWith (+) x -- version 2 --f x = (U.zipWith (+) x) . id -- version 3 --f x y = U.zipWith (+) x y -- version 4 main = do let iters = 100 dim = 221184 y = U.replicate dim 0 :: U.Vector Int let ans = iterate (f y) y !! iters putStr $ (show $ U.foldl1' (+) ans) }}} Versions 1 and 2 of `f` run in 1.6 seconds, while versions 3 and 4 run in 0.09 seconds (with vector-0.10.9.1 and GHC 7.6.2, compiling with -O2). According to an answer on the Vector trac (link below), this problem is because GHC only inlines on saturated function applications. Is there any way to expand the cases when GHC inlines to avoid having coding style affect performance? * [https://github.com/haskell/vector/issues/4 Vector Trac] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 7 17:14:40 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Nov 2013 17:14:40 -0000 Subject: [GHC] #8099: Alternate syntax for indicating when a function is "fully applied" for purposes of inlining In-Reply-To: <048.1fce5dd08fe08fe19b78be2cb1ec14d9@haskell.org> References: <048.1fce5dd08fe08fe19b78be2cb1ec14d9@haskell.org> Message-ID: <063.06bc552218c1be55ca8652449e997ba9@haskell.org> #8099: Alternate syntax for indicating when a function is "fully applied" for purposes of inlining -------------------------------------+------------------------------------ Reporter: jberryman | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): Copied from #8508. After trying a simple test, I noticed some strange performance results from stylistic changes to the code. For example, {{{#!haskell import qualified Data.Vector.Unboxed as U {-# INLINE f #-} f :: U.Vector Int -> U.Vector Int -> U.Vector Int f = U.zipWith (+) -- version 1 --f x = U.zipWith (+) x -- version 2 --f x = (U.zipWith (+) x) . id -- version 3 --f x y = U.zipWith (+) x y -- version 4 main = do let iters = 100 dim = 221184 y = U.replicate dim 0 :: U.Vector Int let ans = iterate (f y) y !! iters putStr $ (show $ U.foldl1' (+) ans) }}} Versions 1 and 2 of `f` run in 1.6 seconds, while versions 3 and 4 run in 0.09 seconds (with vector-0.10.9.1 and GHC 7.6.2, compiling with -O2). According to an answer on the Vector trac (link below), this problem is because GHC only inlines on saturated function applications. Is there any way to expand the cases when GHC inlines to avoid having coding style affect performance? * [https://github.com/haskell/vector/issues/4 Vector Trac] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 7 17:15:04 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Nov 2013 17:15:04 -0000 Subject: [GHC] #8508: Inlining Unsaturated Function Applications In-Reply-To: <047.6c0b52cec482b1da0a412a581c0dd5bf@haskell.org> References: <047.6c0b52cec482b1da0a412a581c0dd5bf@haskell.org> Message-ID: <062.bde36ab2c77058764e099302d8e1e027@haskell.org> #8508: Inlining Unsaturated Function Applications --------------------------------------------+------------------------------ Reporter: crockeea | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by simonpj): * status: new => closed * resolution: => duplicate Comment: Dup of #8508. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 7 17:15:48 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Nov 2013 17:15:48 -0000 Subject: [GHC] #8099: Alternate syntax for indicating when a function is "fully applied" for purposes of inlining In-Reply-To: <048.1fce5dd08fe08fe19b78be2cb1ec14d9@haskell.org> References: <048.1fce5dd08fe08fe19b78be2cb1ec14d9@haskell.org> Message-ID: <063.13c306309540c134d92f4035aa4afb7e@haskell.org> #8099: Alternate syntax for indicating when a function is "fully applied" for purposes of inlining -------------------------------------+------------------------------------ Reporter: jberryman | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): No great difficulty to implement something here, if y'all can converge on a syntax. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 7 18:48:16 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Nov 2013 18:48:16 -0000 Subject: [GHC] #8099: Alternate syntax for indicating when a function is "fully applied" for purposes of inlining In-Reply-To: <048.1fce5dd08fe08fe19b78be2cb1ec14d9@haskell.org> References: <048.1fce5dd08fe08fe19b78be2cb1ec14d9@haskell.org> Message-ID: <063.ef4e00f0b95d5d4a3af8fa2150853284@haskell.org> #8099: Alternate syntax for indicating when a function is "fully applied" for purposes of inlining -------------------------------------+------------------------------------ Reporter: jberryman | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by carter): simon, you're forgetting version 5! : {{{ f = \ x y -> ( U.zipWith (+) x y) }}} I think thats the "maximally inlining" way to define that procedure. Its also how i'm writing quite a bit of my performance sensitive code, because a) this way inlining is independent of using it point free or not b) it saturates all the functions in the body of the procedure c) the way the end user uses the code won't impact when / if inlining happens :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 7 19:46:12 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Nov 2013 19:46:12 -0000 Subject: [GHC] #8099: Alternate syntax for indicating when a function is "fully applied" for purposes of inlining In-Reply-To: <048.1fce5dd08fe08fe19b78be2cb1ec14d9@haskell.org> References: <048.1fce5dd08fe08fe19b78be2cb1ec14d9@haskell.org> Message-ID: <063.163d9da45361248e8f7c576f0fb5014a@haskell.org> #8099: Alternate syntax for indicating when a function is "fully applied" for purposes of inlining -------------------------------------+------------------------------------ Reporter: jberryman | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by crockeea): * cc: ecrockett0@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 7 21:00:59 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Nov 2013 21:00:59 -0000 Subject: [GHC] #8199: Get rid of HEAP_ALLOCED In-Reply-To: <045.61ceff1405fed9aab9c8f0fda5e9d453@haskell.org> References: <045.61ceff1405fed9aab9c8f0fda5e9d453@haskell.org> Message-ID: <060.f45163f549ebeaf165d4c4a9c5c72b93@haskell.org> #8199: Get rid of HEAP_ALLOCED ----------------------------+---------------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.7 Component: | Keywords: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Project (more than a week) Operating System: | Blocked By: 5435 Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Comment (by ezyang): Simon and I chatted about how to move this patchset forward last night on IRC, I'm recording the main points here for posterity: * Static closures originally did not work on Windows with shared libs. Since these are now all copied to dynamic heap, it should be possible to reinstate the Int/Char static closure optimization, among other things. * This is a good step towards supporting multiple RTSes. However, we would need to store the indirection table at an offset from BaseReg. It's not obvious to me how to go about doing that, since we still need some cooperation from the linker to manage all the offsets. I ran some quick tests on the impact of this patch on the startup time of GHC. It seems to add something like 0.02s to initialization time, which is quite reasonable. Simon's primary other concern is binary size. The primary things that are inflating binary size in this patch are as follows: * We are using movq (memory-to-register) instead of movl (constant-to- register). * If we were moving a static constructor into memory, we now need to do it in two instructions, since there are no memory-to-memory movs: {{{ - movq $s_closure+1,-24(%rbp) + movq s_static_closure_ind,%rax + movq %rax,-24(%rbp) }}} * The closures stored in the indirection tables are tagged, which means that if the code expects an untagged closure, we need an extra instruction to deal with it: {{{ - movl $Main_and2_closure,%ebx + movq Main_and2_static_closure_ind,%rbx + andq $-8,%rbx }}} * The indirections table takes up one word per static closure * The initialization code imposes a per-module cost I don't know which of these are the biggest offenders yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 8 00:33:16 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Nov 2013 00:33:16 -0000 Subject: [GHC] #8433: forkProcess masks async exceptions inside the child process In-Reply-To: <044.3cf534b848ce6e2def27d6179964a4ca@haskell.org> References: <044.3cf534b848ce6e2def27d6179964a4ca@haskell.org> Message-ID: <059.886a061831a35daaba268974b732c958@haskell.org> #8433: forkProcess masks async exceptions inside the child process -----------------------------------+------------------------------------ Reporter: joeyh | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/unix | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+------------------------------------ Comment (by hvr): Here's a simple way to reproduce: {{{#!hs System.Posix.Process.forkProcess $ print =<< Control.Exception.getMaskingState }}} outputs `MaskedInterrupt` with GHC 7.6.3 on Linux -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 8 01:18:01 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Nov 2013 01:18:01 -0000 Subject: [GHC] #8224: Excessive system time -- new IO manager problem? In-Reply-To: <047.560f2473b19a53c27f0a194339ba0f97@haskell.org> References: <047.560f2473b19a53c27f0a194339ba0f97@haskell.org> Message-ID: <062.23051df4a96f5e709fa1c9e7003a2ec7@haskell.org> #8224: Excessive system time -- new IO manager problem? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Resolution: | Keywords: IO Manager, Operating System: Linux | System Time Type of failure: Runtime | Architecture: x86_64 (amd64) performance bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by kazu-yamamoto): * cc: kazu@?, simonmar (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 8 04:50:03 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Nov 2013 04:50:03 -0000 Subject: [GHC] #8509: Doc Formatting - Patch Included Message-ID: <047.0136021a5f52b8cacd4f472da4a4b00e@haskell.org> #8509: Doc Formatting - Patch Included -------------------------------------+------------------------------------- Reporter: cschneid | Owner: Type: bug | Status: new Priority: low | Milestone: Component: | Version: 7.6.3 libraries/directory | Operating System: Unknown/Multiple Keywords: | Type of failure: Documentation Architecture: Unknown/Multiple | bug Difficulty: Easy (less than 1 | Test Case: hour) | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Attached is a patch to fixup a bit of doc formatting in the removeDirectory function. The error cases rendered wrong in a few cases, was just missing a bit of markup. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 8 09:24:59 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Nov 2013 09:24:59 -0000 Subject: [GHC] #4268: Warning for ANN pragmas when GHCi is not supported (was: Annotation extension needs a flag) In-Reply-To: <047.ede29838e1cb563fb2d34f66fbf6c1b7@haskell.org> References: <047.ede29838e1cb563fb2d34f66fbf6c1b7@haskell.org> Message-ID: <062.d24f35e70a1154bfb98c540c5f100de1@haskell.org> #4268: Warning for ANN pragmas when GHCi is not supported -------------------------------+------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.0.4 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | -------------------------------+------------------------------------------- Changes (by simonmar): * priority: normal => high * milestone: 7.6.2 => 7.8.1 Comment: We don't want a flag for the ANN pragma, because pragmas don't normally have flags to enable them, they are unconditionally enabled. However, ANN might not be supported if GHC is built without GHCi support (say on a platform that doesn't have GHCi support), so in those cases we want to emit a warning. Therefore this ticket is now for adding a warning when an ANN pragma is being ignored. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 8 09:42:10 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Nov 2013 09:42:10 -0000 Subject: [GHC] #8199: Get rid of HEAP_ALLOCED In-Reply-To: <045.61ceff1405fed9aab9c8f0fda5e9d453@haskell.org> References: <045.61ceff1405fed9aab9c8f0fda5e9d453@haskell.org> Message-ID: <060.2b9ed5816909a9818b07e8efddee8308@haskell.org> #8199: Get rid of HEAP_ALLOCED ----------------------------+---------------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.7 Component: | Keywords: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Project (more than a week) Operating System: | Blocked By: 5435 Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Comment (by simonmar): FYI, I think you uploaded the wrong patch for the latest patch (version 4). Points 1 and 2 are unavoidable. Point 3 is interesting - I think we could probably do better there, but we should look at the context a bit more. In many cases where we have a tagged pointer, we take the tag into account when operating on it (e.g. field index), but here it looks like we're just unconditionally zeroing the tag bits. Point 4 might be improved by overlapping the indirection word with the closure itself. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 8 09:46:30 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Nov 2013 09:46:30 -0000 Subject: [GHC] #4268: Warning for ANN pragmas when GHCi is not supported In-Reply-To: <047.ede29838e1cb563fb2d34f66fbf6c1b7@haskell.org> References: <047.ede29838e1cb563fb2d34f66fbf6c1b7@haskell.org> Message-ID: <062.b17fb5df35b40d7735aa1eb353ea8f5c@haskell.org> #4268: Warning for ANN pragmas when GHCi is not supported -------------------------------+------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.0.4 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | -------------------------------+------------------------------------------- Comment (by nomeata): According to #8312, Annotations will require a `-X` flag in the future, and in a non-GHCi-compiler, we still get an error (not a warning), requiring distributions to patch annotations out of the code. In light of #8312, do you still think that it should be a warning, and not an error? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 8 09:47:44 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Nov 2013 09:47:44 -0000 Subject: [GHC] #8198: One-shot mode is buggy w.r.t. hs-boot files In-Reply-To: <044.066addbaba47f1aa4fead928a038d103@haskell.org> References: <044.066addbaba47f1aa4fead928a038d103@haskell.org> Message-ID: <059.d78c2f9657e24c986b28d355ba816e2e@haskell.org> #8198: One-shot mode is buggy w.r.t. hs-boot files -------------------------------------------------+------------------------- Reporter: parcs | Owner: parcs Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Driver | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect warning at | Unknown/Multiple compile-time | Difficulty: Test Case: | Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by simonmar): FC and MLC? I don't think we make that assumption in one-shot mode. Why make the assumption if we don't need to? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 8 09:51:55 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Nov 2013 09:51:55 -0000 Subject: [GHC] #4268: Warning for ANN pragmas when GHCi is not supported In-Reply-To: <047.ede29838e1cb563fb2d34f66fbf6c1b7@haskell.org> References: <047.ede29838e1cb563fb2d34f66fbf6c1b7@haskell.org> Message-ID: <062.c3ffafc8ae4a9266eaeb006e9c5d22db@haskell.org> #4268: Warning for ANN pragmas when GHCi is not supported -------------------------------+------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.0.4 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | -------------------------------+------------------------------------------- Comment (by nomeata): Nevermind, #8312 was not about the `-X` flag; that was just a discussion on the mailing lists. So basically you are saying that we should replace the error message introduced in #8312 by a warning, right? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 8 09:52:29 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Nov 2013 09:52:29 -0000 Subject: [GHC] #4268: Warning for ANN pragmas when GHCi is not supported In-Reply-To: <047.ede29838e1cb563fb2d34f66fbf6c1b7@haskell.org> References: <047.ede29838e1cb563fb2d34f66fbf6c1b7@haskell.org> Message-ID: <062.834dfa1e2c6875ba8605679e679432f8@haskell.org> #4268: Warning for ANN pragmas when GHCi is not supported -------------------------------+------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.0.4 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | -------------------------------+------------------------------------------- Comment (by simonmar): Thanks for the pointer to #8312, but I don't see where it says that annotations will require a flag, could you help me out? Yes, I think it should be a warning, not an error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 8 09:54:02 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Nov 2013 09:54:02 -0000 Subject: [GHC] #4268: Warning for ANN pragmas when GHCi is not supported In-Reply-To: <047.ede29838e1cb563fb2d34f66fbf6c1b7@haskell.org> References: <047.ede29838e1cb563fb2d34f66fbf6c1b7@haskell.org> Message-ID: <062.51d0e99392db8f08d7e8777115ff3737@haskell.org> #4268: Warning for ANN pragmas when GHCi is not supported -------------------------------+------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.0.4 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: Other | Blocked By: Test Case: | Related Tickets: 8312, 5105 Blocking: | -------------------------------+------------------------------------------- Changes (by simonmar): * related: => 8312, 5105 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 8 09:54:14 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Nov 2013 09:54:14 -0000 Subject: [GHC] #4268: Warning for ANN pragmas when GHCi is not supported In-Reply-To: <047.ede29838e1cb563fb2d34f66fbf6c1b7@haskell.org> References: <047.ede29838e1cb563fb2d34f66fbf6c1b7@haskell.org> Message-ID: <062.695f9ae1a15c4649e85084dcfd8b9e08@haskell.org> #4268: Warning for ANN pragmas when GHCi is not supported -------------------------------+------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.0.4 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: Other | Blocked By: Test Case: | Related Tickets: #8312, #5105 Blocking: | -------------------------------+------------------------------------------- Changes (by simonmar): * related: 8312, 5105 => #8312, #5105 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 8 10:51:45 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Nov 2013 10:51:45 -0000 Subject: [GHC] #8037: GHC panic when compiling unsafeCoerce In-Reply-To: <053.e4953aa5d0e13b80857e846abc34ebf7@haskell.org> References: <053.e4953aa5d0e13b80857e846abc34ebf7@haskell.org> Message-ID: <068.6347eb90714a28555af3f6d8dc4dae57@haskell.org> #8037: GHC panic when compiling unsafeCoerce ---------------------------------+------------------------------------ Reporter: ghc@? | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"a1b6932419a2d425b2a3b7672926a0f9c368f234/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a1b6932419a2d425b2a3b7672926a0f9c368f234" Make worker/wrapper robust to bogus unsafeCorece Fixes Trac #8037 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 8 10:52:29 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Nov 2013 10:52:29 -0000 Subject: [GHC] #8037: GHC panic when compiling unsafeCoerce In-Reply-To: <053.e4953aa5d0e13b80857e846abc34ebf7@haskell.org> References: <053.e4953aa5d0e13b80857e846abc34ebf7@haskell.org> Message-ID: <068.7711b0bcacfe7e6bfd9db0763f9167fd@haskell.org> #8037: GHC panic when compiling unsafeCoerce ---------------------------------+------------------------------------ Reporter: ghc@? | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"9441b7fbf952adf9a3a4402167ba40d8d2166d98/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="9441b7fbf952adf9a3a4402167ba40d8d2166d98" Test Trac #8037 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 8 10:56:24 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Nov 2013 10:56:24 -0000 Subject: [GHC] #8037: GHC panic when compiling unsafeCoerce In-Reply-To: <053.e4953aa5d0e13b80857e846abc34ebf7@haskell.org> References: <053.e4953aa5d0e13b80857e846abc34ebf7@haskell.org> Message-ID: <068.662b6d0c127ecdd22a8c4e2fbf086f4d@haskell.org> #8037: GHC panic when compiling unsafeCoerce -------------------------------------------------+------------------------- Reporter: ghc@? | Owner: Type: bug | Status: Priority: normal | closed Component: Compiler | Milestone: Resolution: fixed | Version: 7.6.1 Operating System: MacOS X | Keywords: Type of failure: None/Unknown | Architecture: Test Case: stranal/should_compile/T8037 | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by simonpj): * status: new => closed * testcase: => stranal/should_compile/T8037 * resolution: => fixed Comment: Thanks. I've robustified this. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 8 11:15:09 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Nov 2013 11:15:09 -0000 Subject: [GHC] #8433: forkProcess masks async exceptions inside the child process In-Reply-To: <044.3cf534b848ce6e2def27d6179964a4ca@haskell.org> References: <044.3cf534b848ce6e2def27d6179964a4ca@haskell.org> Message-ID: <059.71ad26a5cdf417783c8bdde8c6ef6f3a@haskell.org> #8433: forkProcess masks async exceptions inside the child process -----------------------------------+------------------------------------ Reporter: joeyh | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/unix | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+------------------------------------ Comment (by hvr): Potential fix: {{{#!hs forkProcess :: IO () -> IO ProcessID forkProcess action = do -- wrap action to re-establish caller's masking state, as -- 'forkProcessPrim' starts in 'MaskedInterruptible' state by -- default; see also #1048 mstate <- getMaskingState let action' = case mstate of Unmasked -> unsafeUnmask action MaskedInterruptible -> action MaskedUninterruptible -> uninterruptibleMask_ action bracket (newStablePtr (runIO action')) freeStablePtr (\stable -> throwErrnoIfMinus1 "forkProcess" (forkProcessPrim stable)) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 8 11:38:16 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Nov 2013 11:38:16 -0000 Subject: [GHC] #8510: Clear up what extensions are needed at a Template Haskell splice site Message-ID: <046.31fc5da448545a65cf9e299ef73abdd3@haskell.org> #8510: Clear up what extensions are needed at a Template Haskell splice site ------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Suppose you write {{{ module M where data T = ... $(cleverThFunction ''T) }}} where `cleverThFunction` is some Template Haskell code in a library somewhere. Question: * '''If `cleverThFunction` generates code that uses `GADTs`, or `ConstraintKinds`, or `TypeFamilies` or whatnot, do those language extension flags have to be in force in module M, or only at the definition of `cleverThFunction`?''' Currently the situation is anarchic; see below. It should be made tidy. My personal preference is to say that the extensions must be in force in the definition of `cleverThFunction`, but '''not''' at the splice site. Reason: the client doesn't know or care how `cleverThFunction` works. This decision would be compatible with the handling of overlapping instances. Gergely writes: There are a lot of extensions that simply can't be used with TH: {{{ - n+k, - RecursiveDo, - TransformListComp, - Arrows, - ImplicitParams, - TupleSections, - Monadcomprehensions. }}} The rest can be grouped into two parts. The following extensions still work when spliced in without the corresponding language pragma: {{{ - UnicodeSyntax, - LambdaCase, - NamedFieldPuns, - RecordWildCards, - DataTypeContexts (and you get rid of the deprecation warning generation this way :)), - ConstraintKind, - MagicHash (note that UnboxedTuples is in the other part), - TraditionalRecordSyntax, - MultiWayIf, - GADTs (extra nice example at the end of this message). }}} The following needs the pragma at the place of splicing: {{{ - PostfixOperators, - ScopedTypeVariables, - Rank2, RankN, - deriving typeable and data, - UnboxedTuples, - ViewPatterns, - ParallelListComp, - ExistentialQuantification, - EmptyDataDecls, - TypeFamilies, - MultiParamTypeClasses, - FunctionalDependencies. }}} I don't see any trivial distinction, like based on Reader vs Typechecker, or anything like that. In particular * Note `ViewPatterns` vs `LambdaCase`. * Note `GADTs` vs `Rank2`. A very interesting example is `ExplicitForAll`. The AST for polymorphic functions always have explicit foralls in TH.Syntax; so there is no way to require the user at the point of splicing to enable the language extension. GADTs are cool too: {{{ {-# LANGUAGE TemplateHaskell #-} -- No need for GADTs at all! -- {-# LANGUAGE GADTs #-} $([d| data Foo where Foo1 :: Int -> Foo Foo2 :: String -> Foo f1 :: Foo f1 = Foo1 5 f :: Foo -> Either Int String f (Foo1 n) = Left n f (Foo2 s) = Right s |]) main = print (f f1) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 8 11:39:08 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Nov 2013 11:39:08 -0000 Subject: [GHC] #8510: Clear up what extensions are needed at a Template Haskell splice site In-Reply-To: <046.31fc5da448545a65cf9e299ef73abdd3@haskell.org> References: <046.31fc5da448545a65cf9e299ef73abdd3@haskell.org> Message-ID: <061.204e7e42f2270ea78c28efae7dad461d@haskell.org> #8510: Clear up what extensions are needed at a Template Haskell splice site -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): Note that if `cleverThFunction` uses explicit data constructors to construct a syntax tree, it doesn't need ANY language extension flags. Maybe that is acceptable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 8 12:16:07 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Nov 2013 12:16:07 -0000 Subject: [GHC] #8433: forkProcess masks async exceptions inside the child process In-Reply-To: <044.3cf534b848ce6e2def27d6179964a4ca@haskell.org> References: <044.3cf534b848ce6e2def27d6179964a4ca@haskell.org> Message-ID: <059.88d2cf123df1c2a5086660b5708496bb@haskell.org> #8433: forkProcess masks async exceptions inside the child process -----------------------------------+------------------------------------ Reporter: joeyh | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/unix | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+------------------------------------ Comment (by Herbert Valerio Riedel ): In [changeset:"897d66ad9d77d17dae1b5ac94af792e671a76c13/unix"]: {{{ #!CommitTicketReference repository="unix" revision="897d66ad9d77d17dae1b5ac94af792e671a76c13" Fix `forkProcess` to inherit caller's `MaskingState` ...and while at it, use `bracket` to fix a potential resource leak due to `freeStablePtr` not being called if `throwErrnoIfMinus1` throws an exception. This fixes #8433 Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 8 12:16:07 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Nov 2013 12:16:07 -0000 Subject: [GHC] #8433: forkProcess masks async exceptions inside the child process In-Reply-To: <044.3cf534b848ce6e2def27d6179964a4ca@haskell.org> References: <044.3cf534b848ce6e2def27d6179964a4ca@haskell.org> Message-ID: <059.9302e7a881919d6b1847d5aae790aa5f@haskell.org> #8433: forkProcess masks async exceptions inside the child process -----------------------------------+------------------------------------ Reporter: joeyh | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/unix | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+------------------------------------ Comment (by Herbert Valerio Riedel ): In [changeset:"17192d89e642c463a1987fa3cc5cca2eb546bec7/unix"]: {{{ #!CommitTicketReference repository="unix" revision="17192d89e642c463a1987fa3cc5cca2eb546bec7" Add `forkProcessWithUnmask` function This seemed to be an obvious addition while working on #8433. Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 8 12:18:03 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Nov 2013 12:18:03 -0000 Subject: [GHC] #8433: forkProcess masks async exceptions inside the child process In-Reply-To: <044.3cf534b848ce6e2def27d6179964a4ca@haskell.org> References: <044.3cf534b848ce6e2def27d6179964a4ca@haskell.org> Message-ID: <059.5fd240de82549d3c663fe6f9ad18aad4@haskell.org> #8433: forkProcess masks async exceptions inside the child process ------------------------------------------------+-------------------------- Reporter: joeyh | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: libraries/unix | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: Type of failure: Incorrect result at runtime | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by hvr): * status: new => closed * failure: None/Unknown => Incorrect result at runtime * resolution: => fixed * milestone: => 7.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 8 13:35:49 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Nov 2013 13:35:49 -0000 Subject: [GHC] #8510: Clear up what extensions are needed at a Template Haskell splice site In-Reply-To: <046.31fc5da448545a65cf9e299ef73abdd3@haskell.org> References: <046.31fc5da448545a65cf9e299ef73abdd3@haskell.org> Message-ID: <061.a6cfd98e18d97f2f2416c345e4000610@haskell.org> #8510: Clear up what extensions are needed at a Template Haskell splice site -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): While I agree that the current situation -- anarchic is a good description -- should be improved, there are competing forces at work here. As Simon notes, it's possible to create syntax trees in TH without using TH quotes, which gets around the need for language extensions. Indeed, I tend to prefer writing my code this way, as the quoting mechanism isn't quite flexible enough for my needs. So, if we follow Simon's plan of requiring extensions only at the quote site, not at at the splice site, it's possible to write a program using arbitrary extensions while mentioning only `TemplateHaskell`. This seems to fly in the face of the desire to use extensions to help control which compiler (or which version of a compiler) is used to build a cabal package. On the other hand, requiring users of a TH library to turn on extensions feels silly. I know that this a (quite small) point of annoyance when I'm working on my `singletons` package. It currently requires users to turn on roughly 10 extensions to use it. Even worse, if a user doesn't turn on `ScopedTypeVariables` in particular, the error message is ''very'' obscure. One potential solution here is to allow TH to interact directly with the extensions mechanism. At the least, it could query what extensions are in force and then report errors or warnings to the user accordingly. At the most, TH would be able to turn on (and off?) extensions within splices. If the extensions are named via an enumeration type (as opposed to strings), that might be a poor man's mechanism to enforce that the compiler supports an extension -- if the extension isn't present, the use of the relevant constructor wouldn't compile. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 8 14:40:25 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Nov 2013 14:40:25 -0000 Subject: [GHC] #8198: One-shot mode is buggy w.r.t. hs-boot files In-Reply-To: <044.066addbaba47f1aa4fead928a038d103@haskell.org> References: <044.066addbaba47f1aa4fead928a038d103@haskell.org> Message-ID: <059.243c636d96914ee56313bc71ed39ee85@haskell.org> #8198: One-shot mode is buggy w.r.t. hs-boot files -------------------------------------------------+------------------------- Reporter: parcs | Owner: parcs Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Driver | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect warning at | Unknown/Multiple compile-time | Difficulty: Test Case: | Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by parcs): Sorry, I meant the finder cache and mod location cache. I agree now -- there is no reason to assume that the source module exists in the same directory as the boot module. Does this patch look OK? {{{ #!diff diff --git a/compiler/main/DriverPipeline.hs b/compiler/main/DriverPipeline.hs index 337778e..0ecb5eb 100644 --- a/compiler/main/DriverPipeline.hs +++ b/compiler/main/DriverPipeline.hs @@ -928,7 +928,19 @@ runPhase (RealPhase (Hsc src_flavour)) input_fn dflags0 PipeState{hsc_env=hsc_env'} <- getPipeState -- Tell the finder cache about this module - mod <- liftIO $ addHomeModuleToFinder hsc_env' mod_name location + mod <- do + -- We pass in HsSrcFile unconditionally, even if we're compiling a + -- boot module, because every location in the finder cache + -- corresponds to a module's source files only. + src_location0 <- getLocation HsSrcFile mod_name + + -- However, if we're compiling a boot module then don't make any + -- assumptions about the location of the source module. It could + -- be in a different directory than the boot module. + let src_location1 + | isHsBoot src_flavour = src_location0 { ml_hs_file = Nothing } + | otherwise = src_location0 + liftIO $ addHomeModuleToFinder hsc_env' mod_name src_location1 -- Make the ModSummary to hand to hscMain let }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 8 15:40:56 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Nov 2013 15:40:56 -0000 Subject: [GHC] #4900: DEPENDS pragma In-Reply-To: <046.52f138a2609bf72d7f5381a2c64d358e@haskell.org> References: <046.52f138a2609bf72d7f5381a2c64d358e@haskell.org> Message-ID: <061.d4954415b0b4bcdea2e43f1d1a8d22bf@haskell.org> #4900: DEPENDS pragma -------------------------------------+------------------------------------ Reporter: cdsmith | Owner: parcs Type: feature request | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: TH_Depends | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by parcs): * owner: => parcs Comment: Okay, great. I will try to create an extensive patchset. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 8 15:44:23 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Nov 2013 15:44:23 -0000 Subject: [GHC] #7206: Implement cheap build In-Reply-To: <046.231132dc13e5eec24b09b65a3836eff3@haskell.org> References: <046.231132dc13e5eec24b09b65a3836eff3@haskell.org> Message-ID: <061.abb754f68e367e3fc7373546829dedd0@haskell.org> #7206: Implement cheap build -------------------------------------+------------------------------------ Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 7.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): If we do this, don't forget to use `cheapBuild` for `repeat`. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 8 17:56:51 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Nov 2013 17:56:51 -0000 Subject: [GHC] #7229: Detecting if a process was killed by a signal is impossible In-Reply-To: <049.04c6e7b70db678da0226fa39d069be65@haskell.org> References: <049.04c6e7b70db678da0226fa39d069be65@haskell.org> Message-ID: <064.213148536a274eca5e6c9fcdec178fd8@haskell.org> #7229: Detecting if a process was killed by a signal is impossible --------------------------------------+------------------------------------ Reporter: benmachine | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: libraries/process | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by hvr): ...is the current HEAD of [source:process] in a releasable state with respect to this ticket? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 8 20:49:38 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Nov 2013 20:49:38 -0000 Subject: [GHC] #3606: The Ord instance for unboxed arrays is very inefficient In-Reply-To: <046.5524abf7655d34a8f91d5dca7267dc7d@haskell.org> References: <046.5524abf7655d34a8f91d5dca7267dc7d@haskell.org> Message-ID: <061.aa1ecc149f2c3046f3e26cc376d51798@haskell.org> #3606: The Ord instance for unboxed arrays is very inefficient --------------------------------------------+------------------------------ Reporter: blarsen | Owner: Type: bug | Status: new Priority: lowest | Milestone: 7.10.1 Component: libraries (other) | Version: 6.10.4 Resolution: | Keywords: array Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by hvr): * keywords: array, performance, Ord => array * os: Linux => Unknown/Multiple * milestone: 7.6.2 => 7.10.1 Old description: > The Ord instance for unboxed arrays defined in Data.Array.Base results in > code that makes lots of heap allocations and is very slow. > > For the record, the Ord instance is defined as so in Data.Array.Base: > > {{{ > instance (Ix ix, Ord e, IArray UArray e) => Ord (UArray ix e) where > compare = cmpUArray > > {-# INLINE cmpUArray #-} > cmpUArray :: (IArray UArray e, Ix i, Ord e) => UArray i e -> UArray i e > -> Ordering > cmpUArray arr1 arr2 = compare (assocs arr1) (assocs arr2) > }}} > > The 'assocs' calls don't appear to be deforested away, and hence, when > using the Ord functions on unboxed arrays, the performance is bad to the > point of making them unusable. > > It seems reasonable to me that 'compare' for unboxed arrays could be > implemented strictly, in a tight loop, without any heap allocations at > all. New description: The Ord instance for unboxed arrays defined in `Data.Array.Base` results in code that makes lots of heap allocations and is very slow. For the record, the `Ord` instance is defined as so in `Data.Array.Base`: {{{#!hs instance (Ix ix, Ord e, IArray UArray e) => Ord (UArray ix e) where compare = cmpUArray {-# INLINE cmpUArray #-} cmpUArray :: (IArray UArray e, Ix i, Ord e) => UArray i e -> UArray i e -> Ordering cmpUArray arr1 arr2 = compare (assocs arr1) (assocs arr2) }}} The `assocs` calls don't appear to be deforested away, and hence, when using the `Ord` functions on unboxed arrays, the performance is bad to the point of making them unusable. It seems reasonable to me that `compare` for unboxed arrays could be implemented strictly, in a tight loop, without any heap allocations at all. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 8 23:05:13 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Nov 2013 23:05:13 -0000 Subject: [GHC] #7229: Detecting if a process was killed by a signal is impossible In-Reply-To: <049.04c6e7b70db678da0226fa39d069be65@haskell.org> References: <049.04c6e7b70db678da0226fa39d069be65@haskell.org> Message-ID: <064.0b560dd74a4445a116384f68e538b070@haskell.org> #7229: Detecting if a process was killed by a signal is impossible --------------------------------------+------------------------------------ Reporter: benmachine | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: libraries/process | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by andersk): It looks like the current HEAD still uses the ambiguous (128 + signal) return codes from comment:3. I don?t pretend to speak for the developers, but from the following comments it looks like everyone agrees that committing to this API would be a mistake. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 9 08:12:58 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Nov 2013 08:12:58 -0000 Subject: [GHC] #7229: Detecting if a process was killed by a signal is impossible In-Reply-To: <049.04c6e7b70db678da0226fa39d069be65@haskell.org> References: <049.04c6e7b70db678da0226fa39d069be65@haskell.org> Message-ID: <064.d428b257b3e5d5d45b2a69433eda3af8@haskell.org> #7229: Detecting if a process was killed by a signal is impossible --------------------------------------+------------------------------------ Reporter: benmachine | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: libraries/process | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by hvr): Replying to [comment:6 simonmar]: > Unfortunately we can't add the right information to `ExitCode`, because it is a platform-independent type. The correct type already exists: it is called `System.Posix.ProcessStatus`. > > {{{#!hs > data ProcessStatus = Exited ExitCode > | Terminated Signal > | Stopped Signal > deriving (Eq, Ord, Show) > }}} > > Unfortunately whoever wrote this forgot to add a `Bool` to indicate a core dump in the `Terminated` constructor. We *could* fix that. for the record, this has been implemented in [dc29d55b30d95f0838499fb48217e1d22e39d07d/unix] (which is included in the recently released [hackage:unix-2.7.0.0]) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 9 10:16:44 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Nov 2013 10:16:44 -0000 Subject: [GHC] #8511: GHCi Startup Crash with GHC 7.6.3 / HP 2013.2.0.0 64bit on OS X 10.6 Message-ID: <048.eda79a65fd24248c19cdd55ed1f00373@haskell.org> #8511: GHCi Startup Crash with GHC 7.6.3 / HP 2013.2.0.0 64bit on OS X 10.6 ----------------------------------+------------------------------- Reporter: blitzcode | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+------------------------------- A couple of HP / GHC releases later this bug still seems to exist: http://ghc.haskell.org/trac/ghc/ticket/6138 32bit works fine, 64bit GHCi crashes frequently on startup, even with XCode 4.1 installed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 9 11:00:00 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Nov 2013 11:00:00 -0000 Subject: [GHC] #7229: Detecting if a process was killed by a signal is impossible In-Reply-To: <049.04c6e7b70db678da0226fa39d069be65@haskell.org> References: <049.04c6e7b70db678da0226fa39d069be65@haskell.org> Message-ID: <064.da96c19665801db20cb8602e5c67d493@haskell.org> #7229: Detecting if a process was killed by a signal is impossible --------------------------------------+------------------------------------ Reporter: benmachine | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: libraries/process | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by hvr): Replying to [comment:7 andersk]: > that?s going to confuse anyone who knows that the real encoding is `(exit code << 8) + signal` (which, say, Perl forces you to learn). btw, what do you mean by //real// encoding? I've looked a bit around and here's what I've found so far: Python's [http://docs.python.org/3/library/os#os.wait os.wait()] operation which seem to match Perl's encoding: //... exit status indication: a 16-bit number, whose low byte is the signal number that killed the process, and whose high byte is the exit status (if the signal number is zero); the high bit of the low byte is set if a core file was produced.// ...otoh, Wikipedia says regarding [http://en.wikipedia.org/wiki/Exit_status#POSIX POSIX Exit status]: //... SUS specifies that the low-order 8 bits of the status value contain the exit status ...// -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 9 11:11:16 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Nov 2013 11:11:16 -0000 Subject: [GHC] #7229: Detecting if a process was killed by a signal is impossible In-Reply-To: <049.04c6e7b70db678da0226fa39d069be65@haskell.org> References: <049.04c6e7b70db678da0226fa39d069be65@haskell.org> Message-ID: <064.e88633b2f750b08f38cfb1da05414a8b@haskell.org> #7229: Detecting if a process was killed by a signal is impossible --------------------------------------+------------------------------------ Reporter: benmachine | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: libraries/process | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by andersk): Wikipedia is confused. If you go actually read the [http://pubs.opengroup.org/onlinepubs/9699919799/functions/wait.html specification], you see > WEXITSTATUS(stat_val): ? this macro evaluates to the low-order 8 bits of the status argument that the child process passed to _exit() or exit(), or the value the child process returned from main(). and also > The status values are retrieved by macros, rather than given as specific bit encodings as they are in most historical implementations (and thus expected by existing programs). This was necessary to eliminate a limitation on the number of signals an implementation can support that was inherent in the traditional encodings. Here?s the [https://sourceware.org/git/?p=glibc.git;a=blob;f=bits/waitstatus.h;hb=refs/tags/glibc-2.18#l27 definition] from glibc: {{{ /* If WIFEXITED(STATUS), the low-order 8 bits of the status. */ #define __WEXITSTATUS(status) (((status) & 0xff00) >> 8) /* If WIFSIGNALED(STATUS), the terminating signal. */ #define __WTERMSIG(status) ((status) & 0x7f) }}} which is to say that bits 8-15 of the wait()/waitpid() status are bits 0-7 of the exit() status (the rest of the exit() status being thrown away), and bits 0-6 of the wait()/waitpid() status are the signal number. This agrees with the Perl/Python encoding (because, of course, that?s where the Perl/Python encoding came from). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 9 11:29:47 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Nov 2013 11:29:47 -0000 Subject: [GHC] #7229: Detecting if a process was killed by a signal is impossible In-Reply-To: <049.04c6e7b70db678da0226fa39d069be65@haskell.org> References: <049.04c6e7b70db678da0226fa39d069be65@haskell.org> Message-ID: <064.19b0bfb16845ae687b45b3bf5136a24a@haskell.org> #7229: Detecting if a process was killed by a signal is impossible --------------------------------------+------------------------------------ Reporter: benmachine | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: libraries/process | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by hvr): Ok, in summary I see the following possibilities for the return value of the existing `waitForProcess` call on POSIX systems: 1. Use the reserved `ExitFailure 0` value to denote `WIFEXITED(s) == FALSE`; code should use the new API functions from comment:9 if it's interested in getting better exit-status information 2. Use the Perl/Python encoding convention for the argument of `ExitFailure`, i.e. {{{#!hs if coredump then 0x8000 else 0 .|. exit-status `shift` 8 .|. signum }}} causes impedance mismatch with the Haskell2010's `exitWith` 3. Use Bash-encoding for the argument of `ExitFailure` causes impedance mismatch with Haskell2010's `exitWith` I'm somewhat inclined to go with 1.; 2. would be tolerable if `exitWith` in base is adapted to interpret the exit code in the same way -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 9 11:50:11 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Nov 2013 11:50:11 -0000 Subject: [GHC] #7229: Detecting if a process was killed by a signal is impossible In-Reply-To: <049.04c6e7b70db678da0226fa39d069be65@haskell.org> References: <049.04c6e7b70db678da0226fa39d069be65@haskell.org> Message-ID: <064.d407636f8b391bb88558ead5c89d8915@haskell.org> #7229: Detecting if a process was killed by a signal is impossible --------------------------------------+------------------------------------ Reporter: benmachine | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: libraries/process | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by andersk): Adding constructors to `ExitCode` seems to still be an option (comment:10, comment:11). I think that would make all the other proposed changes unnecessary. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 9 11:56:13 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Nov 2013 11:56:13 -0000 Subject: [GHC] #7229: Detecting if a process was killed by a signal is impossible In-Reply-To: <049.04c6e7b70db678da0226fa39d069be65@haskell.org> References: <049.04c6e7b70db678da0226fa39d069be65@haskell.org> Message-ID: <064.41a442a6881b7610ec6046508ef3190c@haskell.org> #7229: Detecting if a process was killed by a signal is impossible --------------------------------------+------------------------------------ Reporter: benmachine | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: libraries/process | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by hvr): Replying to [comment:19 andersk]: > Adding constructors to `ExitCode` seems to still be an option (comment:10, comment:11). I think that would make all the other proposed changes unnecessary. that change would involve modifications to `haskell2010`, `base`, `process` and maybe `unix` if I understand it right... :-/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 9 14:34:44 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Nov 2013 14:34:44 -0000 Subject: [GHC] #7229: Detecting if a process was killed by a signal is impossible In-Reply-To: <049.04c6e7b70db678da0226fa39d069be65@haskell.org> References: <049.04c6e7b70db678da0226fa39d069be65@haskell.org> Message-ID: <064.58daf8d813b61e70ef67b30e77e18afb@haskell.org> #7229: Detecting if a process was killed by a signal is impossible --------------------------------------+------------------------------------ Reporter: benmachine | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: libraries/process | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by hvr): Replying to [comment:11 simonmar]: > We would have to move the existing `ExitCode` datatype into the `haskell2010` package, and do the corresponding refactorings. ...what's exactly involved here? Does this mean, that `haskell2010` (as well as `haskell98`) gets a //distinct// `System.Exit.ExitCode` type (but with the same name) as the one remaining in `base`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 9 17:18:25 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Nov 2013 17:18:25 -0000 Subject: [GHC] #8511: GHCi Startup Crash with GHC 7.6.3 / HP 2013.2.0.0 64bit on OS X 10.6 In-Reply-To: <048.eda79a65fd24248c19cdd55ed1f00373@haskell.org> References: <048.eda79a65fd24248c19cdd55ed1f00373@haskell.org> Message-ID: <063.1cfad0252abddb5f619b1b51c9237c82@haskell.org> #8511: GHCi Startup Crash with GHC 7.6.3 / HP 2013.2.0.0 64bit on OS X 10.6 -------------------------------+---------------------------------- Reporter: blitzcode | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+---------------------------------- Comment (by blitzcode): Note that this does not only affect the GHCi repl, but the bytecode interpreter in general. So Template Haskell compilation and things like 'ghc -e' in Makefiles seem to be broken since HP 2012.2.0.0 with OS X 10.6 + 64bit, at least as far as I can tell on my two machines. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 9 17:42:52 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Nov 2013 17:42:52 -0000 Subject: [GHC] #8512: Add flag like '-xc' that only reports uncaught exceptions Message-ID: <048.82b1fcc5113161d6daef1f786f24006e@haskell.org> #8512: Add flag like '-xc' that only reports uncaught exceptions ------------------------------------+------------------------------------- Reporter: blitzcode | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The -xc RTS flag reports the stack trace of all exceptions. This can be very noisy when, for instance, certain http or parsing libraries are used that throw many exceptions, often handled fully internal, during their normal operation. Having multiple threads makes it even noisier. I'd think having a flag like -xc that only reports uncaught exceptions would be useful. It seems the GHCi debugger has a flag to only stop on uncaught exceptions, maybe this could be made available as an RTS option? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 9 18:22:03 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Nov 2013 18:22:03 -0000 Subject: [GHC] #8513: Parallel GC increases CPU load while slowing down program Message-ID: <048.acba2cf90eacaca80204f1d1ff7b76b8@haskell.org> #8513: Parallel GC increases CPU load while slowing down program ------------------------------+-------------------------------------------- Reporter: blitzcode | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.6.3 System | Operating System: Unknown/Multiple Keywords: | Type of failure: Runtime performance bug Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- I noticed this issue with a lot of my programs. I have no idea if this is a widely know issue or if I'm just particularly unluckily and/or unskilled when it comes to the GHC GC, but I thought it might be worth reporting as a bug. Here's a fairly simple program showing the issue: https://github.com/blitzcode/haskell-gol/tree/master/vector-glfwb (Note the 'GHC.Conc.getNumProcessors >>= setNumCapabilities', need to remove that for testing) On my quad core machine, this simple (non-parallel, some concurrency for draw & compute) Game-of-Life program runs as follows: +RTS -N1 = ~520G/s, CPU Load ~100% +RTS -N2 = ~505G/s, CPU Load ~135% +RTS -N3 = ~485G/s, CPU Load ~150% +RTS -N4 = ~485G/s, CPU Load ~160% Specifying -qg1 caps the CPU load increase at ~135% and it won't slow down below ~505G/s. The statistics from +RTS -s also suggest a decrease in GC time / increase in productivity through using -qg1. The program is a bit crummy, but it's the shortest example of this I got at hand. I've seen this in many different programs, serial GC just seems to be faster for a lot of workloads. I think it might at least be helpful to improve documentation a bit, suggesting some things to try for a GC speedup etc. Apologies if this is already a well-known issue or if I'm just doing something obviously dumb here that makes the GC perform poorly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 9 18:40:52 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Nov 2013 18:40:52 -0000 Subject: [GHC] #8514: Non-ideal error with a kind error in a tuple Message-ID: <047.4c9258367aa20f601907b38889acede0@haskell.org> #8514: Non-ideal error with a kind error in a tuple -------------------------------------------+------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler (Type checker) | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: #7410 | Test Case: | Blocking: -------------------------------------------+------------------------------- The definition {{{ type T a = (a, Maybe) }}} gives an error: {{{ Expecting one more argument to ?a? The first argument of a tuple should have kind ?*?, but ?a? has kind ?* -> *? }}} However, obviously that's not the problem - the error should point to the `Maybe` part. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 9 20:04:31 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Nov 2013 20:04:31 -0000 Subject: [GHC] #8515: Biographical profiling (-hb) crashes, other profiling modes have truncated output Message-ID: <048.c7e4a832e375c0962ebd5fbc8e1e03c8@haskell.org> #8515: Biographical profiling (-hb) crashes, other profiling modes have truncated output ----------------------------------+---------------------------------- Reporter: blitzcode | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Keywords: | Operating System: MacOS X Architecture: x86 | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+---------------------------------- I have a (non-trivial) threaded program which always crashes with a Bus Error when running with +RTS -hb. gdb didn't provide much useful information. Valgrind seems to have some issues with Haskell programs, but here is what it spits out: jacky: ioManagerDie: write: Bad file descriptor ==56255== Invalid read of size 4 ==56255== at 0x1AAC4BD: LdvCensusForDead (in ./jacky) ==56255== by 0x1ABBAAC: scheduleDoGC (in ./jacky) ==56255== by 0x1ABBEBE: exitScheduler (in ./jacky) ==56255== Address 0x9c88090 is 0 bytes inside a block of size 8 free'd ==56255== at 0x3E7511F: realloc (vg_replace_malloc.c:525) ==56255== by 0x1AB9E77: stgReallocBytes (in ./jacky) ==56255== ==56255== Invalid read of size 4 ==56255== at 0x1AAC4BD: LdvCensusForDead (in ./jacky) ==56255== Address 0x9c88090 is 0 bytes inside a block of size 8 free'd ==56255== at 0x3E7511F: realloc (vg_replace_malloc.c:525) ==56255== by 0x1AB9E77: stgReallocBytes (in ./jacky) ==56251== Invalid read of size 4 ==56251== at 0x1AAC4BD: LdvCensusForDead (in ./jacky) ==56251== by 0x1ABBAAC: scheduleDoGC (in ./jacky) ==56251== by 0x1ABBEBE: exitScheduler (in ./jacky) ==56251== Address 0x9c88090 is 0 bytes inside a block of size 8 free'd ==56251== at 0x3E7511F: realloc (vg_replace_malloc.c:525) ==56251== by 0x1AB9E77: stgReallocBytes (in ./jacky) ==56251== ==56251== Invalid read of size 4 ==56251== at 0x1AAC4BD: LdvCensusForDead (in ./jacky) ==56251== Address 0x9c88090 is 0 bytes inside a block of size 8 free'd ==56251== at 0x3E7511F: realloc (vg_replace_malloc.c:525) ==56251== by 0x1AB9E77: stgReallocBytes (in ./jacky) running with +'RTS -hb -s' gets us this from valgrind: jacky(56272,0xa0707540) malloc: *** error for object 0x4c05684: incorrect checksum for freed object - object was probably modified after being freed. *** set a breakpoint in malloc_error_break to debug jacky(56272,0xa0707540) malloc: *** error for object 0x4c03894: incorrect checksum for freed object - object was probably modified after being freed. ... The program seems to work just fine when running without profiling. Profiling modes other than -hb haven't crashed so far, but it seems the output is truncated. Cost-center profiling seems to work the most reliable, but all the other memory profiling options only output data for the first few seconds, even when the program runs for minutes. I haven't managed to narrow this one down further in the program, please let me know if this is already helpful or if I need to provide more information. I also attached the OS X crash report file. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 9 20:39:42 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Nov 2013 20:39:42 -0000 Subject: [GHC] #8516: Add (->) representation and the Invariant class to GHC.Generics Message-ID: <046.4bd98a18c7a25f1a7eb2c50c7cbb4858@haskell.org> #8516: Add (->) representation and the Invariant class to GHC.Generics ----------------------------------------------+---------------------------- Reporter: nfrisby | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type checker) | Version: 7.7 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less than a day) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: ----------------------------------------------+---------------------------- We currently disallow any use of the parameter in the domain of (->). {{{ newtype F a = F ((a -> Int) -> Int) deriving Generic1 :4:38: Can't make a derived instance of `Generic1 (F g)': Constructor `F' must use the last type parameter only as the last argument of a data type, newtype, or (->) In the data declaration for `F' }}} !DeriveFunctor succeeds for this F. I'd like to add this representation type to GHC.Generics and !DeriveGeneric. {{{ newtype (f :->: g) a = FArrow1 (f a -> g a) }}} We could then represent the first example above. We could also derive the more interesting Generic1 (F g). {{{ newtype F g a = F (g a -> Int) deriving Generic1 type instance Rep1 (F g) = Rec1 g :->: Rec0 Int instance Generic1 (F g) where to x = F $ unRec0 . unArrow1 x . Rec1 from (F x) = FArrow1 $ Rec0 . x . unRec1 }}} Admittedly, there's not many generic definitions impeded by not having (:->:). Contra- and in-variant types are uncommon. I'm suggesting this feature without strong motivating examples because I think this would streamline the implementation of -XDeriveGenerics in some ways while also making it more general ? assuming that we added the Invariant class to base or ghc-prim. {{{ class Invariant t where invmap :: (a -> b) -> (b -> a) -> t a -> t b invmap_covariant :: Functor t => (a -> b) -> (b -> a) -> t a -> t b invmap_covariant f _ = fmap f instance (Invariant f,Invariant g) => Invariant (FArrow f g) where invmap co contra (FArrow h) = FArrow $ invmap co contra . h . invmap contra co }}} (Of course, Invariant should be a super class of Functor. :/ ) Now we can handle quite involved examples: {{{ newtype F g h a = F (g (h a)) deriving Generic1 instance Invariant g => Generic1 (F g h) where to x = invmap unRec1 Rec1 $ unComp1 x from (F x) = Comp1 $ invmap Rec1 unRec1 }}} All of that said, I'm mostly opening this ticket so I can get feedback on difficulties I might not be anticipating and have a place to reference from the compiler source code comments. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 9 21:00:09 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Nov 2013 21:00:09 -0000 Subject: [GHC] #8517: Add library function retrieve label set by GHC.Conc.Sync.labelThread Message-ID: <048.d427ad4c249513a7b1f62c90daadde10@haskell.org> #8517: Add library function retrieve label set by GHC.Conc.Sync.labelThread ------------------------------------+------------------------------------- Reporter: blitzcode | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- It would be useful to be able to retrieve the label set by the labelThread function. For instance, a logging / tracing system could output a human readable string for the thread the trace originated from instead of just the thread ID. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 10 08:43:57 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Nov 2013 08:43:57 -0000 Subject: [GHC] #8518: Build Extra Bodybuilding With Supplement Message-ID: <049.986b919cc771a293b9dcb72aa1e24b84@haskell.org> #8518: Build Extra Bodybuilding With Supplement -------------------------------------------+------------------------------- Reporter: AnnDForbes | Owner: Type: task | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler (FFI) | Version: 7.6.3 Keywords: Niwali Testobost | Operating System: Architecture: alpha | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- '''I said hey I make what you guys want to see like''' the two article I really did make that article for you guys because US so let me flip this around and show you so we'll start with preteen right here I'm sure must be as use this if you lightweights you probably know all about it to great supplement and I makes all three these things together for my workout drink and buying all these separately is so much cheaper than going out to you supplement store and buying a packaged per-workout those actually are pretty expensive and then moving on we've got some fish oil some calcium in a mufti-vitamin and of course I take away protein powder the brand really doesn?t matter this is salvation got pretty good record you guys can see right there I really like it but like I said it doesn?t matter what brand you use here's my thoughts about supplements I?ve never really talked about supplements but I think the whole supplement industry it's kind of a scam because most of the time when you want to go by a supplement all you see in the stores are like pro bodybuilders that have Avery impressive physique. '''It's true our way it's probably not true and a lot of''' the supplement companies can say whatever they would like on the bottle like gain because the supplement industry is it regulated there's actually a really good documentary that touch son this call bigger faster stronger thinker some combination of those three words and actually show how easy it is to make your own supplement and put some bogus claims on it and sell it?s kind of crazy and it really makes you think twice before going out and buying a supplement that probably doesn't work so the average person that buys one point was supplement a month for sixty dollars think how much that is over the course of one year it's a lot of money in here is my latest busy picture actually posted this the other day on Twitter and Integral you should follow me there if you don?t because overly be posting some more at a pretty happy. ''' I am a lot bigger than most people think because most the time''' in these articles you see mean my off day just standing in the kitchen you know not pumped up for anything they're going to try to get some workout out I found someone to fill which is great but that's pretty much it for this article my thoughts on supplements and which ones I take I hope you guys enjoy it and I hope you guys have a really get holiday season or whatever and I'll post this article and I think you guys will enjoy it little holiday spirit but I hope you guys have a good holiday like I said spend some time with your loved ones and be sure to check out this week's articles which is coming up on this outer screen. For more details http://www.niwalitest-o-boost.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 10 19:00:22 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Nov 2013 19:00:22 -0000 Subject: [GHC] #8518: panic ghci when probably using type families incorrectly Message-ID: <048.6fb8bd551db19740f383c6e83d846014@haskell.org> #8518: panic ghci when probably using type families incorrectly ------------------------------+------------------------------------- Reporter: HanStolpo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: ghci panic | Operating System: Unknown/Multiple Architecture: x86 | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------+------------------------------------- Hi I am a beginner and was playing around with type families when ghc gave me a panic message and suggested I log a bug. I am running Windows 7 with GHC 7.6.3 installed using Haskell Platform 2013.2.0.0. Here is the reduced code producing the panic: {{{ {-# LANGUAGE TypeFamilies #-} import Data.Maybe import Control.Applicative class Continuation c where type Z c type B c type F c continue :: c -> (Z c) -> (B c) -> Maybe ((F c), c) callCont :: Continuation c => c -> (Z c) -> (B c) -> Maybe (F c) callCont c z b = rpt (4 :: Int) c z b where rpt 0 c' z' b' = fromJust (fst <$> (continue c' z' b')) rpt i c' z' b' = let c'' = fromJust (snd <$> (continue c' z' b')) in rpt (i-1) c'' main = putStrLn "" }}} Loading the code in WinGHCi and calling main results in the following {{{ GHCi, version 7.6.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> :cd C:\Dev Prelude> :load "Crash.hs" [1 of 1] Compiling Main ( Crash.hs, interpreted ) Ok, modules loaded: Main. *Main> main ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for i386-unknown-mingw32): nameModule <
> Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *Main> }}} There is obviously something degenerate with the code but I guess the compiler should give a better error message. Note it actually compiles, i.e. if the file itself is just compiled but not linked in it does not give any errors. If the degenerate function 'callCont' is changed as follows. {{{ {-# LANGUAGE TypeFamilies #-} import Data.Maybe import Control.Applicative class Continuation c where type Z c type B c type F c continue :: c -> (Z c) -> (B c) -> Maybe ((F c), c) callCont :: Continuation c => c -> (Z c) -> (B c) -> Maybe (F c) callCont c z b = rpt (4 :: Int) c z b where rpt i c' z' b' = fromJust (fst <$> (continue c' z' b')) main = putStrLn "" }}} Then you get the following compile error: {{{ Crash.hs|12 col 18 error| Occurs check: cannot construct the infinite type: uf0 = Maybe uf0 || Expected type: Maybe (F c) || Actual type: F c || In the return type of a call of `rpt' || In the expression: rpt (4 :: Int) c z b || In an equation for `callCont': || callCont c z b || = rpt (4 :: Int) c z b || where || rpt i c' z' b' = fromJust (fst <$> (continue c' z' b')) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 11 04:30:53 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Nov 2013 04:30:53 -0000 Subject: [GHC] #8518: panic ghci when probably using type families incorrectly In-Reply-To: <048.6fb8bd551db19740f383c6e83d846014@haskell.org> References: <048.6fb8bd551db19740f383c6e83d846014@haskell.org> Message-ID: <063.4eec0decb6c8c2547cd05e15e9dd7b89@haskell.org> #8518: panic ghci when probably using type families incorrectly -------------------------------------+------------------------------ Reporter: HanStolpo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: ghci panic Operating System: Unknown/Multiple | Architecture: x86 Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------ Comment (by HanStolpo): If the code is fixed to be valid compilable code then it does not panic any more. {{{ {-# LANGUAGE TypeFamilies #-} import Data.Maybe import Control.Applicative class Continuation c where type Z c type B c type F c continue :: c -> (Z c) -> (B c) -> Maybe ((F c), c) callCont :: Continuation c => c -> (Z c) -> (B c) -> Maybe (F c) callCont c z b = rpt (4 :: Int) c z b where rpt 0 c' z' b' = (fst <$> (continue c' z' b')) rpt i c' z' b' = let c'' = fromJust (snd <$> (continue c' z' b')) in rpt (i-1) c'' z' b' main = putStrLn "" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 11 08:38:23 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Nov 2013 08:38:23 -0000 Subject: [GHC] #8518: panic ghci when probably using type families incorrectly In-Reply-To: <048.6fb8bd551db19740f383c6e83d846014@haskell.org> References: <048.6fb8bd551db19740f383c6e83d846014@haskell.org> Message-ID: <063.9921aa00580e6abc5dc6dc697c5a6b13@haskell.org> #8518: panic ghci when probably using type families incorrectly -------------------------------------+------------------------------ Reporter: HanStolpo | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: ghci panic Operating System: Unknown/Multiple | Architecture: x86 Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------ Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: Thank you! Happily the original program compiled with HEAD (shortly to be 7.8.1) gives a sensible error message {{{ T8518.hs:17:78: Could not deduce (F a1 ~ (Z a1 -> B a1 -> F a1)) from the context (Continuation c) bound by the type signature for callCont :: Continuation c => c -> Z c -> B c -> Maybe (F c) at T8518.hs:13:13-64 Relevant bindings include c'' :: a1 (bound at T8518.hs:17:30) b' :: B a1 (bound at T8518.hs:17:21) z' :: Z a1 (bound at T8518.hs:17:18) c' :: a1 (bound at T8518.hs:17:15) rpt :: a -> a1 -> Z a1 -> B a1 -> F a1 (bound at T8518.hs:16:9) In the expression: rpt (i - 1) c'' In the expression: let c'' = fromJust (snd <$> (continue c' z' b')) in rpt (i - 1) c'' }}} I'll add the example as a regression test though! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 11 08:50:52 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Nov 2013 08:50:52 -0000 Subject: [GHC] #8519: Make -XTemplateHaskell an error in a stage-1 compiler Message-ID: <046.3ef79a306c8292fd80a78cafcbd74b7f@haskell.org> #8519: Make -XTemplateHaskell an error in a stage-1 compiler ------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- If you use the language extension `-XTemplateHaskell` in a stage-1 compiler, it's guaranteed not to work. This patch makes it an error to do so. The error is suppressed in `MkDepend` mode (i.e. `ghc -M`) because that ''does'' work; the TH flag is not consulted. Moreover it is used by GHC's build system itself: for some reason we use the stage-1 compiler to do build the `.depend` files for DPH, even though DPH is only built with stage2. This is an infelicity, but Ian writes "It's due to the [wiki:Building/Architecture/Idiom/PhaseOrdering#GHCsphases build system phases]: stage2 doesn't exist during the phase in which DPH is configured. Changing it to use stage 2 would probably mean adding another phase for things that need to be configured by stage 2. This might mean slower builds due to loss of parallelism, I'm not sure. This change isn't mission critical; it could be a warning instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 11 11:28:50 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Nov 2013 11:28:50 -0000 Subject: [GHC] #8520: ghc.exe: internal error: loadArchive: error whilst reading `C' Message-ID: <044.7423adcbc9658116359111a685ed6de6@haskell.org> #8520: ghc.exe: internal error: loadArchive: error whilst reading `C' ----------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+---------------------------------- While building Agda HEAD, GHC 7.7.20131108 for i386_unknown_mingw32 spits: {{{ [ 88 of 256] Compiling Agda.TypeChecking.Monad.Base[boot] ( src\full\Agda\TypeChecking\Monad\Base.hs-boot, dist\build\Agda\TypeChecking\Monad\Base.o-boot ) [ 89 of 256] Compiling Agda.Interaction.Response[boot] ( src\full\Agda\Interaction\Response.hs-boot, dist\build\Agda\Interaction\Response.o-boot ) [ 90 of 256] Compiling Agda.Interaction.FindFile[boot] ( src\full\Agda\Interaction\FindFile.hs-boot, dist\build\Agda\Interaction\FindFile.o-boot ) [ 91 of 256] Compiling Agda.Syntax.Abstract ( src\full\Agda\Syntax\Abstract.hs, dist\build\Agda\Syntax\Abstract.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... 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 zlib-0.5.4.1 ... linking ... done. Loading package xhtml-3000.2.1 ... linking ... done. Loading package text-0.11.3.1 ... linking ... done. Loading package hashable-1.2.1.0 ... linking ... done. Loading package unordered-containers-0.2.3.3 ... linking ... done. Loading package Win32-2.3.0.0 ... 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.1 ... linking ... done. Loading package directory-1.2.0.2 ... linking ... done. Loading package process-1.2.0.0 ... linking ... done. Loading package containers-0.5.3.1 ... linking ... done. Loading package parallel-3.2.0.4 ... linking ... done. Loading package old-time-1.1.0.2 ... linking ... done. Loading package cpphs-1.17.1 ... linking ... done. Loading package pretty-1.1.1.1 ... linking ... done. Loading package haskell-src-exts-1.14.0 ... linking ... done. Loading package transformers-0.3.0.0 ... linking ... done. Loading package haskeline-0.7.0.3 ... linking ... done. Loading package primitive-0.5.1.0 ... linking ... done. Loading package vector-0.10.9.1 ... ghc.exe: internal error: loadArchive: error whilst reading `C' (GHC version 7.7.20131108 for i386_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Btw, 7.7.20131024 has *NO* this bug, thus it was introduced quite recently. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 11 12:15:13 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Nov 2013 12:15:13 -0000 Subject: [GHC] #8520: ghc.exe: internal error: loadArchive: error whilst reading `C' In-Reply-To: <044.7423adcbc9658116359111a685ed6de6@haskell.org> References: <044.7423adcbc9658116359111a685ed6de6@haskell.org> Message-ID: <059.cc6a0b18a09484a4f30956467f106722@haskell.org> #8520: ghc.exe: internal error: loadArchive: error whilst reading `C' ----------------------------------+--------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+--------------------------- Comment (by awson): When I initially configure Agda without -j3 GHC option I have the same error in a slightly different place: {{{ [ 88 of 256] Compiling Agda.Syntax.Abstract ( src\full\Agda\Syntax\Abstract.hs, dist\build\Agda\Syntax\Abstract.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... 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 zlib-0.5.4.1 ... linking ... done. Loading package xhtml-3000.2.1 ... linking ... done. Loading package text-0.11.3.1 ... linking ... done. Loading package hashable-1.2.1.0 ... linking ... done. Loading package unordered-containers-0.2.3.3 ... linking ... done. Loading package Win32-2.3.0.0 ... 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.1 ... linking ... done. Loading package directory-1.2.0.2 ... linking ... done. Loading package process-1.2.0.0 ... linking ... done. Loading package containers-0.5.3.1 ... linking ... done. Loading package parallel-3.2.0.4 ... linking ... done. Loading package old-time-1.1.0.2 ... linking ... done. Loading package cpphs-1.17.1 ... linking ... done. Loading package pretty-1.1.1.1 ... linking ... done. Loading package haskell-src-exts-1.14.0 ... linking ... done. Loading package transformers-0.3.0.0 ... linking ... done. Loading package haskeline-0.7.0.3 ... ghc.exe: internal error: loadArchive: error whilst reading `C' (GHC version 7.7.20131108 for i386_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 11 12:45:03 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Nov 2013 12:45:03 -0000 Subject: [GHC] #8521: Tight loop prevents other threads from running in available cores Message-ID: <056.1462ccb14964f58201abc5dcbd1962c4@haskell.org> #8521: Tight loop prevents other threads from running in available cores -------------------------------------+------------------------------------- Reporter: facundo.dominguez | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- The following program does not terminate when compiled with: {{{ghc --make -O -threaded test.hs}}} and executed on linux on an amd64 machine with 16 cores with: {{{./test}}} {{{ import Control.Concurrent import Control.Monad import System.Environment main :: IO () main = do y <- getArgs mv0 <- newEmptyMVar mv1 <- newEmptyMVar forkIO $ do takeMVar mv0 putMVar mv1 () loop (y == ["yield"]) putMVar mv0 () takeMVar mv1 >>= print loop :: Bool -> IO () loop cooperative = go where go = when cooperative yield >> go }}} Here [1] is the discussion about it so far. [1] http://www.haskell.org/pipermail/glasgow-haskell- users/2013-October/024412.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 11 13:32:10 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Nov 2013 13:32:10 -0000 Subject: [GHC] #8513: Parallel GC increases CPU load while slowing down program In-Reply-To: <048.acba2cf90eacaca80204f1d1ff7b76b8@haskell.org> References: <048.acba2cf90eacaca80204f1d1ff7b76b8@haskell.org> Message-ID: <063.8c4cb91af66577b550c720b33010b6aa@haskell.org> #8513: Parallel GC increases CPU load while slowing down program --------------------------------------------+------------------------------ Reporter: blitzcode | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Resolution: worksforme | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by simonmar): * status: new => closed * resolution: => worksforme Comment: Your results seem to be in line with what I would expect. The parallel GC improves performance for (a) parallel programs and (b) sequential programs that have a large residency. For (b) you should use `+RTS -qg1`. The documentation for `+RTS -qg` already mentions the points above, and seems reasonably clear to me: http://www.haskell.org/ghc/docs/latest/html/users_guide/runtime- control.html#rts-options-gc Your program looks like its main heap structure is a single Vector, which is not very parallelisable in the GC. This would explain why you don't see much speedup with parallel GC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 11 16:28:24 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Nov 2013 16:28:24 -0000 Subject: [GHC] #7229: Detecting if a process was killed by a signal is impossible In-Reply-To: <049.04c6e7b70db678da0226fa39d069be65@haskell.org> References: <049.04c6e7b70db678da0226fa39d069be65@haskell.org> Message-ID: <064.20430e625ad77aead4f98ead90c04a91@haskell.org> #7229: Detecting if a process was killed by a signal is impossible --------------------------------------+------------------------------------ Reporter: benmachine | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: libraries/process | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by duncan): What would `exitWith (ExitTerminated signal)` mean on Windows? Having the abstract `ExitStatus` type as Simon and I proposed would not have that issue, since it's only for the reading side, not the throwing side, and on Windows can always return Nothing. My view is still that using a structured type is a lot nicer than using a bit twiddling encoding. Related to this is that we want an extra `CreateProcess` option to do the WCE automatically. We still have the mad situation that System.Cmd can mask ctl-c for us, but System.Process lacks that feature. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 11 16:29:05 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Nov 2013 16:29:05 -0000 Subject: [GHC] #8516: Add (->) representation and the Invariant class to GHC.Generics In-Reply-To: <046.4bd98a18c7a25f1a7eb2c50c7cbb4858@haskell.org> References: <046.4bd98a18c7a25f1a7eb2c50c7cbb4858@haskell.org> Message-ID: <061.4a1610d7c03e048fd466a8bfd17a5a51@haskell.org> #8516: Add (->) representation and the Invariant class to GHC.Generics -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.7 checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Unknown/Multiple | Difficulty: Moderate (less Type of failure: None/Unknown | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by simonpj): * cc: dreixel (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 11 17:01:48 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Nov 2013 17:01:48 -0000 Subject: [GHC] #7229: Detecting if a process was killed by a signal is impossible In-Reply-To: <049.04c6e7b70db678da0226fa39d069be65@haskell.org> References: <049.04c6e7b70db678da0226fa39d069be65@haskell.org> Message-ID: <064.98050d5b5fed24cc4391e55479c2c5d6@haskell.org> #7229: Detecting if a process was killed by a signal is impossible --------------------------------------+------------------------------------ Reporter: benmachine | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: libraries/process | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by andersk): I guess you could replace `ExitTerminated CInt Bool` with `ExitTerminated Signal Bool`, where `Signal` is `CInt` on POSIX and `Void` on Windows? (And/or there?s a platform-independent `Signal -> CInt` and a POSIX- dependent `CInt -> Signal`?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 11 17:23:35 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Nov 2013 17:23:35 -0000 Subject: [GHC] #7229: Detecting if a process was killed by a signal is impossible In-Reply-To: <049.04c6e7b70db678da0226fa39d069be65@haskell.org> References: <049.04c6e7b70db678da0226fa39d069be65@haskell.org> Message-ID: <064.ff1d639aa06de416f860eb1617ebfe78@haskell.org> #7229: Detecting if a process was killed by a signal is impossible --------------------------------------+------------------------------------ Reporter: benmachine | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: libraries/process | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by duncan): So on reflection, I think I'm changing my opinion. The H2010 docs say: "The exact interpretation of the code is operating- system dependent." So on that principle then I think we're well justified to use a reasonable encoding. This also means we don't have the trouble of braking existing code by adding a new `ExitCode` constructor. Existing code that doesn't interpret the exit code much will continue to work. As for the specific encoding. It would be madness for us to use the low bits for the signal. There must be plenty of code out there that looks for `ExitFailure 1` or other low numbers for example. So we would have to use Simon's encoding, high bits for a signal, low bits for a normal exit. I suggest we update the `ExitCode` docs to indicate how the `Int` corresponds to the system exit code on Windows and Unix (ie directly for Windows and the high 8 signal & low 8 normal exit code encoding for Unix). hvr raises a related question: * What should we do for `exitWith (ExitFailure n)` for `n > 255` on Unix? Currently the code just takes the low 8 bits. This is clearly silly since it would end up being equiv to `exitWith ExitSuccess`. Using numbers > 255 is fine on Windows. In addition, if we are going to use 16 bits for the exit code on Unix then we ought to be able to use `exitWith` on such values. So, how about this for a specific suggestion: * On unix, use 16bits of the `ExitFailure Int`, high 8 for signal, low 8 for normal exit code. * `waitForProcess` & `getProcessExitCode` return this encoding on Unix. * It is valid to `exitWith` an `ExitCode` from `waitForProcess` & `getProcessExitCode` and the top level handler should make this have the appropriate behaviour: * calling exit(n); or * calling kill(getpid(), s); * These are mutually exclusive. That is, we either get non-0 high byte or non-0 low byte but never both. * We enforce this on the `exitWith` side. An invalid encoding is replaced with `ExitFailure 255`. So that's used if both exit code + signal are set, or if it's > 16bit, or negative. But we do not make it an error because we don't want to create needless portability problems for programs using high Windows error codes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 11 17:29:54 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Nov 2013 17:29:54 -0000 Subject: [GHC] #7229: Detecting if a process was killed by a signal is impossible In-Reply-To: <049.04c6e7b70db678da0226fa39d069be65@haskell.org> References: <049.04c6e7b70db678da0226fa39d069be65@haskell.org> Message-ID: <064.47c6e71ba88d928d21a3855ac3db0083@haskell.org> #7229: Detecting if a process was killed by a signal is impossible --------------------------------------+------------------------------------ Reporter: benmachine | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: libraries/process | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by duncan): hvr points out it's actually only 7bits for the signal, not 8. I can't bring myself to care about the core dump bit in this interface. I'm quite happy with leaving that for the `unix` package. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 11 17:47:03 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Nov 2013 17:47:03 -0000 Subject: [GHC] #7229: Detecting if a process was killed by a signal is impossible In-Reply-To: <049.04c6e7b70db678da0226fa39d069be65@haskell.org> References: <049.04c6e7b70db678da0226fa39d069be65@haskell.org> Message-ID: <064.34b78c15f3fefc6f69361dfd9e506f47@haskell.org> #7229: Detecting if a process was killed by a signal is impossible --------------------------------------+------------------------------------ Reporter: benmachine | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: libraries/process | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by duncan): See `libraries/base/GHC/TopHandler.lhs` and `rts/RtsStartup.c` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 11 20:16:14 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Nov 2013 20:16:14 -0000 Subject: [GHC] #8522: exprType incorrect for let expressions which bind types Message-ID: <046.74e9c81df2ed72c1bafb41228d3f51e0@haskell.org> #8522: exprType incorrect for let expressions which bind types ------------------------------------+------------------------------------- Reporter: afarmer | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The `exprType` function in CoreUtils doesn't handle let expressions which bind type variables correctly. Consider: {{{ let a = Int in \ $dNum x y -> (+) a $dNum x y }}} `exprType` on this expression will give: `Num a => a -> a -> a` instead of `Num Int => Int -> Int -> Int` Obviously the core lint checker does the right thing, so I modified exprType (see attached patch) to do what it does. I'm guessing that exprType isn't used in any crucial capacity (or let-bound types are not that common) or the fact that `a` is unbound in the result would be a big problem. That said, we use this function heavily in HERMIT... is there another we should be using instead? Any chance this can make the 7.8 window? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 11 20:22:25 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Nov 2013 20:22:25 -0000 Subject: [GHC] #7229: Detecting if a process was killed by a signal is impossible In-Reply-To: <049.04c6e7b70db678da0226fa39d069be65@haskell.org> References: <049.04c6e7b70db678da0226fa39d069be65@haskell.org> Message-ID: <064.55d86042db57272f4b238d5e1779ecf1@haskell.org> #7229: Detecting if a process was killed by a signal is impossible --------------------------------------+------------------------------------ Reporter: benmachine | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: libraries/process | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by simonmar): Sounds like this discussion is converging. I'm happy with the proposal to encode signals in bits 8-15 of the exit code, and to have `exitWith` call `kill()` when given one of these signal codes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 11 20:46:32 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Nov 2013 20:46:32 -0000 Subject: [GHC] #8522: exprType incorrect for let expressions which bind types In-Reply-To: <046.74e9c81df2ed72c1bafb41228d3f51e0@haskell.org> References: <046.74e9c81df2ed72c1bafb41228d3f51e0@haskell.org> Message-ID: <061.00d660705bd933f6d11ced93cf01b43d@haskell.org> #8522: exprType incorrect for let expressions which bind types -------------------------------------+------------------------------------ Reporter: afarmer | Owner: Type: bug | Status: patch Priority: high | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by afarmer): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 11 20:58:48 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Nov 2013 20:58:48 -0000 Subject: [GHC] #7229: Detecting if a process was killed by a signal is impossible In-Reply-To: <049.04c6e7b70db678da0226fa39d069be65@haskell.org> References: <049.04c6e7b70db678da0226fa39d069be65@haskell.org> Message-ID: <064.5db582ff2b2eabb1cfce668b4c9e4f25@haskell.org> #7229: Detecting if a process was killed by a signal is impossible --------------------------------------+------------------------------------ Reporter: benmachine | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: libraries/process | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by hvr): Replying to [comment:18 hvr]: > Ok, in summary I see the following possibilities for the return value of the existing `waitForProcess` call on POSIX systems: > > ... 5. PS/Just for the record: it would also be possible (since `WIFEXITED(s)` and `WIFSIGNALED(s)` are mutually exclusive) to encode signals as negative integers -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 11 22:28:07 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Nov 2013 22:28:07 -0000 Subject: [GHC] #7229: Detecting if a process was killed by a signal is impossible In-Reply-To: <049.04c6e7b70db678da0226fa39d069be65@haskell.org> References: <049.04c6e7b70db678da0226fa39d069be65@haskell.org> Message-ID: <064.7ca036c7d59909637dc0a2718f4cb36d@haskell.org> #7229: Detecting if a process was killed by a signal is impossible --------------------------------------+------------------------------------ Reporter: benmachine | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: libraries/process | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by hvr): So, the implementation of the last proposal ammmounts to two simple modifications: a patch to `process`: {{{#!diff diff --git a/cbits/runProcess.c b/cbits/runProcess.c index 3462cfc..3a6f2f3 100644 --- a/cbits/runProcess.c +++ b/cbits/runProcess.c @@ -22,12 +22,12 @@ UNIX versions ------------------------------------------------------------------------- */ -// -// If a process terminates with a signal, the exit status we return to -// via the System.Process API follows the Unix shell convention of -// (128 + signal). -// -#define TERMSIG_STATUS(r) ((r) | 0x80) +// If a process was terminated by a signal, the exit status we return +// via the System.Process API is (signum << 8); this avoids collision +// with normal process termination status codes, as according to +// http://pubs.opengroup.org/onlinepubs/9699919799/functions/wait.html +// WEXITSTATUS(s) returns an 8-bit value. See also #7229. +#define TERMSIG_STATUS(r) (r << 8) static long max_fd = 0; }}} ...and a patch for `base` (provided by duncan): {{{#!diff diff --git a/GHC/TopHandler.lhs b/GHC/TopHandler.lhs index 9e4bc07..b0c5d0d 100644 --- a/GHC/TopHandler.lhs +++ b/GHC/TopHandler.lhs @@ -180,7 +180,25 @@ flushStdHandles = do -- we have to use unsafeCoerce# to get the 'IO a' result type, since the -- compiler doesn't let us declare that as the result type of a foreign export. safeExit :: Int -> IO a +#ifdef mingw32_HOST_OS safeExit r = unsafeCoerce# (shutdownHaskellAndExit $ fromIntegral r) +#else +-- On Unix we use an encoding for the ExitCode: +-- high 7 bits signal, low 8 bits normal exit code. +-- People can also use ExitCode that do not correspond to Unix exit() +-- codes and we just use a replacement. +safeExit r + | sig /= 0 && code == 0 && other == 0 + = unsafeCoerce# (shutdownHaskellAndSignal $ fromIntegral sig) + | sig == 0 && other == 0 + = unsafeCoerce# (shutdownHaskellAndExit $ fromIntegral code) + | otherwise + = unsafeCoerce# (shutdownHaskellAndExit 0xff) + where + sig = (r .&. 0x7f00) `shiftR` 8 + code = r .&. 0x00ff + other = r .&. (complement 0x7fff) +#endif }}} If there are no objections left, I'll apply the changes above, `validate` (tweaking the testsuite if necessary) and push the changes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 11 23:07:56 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Nov 2013 23:07:56 -0000 Subject: [GHC] #8509: Doc Formatting - Patch Included In-Reply-To: <047.0136021a5f52b8cacd4f472da4a4b00e@haskell.org> References: <047.0136021a5f52b8cacd4f472da4a4b00e@haskell.org> Message-ID: <062.6a208a49a998cf82ecbbc59129e31fb4@haskell.org> #8509: Doc Formatting - Patch Included -------------------------------------+------------------------------------- Reporter: cschneid | Owner: Type: bug | Status: patch Priority: low | Milestone: Component: | Version: 7.6.3 libraries/directory | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: Documentation | hour) bug | Blocked By: Test Case: | Related Tickets: Blocking: | -------------------------------------+------------------------------------- Changes (by cschneid): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 11 23:18:28 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Nov 2013 23:18:28 -0000 Subject: [GHC] #7229: Detecting if a process was killed by a signal is impossible In-Reply-To: <049.04c6e7b70db678da0226fa39d069be65@haskell.org> References: <049.04c6e7b70db678da0226fa39d069be65@haskell.org> Message-ID: <064.6d1f98cf0e8f462a0e19508d38b10a7c@haskell.org> #7229: Detecting if a process was killed by a signal is impossible --------------------------------------+------------------------------------ Reporter: benmachine | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: libraries/process | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by andersk): Ugly but acceptable; I?m happy to come to a resolution on this issue, provided * The documentation clearly calls out that our encoding is byte-swapped from the standard one for historical reasons. * We might as well include the core dump bit as bit 15 for completeness. It?s useful for printing messages like `Segmentation fault (core dumped)`, and I don?t see a downside as long as we do it now. glibc, Perl, and Python all provide it as bit 7. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 12 00:47:54 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Nov 2013 00:47:54 -0000 Subject: [GHC] #8523: blowup in space/time for type checking and object size for high arity tuples Message-ID: <045.5997c88b50a3268ad761aba3d7c6d625@haskell.org> #8523: blowup in space/time for type checking and object size for high arity tuples -------------------------+------------------------------------------------- Reporter: | Owner: carter | Status: new Type: bug | Milestone: Priority: | Version: 7.6.3 normal | Operating System: Unknown/Multiple Component: | Type of failure: Compile-time performance bug Compiler | Test Case: Keywords: | Blocking: Architecture: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- Eric Mertens found a compilation performance issue in how GHC handles type class instance methods with many equality constraints and large arity tuples. basically using equality constraints to force 62 variables equal, instead of using the same variable for all the tuple slots, make the type checking time go from 0.9 seconds and very little memory to ~20 seconds and ~ 700mb of ram, along with going from ~ 7,000 coercions to 700,000-400,000 coercions, and object file size of 143kb to an object file size of 2.8mb-3.1mb I'm attaching 2 variants Tuple.hs and NeighborTuple.hs that exhibit the blowup behavior, and MonoTuple.hs (better named PolyTuple.hs but thats a side detail) that doesn't exhibit the blow up behavior. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 12 00:53:10 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Nov 2013 00:53:10 -0000 Subject: [GHC] #8523: blowup in space/time for type checking and object size for high arity tuples In-Reply-To: <045.5997c88b50a3268ad761aba3d7c6d625@haskell.org> References: <045.5997c88b50a3268ad761aba3d7c6d625@haskell.org> Message-ID: <060.27c261af516edf7b18794c483c4e037d@haskell.org> #8523: blowup in space/time for type checking and object size for high arity tuples -------------------------------------------------+------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time performance bug | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by carter): I think it'd be a good idea to understand this blowup. What I think is specially concerning is the increase in object code size, though that will require some exploration. I'd also like to understand why the equality constraints blow up the compile time. Do we need a better / more robust algorithm for handling the constraints. In some sense its a possible denial of service issue hypothetically. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 12 03:39:03 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Nov 2013 03:39:03 -0000 Subject: [GHC] #8524: GHC is inconsistent with the Haskell Report on which Unicode characters are allowed in string and character literals Message-ID: <045.aa22727e9338664a3617f731b2d178cd@haskell.org> #8524: GHC is inconsistent with the Haskell Report on which Unicode characters are allowed in string and character literals ----------------------------+---------------------------------------------- Reporter: oerjan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects valid program Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ----------------------------+---------------------------------------------- GHC is inconsistent with the Haskell Report on which Unicode characters are allowed in string and character literals. (And I don't like either option, why leave out any characters in strings unnecessarily?) Examples from ghci 7.6.3 (also tested in lambdabot on irc): {{{ Prelude> "?" -- Unicode char \8203, Format class. :10:2: lexical error in string/character literal at character '\8203' Prelude> "?" -- Unicode char \8202, Space class. "\8202" Prelude> "t\?\est" -- Unicode char \8202 in a string gap. :14:4: lexical error in string/character literal at character '\8202' }}} My reading of http://www.haskell.org/onlinereport/haskell2010/haskellch2.html (section 2.2 and 2.6): * The report BNF token "graphic", which can be used in literals, includes indirectly many Unicode classes, but uniWhite is not one of them. Thus the only Unicode whitespace allowed to represent itself in literals is ASCII space. * Unicode formatting characters are not mentioned in the BNF that I can see, so are not allowed in literals. * String gaps are made out of the report BNF token whitespace, which ''does'' include uniWhite. Who wants what: || ||= GHC =||= Report =||= Me =|| || Format in string || No || No || Yes || || Space/uniWhite in string || Yes || No || Yes || || Space/uniWhite in string gap || No || Yes || Dunno || In short, GHC's behavior is buggy and/or annoying in two opposite ways: * It leaves out some Unicode characters as allowable in strings and character literals, presumably because the report says so. * It allows some characters the report says it ''shouldn't'', and refuses some characters the report says it ''should''. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 12 07:59:22 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Nov 2013 07:59:22 -0000 Subject: [GHC] #7229: Detecting if a process was killed by a signal is impossible In-Reply-To: <049.04c6e7b70db678da0226fa39d069be65@haskell.org> References: <049.04c6e7b70db678da0226fa39d069be65@haskell.org> Message-ID: <064.d258b94ebc8b7aef5fe6aed0e2fede78@haskell.org> #7229: Detecting if a process was killed by a signal is impossible --------------------------------------+------------------------------------ Reporter: benmachine | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: libraries/process | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by hvr): Replying to [comment:30 andersk]: > * The documentation clearly calls out that our encoding is byte-swapped from the standard one for historical reasons. Yeah, I've planned to enhance the documentation related to `exitWith`, and for the two functions in `process` to reflect the new non-windows encoding. > * We might as well include the core dump bit as bit 15 for completeness. It?s useful for printing messages like `Segmentation fault (core dumped)`, and I don?t see a downside as long as we do it now. glibc, Perl, and Python all provide it as bit 7. ...I'm not against that, but what should `safeExit` do in that case? with the current patch this would cause `other /= 0` and thus terminate normally with exit code 255. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 12 08:17:47 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Nov 2013 08:17:47 -0000 Subject: [GHC] #8523: blowup in space/time for type checking and object size for high arity tuples In-Reply-To: <045.5997c88b50a3268ad761aba3d7c6d625@haskell.org> References: <045.5997c88b50a3268ad761aba3d7c6d625@haskell.org> Message-ID: <060.8d8f5936c4ca4b6341d40ff7644a9cfc@haskell.org> #8523: blowup in space/time for type checking and object size for high arity tuples -------------------------------------------------+------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time performance bug | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by dreixel): Perhaps related to #5642? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 12 08:49:27 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Nov 2013 08:49:27 -0000 Subject: [GHC] #8523: blowup in space/time for type checking and object size for high arity tuples In-Reply-To: <045.5997c88b50a3268ad761aba3d7c6d625@haskell.org> References: <045.5997c88b50a3268ad761aba3d7c6d625@haskell.org> Message-ID: <060.665477b8e27b9c4abe136d65ff666b28@haskell.org> #8523: blowup in space/time for type checking and object size for high arity tuples -------------------------------------------------+------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time performance bug | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by simonpj): I have not investigated yet (busy), but my nose tells me that it is indeed similar to #5642, and in particular is a symptom of Section 2.3 of [http://research.microsoft.com/en- us/um/people/simonpj/papers/variant-f/index.htm Scrap your type applications]. Bit I could be wrong. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 12 08:52:35 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Nov 2013 08:52:35 -0000 Subject: [GHC] #7229: Detecting if a process was killed by a signal is impossible In-Reply-To: <049.04c6e7b70db678da0226fa39d069be65@haskell.org> References: <049.04c6e7b70db678da0226fa39d069be65@haskell.org> Message-ID: <064.d952d602e8e6cfc9e771023dacc5bd32@haskell.org> #7229: Detecting if a process was killed by a signal is impossible --------------------------------------+------------------------------------ Reporter: benmachine | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: libraries/process | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by andersk): `safeExit` should just ignore the coredump flag. (The process can?t control whether the `SIG_DFL` action for that signal results in a core dump?the list of such signals is defined by the kernel, e.g. `SIG_KERNEL_COREDUMP_MASK` in Linux.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 12 09:00:06 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Nov 2013 09:00:06 -0000 Subject: [GHC] #7229: Detecting if a process was killed by a signal is impossible In-Reply-To: <049.04c6e7b70db678da0226fa39d069be65@haskell.org> References: <049.04c6e7b70db678da0226fa39d069be65@haskell.org> Message-ID: <064.6f2beb11877249529b4c962c65fc8e15@haskell.org> #7229: Detecting if a process was killed by a signal is impossible --------------------------------------+------------------------------------ Reporter: benmachine | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: libraries/process | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by hvr): Replying to [comment:32 andersk]: > `safeExit` should just ignore the coredump flag. (The process can?t control whether the `SIG_DFL` action for that signal results in a core dump?the list of such signals is defined by the kernel, e.g. `SIG_KERNEL_COREDUMP_MASK` in Linux.) ok, so - `safeExit 0x8300` would be handled like `safeExit 0x0300` but what should happen for the corner-cases - `safeExit 0x8000`, or - `safeExit 0x8001`, or - `safeExit 0x18000` ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 12 09:14:20 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Nov 2013 09:14:20 -0000 Subject: [GHC] #7229: Detecting if a process was killed by a signal is impossible In-Reply-To: <049.04c6e7b70db678da0226fa39d069be65@haskell.org> References: <049.04c6e7b70db678da0226fa39d069be65@haskell.org> Message-ID: <064.8c57b7f24869cbecf7c2b21adbd5896b@haskell.org> #7229: Detecting if a process was killed by a signal is impossible --------------------------------------+------------------------------------ Reporter: benmachine | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: libraries/process | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by andersk): I?d say we reject those corner cases and turn them into `0xff` like other unexpected values?we only allow the coredump flag in the signal case. (I don?t care strongly.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 12 09:47:36 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Nov 2013 09:47:36 -0000 Subject: [GHC] #6068: Panic in GHCi when using functional dependencies and promoted kinds In-Reply-To: <047.53daac14d65caa6ad1d72ce6ffc9d9ff@haskell.org> References: <047.53daac14d65caa6ad1d72ce6ffc9d9ff@haskell.org> Message-ID: <062.60b242be5fbe50792e2c33574fff103f@haskell.org> #6068: Panic in GHCi when using functional dependencies and promoted kinds -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.5 Resolution: | Keywords: PolyKinds Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Unknown Test Case: polykinds/T6068 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by nomeata): * cc: hvr (added) * status: closed => new * resolution: fixed => Comment: In a fresh checkout (95216e8fa0ecb98189dce29f0b89b3b0f8d439c6, `distclean`?ed and built), I get: {{{ =====> T6068(ghci) 2026 of 3814 [0, 0, 0] cd ./polykinds && HC='/home/jojo/build/haskell/ghc/inplace/bin/ghc-stage2' HC_OPTS='-dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history ' '/home/jojo/build/haskell/ghc/inplace/bin /ghc-stage2' --interactive -v0 -ignore-dot-ghci -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history T6068.run.stdout 2>T6068.run.stderr Actual stderr output differs from expected: --- /dev/null 2013-11-12 10:20:30.826690103 +0100 +++ ./polykinds/T6068.run.stderr 2013-11-12 10:39:54.333361005 +0100 @@ -0,0 +1,9 @@ +ghc-stage2: panic! (the 'impossible' happened) + (GHC version 7.7.20131108 for x86_64-unknown-linux): + ASSERT failed! + file compiler/typecheck/TcMType.lhs line 809 + [D] _ :: mp{tv aEn} [tau[0]] + ghc-prim:GHC.Types.~{(w) tc 31Q} kp_aEi{tv} [tau[0]] (CIrredEvCan) + +Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug + Actual stdout output differs from expected: --- ./polykinds/T6068.stdout 2013-10-05 15:18:57.118579683 +0200 +++ ./polykinds/T6068.run.stdout 2013-11-12 10:39:54.193361010 +0100 @@ -1 +0,0 @@ -exists Nothing :: Floop a mp => Existential mp *** unexpected failure for T6068(ghci) }}} Strangely, on [https://s3.amazonaws.com/archive.travis- ci.org/jobs/13835382/log.txt travis] it succeeded. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 12 12:08:17 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Nov 2013 12:08:17 -0000 Subject: [GHC] #6068: Panic in GHCi when using functional dependencies and promoted kinds In-Reply-To: <047.53daac14d65caa6ad1d72ce6ffc9d9ff@haskell.org> References: <047.53daac14d65caa6ad1d72ce6ffc9d9ff@haskell.org> Message-ID: <062.38251d67afffe0287f796e25e8f7a0cc@haskell.org> #6068: Panic in GHCi when using functional dependencies and promoted kinds -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.5 Resolution: | Keywords: PolyKinds Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Unknown Test Case: polykinds/T6068 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): With completely fresh check-outs, it does not happen using validate, but it does happen with `BuildFlavour = devel2`. So likely it is related to `-DDebug` in `GhcStage2HcOpts`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 12 12:57:37 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Nov 2013 12:57:37 -0000 Subject: [GHC] #6068: Panic in GHCi when using functional dependencies and promoted kinds In-Reply-To: <047.53daac14d65caa6ad1d72ce6ffc9d9ff@haskell.org> References: <047.53daac14d65caa6ad1d72ce6ffc9d9ff@haskell.org> Message-ID: <062.29120a7780f2399c44c3715005627569@haskell.org> #6068: Panic in GHCi when using functional dependencies and promoted kinds -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.5 Resolution: | Keywords: PolyKinds Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Unknown Test Case: polykinds/T6068 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Confirmed, the test fails with `-DDEBUG`. So is the debugging information wrong, or is there a real bug? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 12 14:40:01 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Nov 2013 14:40:01 -0000 Subject: [GHC] #8525: lib/integer/integerConstantFolding fails with -DDEBUG Message-ID: <046.5d4a4a7e5e2261c32eff470cf125498f@haskell.org> #8525: lib/integer/integerConstantFolding fails with -DDEBUG -------------------------------+------------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: integerConstantFolding Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------+------------------------------------------- Hi, with `-DDEBUG` in `GhcStage2HcOpts`, the test integerConstantFolding fails: {{{ =====> integerConstantFolding(normal) 1103 of 3814 [0, 1, 0] cd ./lib/integer && $MAKE -s --no-print-directory integerConstantFolding integerConstantFolding.run.stdout 2>integerConstantFolding.run.stderr Actual stderr output differs from expected: --- /dev/null 2013-11-12 10:54:14.804286745 +0100 +++ ./lib/integer/integerConstantFolding.run.stderr 2013-11-12 15:33:12.384669953 +0100 @@ -0,0 +1,62 @@ +WARNING: file compiler/stgSyn/CoreToStg.lhs, line 269 + lvl{v r3Ok} [gid] True False +WARNING: file compiler/stgSyn/CoreToStg.lhs, line 269 + lvl4{v r3Oo} [gid] True False +WARNING: file compiler/stgSyn/CoreToStg.lhs, line 269 + lvl8{v r3Os} [gid] True False +WARNING: file compiler/stgSyn/CoreToStg.lhs, line 269 + lvl12{v r3Ow} [gid] True False +WARNING: file compiler/stgSyn/CoreToStg.lhs, line 269 + ww1{v r3OO} [gid] True False +WARNING: file compiler/stgSyn/CoreToStg.lhs, line 269 + lvl48{v r3P7} [gid] True False +WARNING: file compiler/stgSyn/CoreToStg.lhs, line 269 + lvl52{v r3Pb} [gid] True False +WARNING: file compiler/stgSyn/CoreToStg.lhs, line 269 + lvl56{v r3Pf} [gid] True False +WARNING: file compiler/stgSyn/CoreToStg.lhs, line 269 + lvl60{v r3Pj} [gid] True False +WARNING: file compiler/stgSyn/CoreToStg.lhs, line 269 + lvl64{v r3Pn} [gid] True False +WARNING: file compiler/stgSyn/CoreToStg.lhs, line 269 + lvl68{v r3Pr} [gid] True False +WARNING: file compiler/stgSyn/CoreToStg.lhs, line 269 + ww2{v r3Pv} [gid] True False +WARNING: file compiler/stgSyn/CoreToStg.lhs, line 269 + ww3{v r3Pw} [gid] True False +WARNING: file compiler/stgSyn/CoreToStg.lhs, line 269 + ww4{v r3PG} [gid] True False +WARNING: file compiler/stgSyn/CoreToStg.lhs, line 269 + ww5{v r3PH} [gid] True False +WARNING: file compiler/stgSyn/CoreToStg.lhs, line 269 + lvl90{v r3PR} [gid] True False +WARNING: file compiler/stgSyn/CoreToStg.lhs, line 269 + lvl94{v r3PV} [gid] True False +WARNING: file compiler/stgSyn/CoreToStg.lhs, line 269 + lvl98{v r3PZ} [gid] True False +WARNING: file compiler/stgSyn/CoreToStg.lhs, line 269 + lvl102{v r3Q3} [gid] True False +WARNING: file compiler/stgSyn/CoreToStg.lhs, line 269 + lvl106{v r3Q7} [gid] True False +WARNING: file compiler/stgSyn/CoreToStg.lhs, line 269 + lvl110{v r3Qb} [gid] True False +WARNING: file compiler/stgSyn/CoreToStg.lhs, line 269 + lvl134{v r3Qz} [gid] True False +WARNING: file compiler/stgSyn/CoreToStg.lhs, line 269 + lvl138{v r3QD} [gid] True False +WARNING: file compiler/stgSyn/CoreToStg.lhs, line 269 + lvl142{v r3QH} [gid] True False +WARNING: file compiler/stgSyn/CoreToStg.lhs, line 269 + lvl146{v r3QL} [gid] True False +WARNING: file compiler/stgSyn/CoreToStg.lhs, line 269 + lvl153{v r3QS} [gid] True False +WARNING: file compiler/stgSyn/CoreToStg.lhs, line 269 + lvl161{v r3R0} [gid] True False +WARNING: file compiler/stgSyn/CoreToStg.lhs, line 269 + lvl165{v r3R4} [gid] True False +WARNING: file compiler/stgSyn/CoreToStg.lhs, line 269 + lvl169{v r3R8} [gid] True False +WARNING: file compiler/stgSyn/CoreToStg.lhs, line 269 + lvl173{v r3Rc} [gid] True False +WARNING: file compiler/stgSyn/CoreToStg.lhs, line 269 + lvl177{v r3Rg} [gid] True False *** unexpected failure for integerConstantFolding(normal) }}} The warning is in `consistentCafInfo` source:compiler/stgSyn/CoreToStg.lhs and was was last touched by SPJ in [fdf86568], and originally introduced by simmonmar in 2e6d322e130a8c37807a14699bbcbf9eb08fc970. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 12 14:57:44 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Nov 2013 14:57:44 -0000 Subject: [GHC] #7229: Detecting if a process was killed by a signal is impossible In-Reply-To: <049.04c6e7b70db678da0226fa39d069be65@haskell.org> References: <049.04c6e7b70db678da0226fa39d069be65@haskell.org> Message-ID: <064.a39bf9adcf469d41f2e558a92e1703ff@haskell.org> #7229: Detecting if a process was killed by a signal is impossible --------------------------------------+------------------------------------ Reporter: benmachine | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: libraries/process | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by duncan): Here's my updated patch. '''Totally untested''' {{{#!diff diff --git a/GHC/TopHandler.lhs b/GHC/TopHandler.lhs index 9e4bc07..8953334 100644 --- a/GHC/TopHandler.lhs +++ b/GHC/TopHandler.lhs @@ -180,7 +180,28 @@ flushStdHandles = do -- we have to use unsafeCoerce# to get the 'IO a' result type, since the -- compiler doesn't let us declare that as the result type of a foreign export. safeExit :: Int -> IO a +#ifdef mingw32_HOST_OS safeExit r = unsafeCoerce# (shutdownHaskellAndExit $ fromIntegral r) +#else +-- On Unix we use an encoding for the ExitCode: +-- Bits: 0-7 (mask 0x00ff) normal exit code +-- Bits: 8-14 (mask 0x7f00) exit by signal +-- Bits: 15 (mask 0x8000) core dump (allowed with signal but ignored) +-- A normal exit, and exit by signal are mutually exclusive. +-- For any invalid encoding we just use a replacement (0xff). +safeExit r + | sig /= 0 && code == 0 && other == 0 {-any cdump-} + = unsafeCoerce# (shutdownHaskellAndSignal $ fromIntegral sig) + | sig == 0 {-any code-} && other == 0 && cdump == 0 + = unsafeCoerce# (shutdownHaskellAndExit $ fromIntegral code) + | otherwise + = unsafeCoerce# (shutdownHaskellAndExit 0xff) + where + sig = (r .&. 0x7f00) `shiftR` 8 + cdump = r .&. 0x8000 + code = r .&. 0x00ff + other = r .&. (complement 0xffff) +#endif exitInterrupted :: IO a exitInterrupted = }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 12 15:07:24 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Nov 2013 15:07:24 -0000 Subject: [GHC] #8519: Make -XTemplateHaskell an error in a stage-1 compiler In-Reply-To: <046.3ef79a306c8292fd80a78cafcbd74b7f@haskell.org> References: <046.3ef79a306c8292fd80a78cafcbd74b7f@haskell.org> Message-ID: <061.b71a75b682361bac1b0fe54443ecd249@haskell.org> #8519: Make -XTemplateHaskell an error in a stage-1 compiler -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"4279665b08a5fed970b5eb37f85bde68bd7c68f9/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="4279665b08a5fed970b5eb37f85bde68bd7c68f9" Make -XTemplateHaskell an error in a stage-1 compiler (except with -M) Fixes Trac #8519 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 12 15:07:25 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Nov 2013 15:07:25 -0000 Subject: [GHC] #4268: Warning for ANN pragmas when GHCi is not supported In-Reply-To: <047.ede29838e1cb563fb2d34f66fbf6c1b7@haskell.org> References: <047.ede29838e1cb563fb2d34f66fbf6c1b7@haskell.org> Message-ID: <062.7f4055d6bd3e2f6c682733b6fdbba63c@haskell.org> #4268: Warning for ANN pragmas when GHCi is not supported -------------------------------+------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.0.4 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: Other | Blocked By: Test Case: | Related Tickets: #8312, #5105 Blocking: | -------------------------------+------------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"6c1aba4ff27371fddfc0dce5f9256c97edf16eea/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="6c1aba4ff27371fddfc0dce5f9256c97edf16eea" Warn if you use ANN annotations with a stage-1 compiler (Trac #4268) This makes us give a civilised warning when we hit an {-# ANN f foo #-} pragma in a stage-1 compiler. We decided that, since it's a pragma, it does not need a language extension flag to enable it. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 12 15:07:25 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Nov 2013 15:07:25 -0000 Subject: [GHC] #5996: fix for CSE In-Reply-To: <046.b2e909f9afbf1125d7f000dbe03b3cc0@haskell.org> References: <046.b2e909f9afbf1125d7f000dbe03b3cc0@haskell.org> Message-ID: <061.b4142496c4c48b9c15e7c3b44869d81c@haskell.org> #5996: fix for CSE --------------------------------------------+------------------------------ Reporter: michalt | Owner: simonpj Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"0001d161f7f6a6f7392eb2a3229f6204c3423450/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="0001d161f7f6a6f7392eb2a3229f6204c3423450" Fix egregious omission in CSE (Trac #5996) This patch fixes a bad omission in CSE, thanks to 'michaelt' for spotting it, and correctly identifying the fix (in cseRhs). The trouble was with x1 = C a b x2 = C x1 b y1 = C a b y2 = C y1 b we were not commoning up y2=x2, because we failed to substitute y1:=x1, so y2's RHS looked different to x2's I also refactoring, so taht the cs_map in a CSEnv map is cs_map :: CoreMap (OutExpr, Id) instead of cs_map :: CoreMap (OutExpr, OutExpr) Much nicer! This doesn't make much difference to allocation, but it gives a surprisingly big benefit to binary size. -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- ansi -1.7% -0.8% 0.00 0.00 +0.0% bspt -1.6% -1.5% 0.01 0.01 +0.0% cacheprof -1.8% -0.2% +1.6% +1.9% +2.7% fft -1.4% -1.3% 0.06 0.06 +11.1% ida -1.4% -1.0% 0.12 0.12 +0.0% rfib -1.4% -0.1% 0.03 0.03 +0.0% scs -1.6% -0.1% +1.5% +1.5% +0.0% spectral-norm -1.3% -0.1% -0.2% -0.2% +0.0% tak -1.4% -0.1% 0.02 0.02 +0.0% veritas -1.4% -0.1% 0.00 0.00 +0.0% -------------------------------------------------------------------------------- Min -2.5% -1.5% -11.8% -11.8% -8.0% Max -1.0% +0.0% +2.7% +2.5% +11.1% Geometric Mean -1.3% -0.1% -2.6% -2.6% +0.0% }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 12 15:07:47 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Nov 2013 15:07:47 -0000 Subject: [GHC] #8507: ConstraintKinds TH regression from 7.6 -> 7.7 In-Reply-To: <044.279c8d9fc60344afededa9adb9a13c1a@haskell.org> References: <044.279c8d9fc60344afededa9adb9a13c1a@haskell.org> Message-ID: <059.8a0be3f654514a08d441a09ff0472f3a@haskell.org> #8507: ConstraintKinds TH regression from 7.6 -> 7.7 ----------------------------------------------+---------------------------- Reporter: errge | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Template Haskell | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: th/T8507 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by Simon Peyton Jones ): In [changeset:"12155437ae9cc6bade3beb209c188859b2867799/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="12155437ae9cc6bade3beb209c188859b2867799" Test Trac #8507 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 12 15:07:48 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Nov 2013 15:07:48 -0000 Subject: [GHC] #8518: panic ghci when probably using type families incorrectly In-Reply-To: <048.6fb8bd551db19740f383c6e83d846014@haskell.org> References: <048.6fb8bd551db19740f383c6e83d846014@haskell.org> Message-ID: <063.3d4c4879cbf8555a274ad2d55ad77c21@haskell.org> #8518: panic ghci when probably using type families incorrectly -------------------------------------+------------------------------ Reporter: HanStolpo | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: ghci panic Operating System: Unknown/Multiple | Architecture: x86 Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"5ecd306e9420b0b4df3432c54555a183e8fe097d/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="5ecd306e9420b0b4df3432c54555a183e8fe097d" Test Trac #8518 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 12 15:10:22 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Nov 2013 15:10:22 -0000 Subject: [GHC] #8514: Non-ideal error with a kind error in a tuple In-Reply-To: <047.4c9258367aa20f601907b38889acede0@haskell.org> References: <047.4c9258367aa20f601907b38889acede0@haskell.org> Message-ID: <062.690e57211ca0c58cb230040d539c70cd@haskell.org> #8514: Non-ideal error with a kind error in a tuple --------------------------------------------+------------------------------ Reporter: monoidal | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler (Type checker) | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #7410 --------------------------------------------+------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"961203b585aac003a32ac0000456bdd742dba4d9/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="961203b585aac003a32ac0000456bdd742dba4d9" Improve typechecking of tuples (Trac #8514) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 12 15:10:22 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Nov 2013 15:10:22 -0000 Subject: [GHC] #8522: exprType incorrect for let expressions which bind types In-Reply-To: <046.74e9c81df2ed72c1bafb41228d3f51e0@haskell.org> References: <046.74e9c81df2ed72c1bafb41228d3f51e0@haskell.org> Message-ID: <061.3cdc052eaeb34a51fe201a375781ee70@haskell.org> #8522: exprType incorrect for let expressions which bind types -------------------------------------+------------------------------------ Reporter: afarmer | Owner: Type: bug | Status: patch Priority: high | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"96e6eddc40c34a171f6261a7814a1e264457ce86/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="96e6eddc40c34a171f6261a7814a1e264457ce86" Make exprType work correctly in the presnce of type bindings (Trac #8522) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 12 15:17:39 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Nov 2013 15:17:39 -0000 Subject: [GHC] #6068: Panic in GHCi when using functional dependencies and promoted kinds In-Reply-To: <047.53daac14d65caa6ad1d72ce6ffc9d9ff@haskell.org> References: <047.53daac14d65caa6ad1d72ce6ffc9d9ff@haskell.org> Message-ID: <062.5f926415f1c7369adab1db24f9c9d066@haskell.org> #6068: Panic in GHCi when using functional dependencies and promoted kinds -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.5 Resolution: | Keywords: PolyKinds Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Unknown Test Case: polykinds/T6068 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): I think there's a real bug. I'm looking at it -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 12 15:20:27 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Nov 2013 15:20:27 -0000 Subject: [GHC] #4268: Warning for ANN pragmas when GHCi is not supported In-Reply-To: <047.ede29838e1cb563fb2d34f66fbf6c1b7@haskell.org> References: <047.ede29838e1cb563fb2d34f66fbf6c1b7@haskell.org> Message-ID: <062.2cdb2997250ebb912897eadf2d23c694@haskell.org> #4268: Warning for ANN pragmas when GHCi is not supported -------------------------------+------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.0.4 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: Other | Blocked By: Test Case: | Related Tickets: #8312, #5105 Blocking: | -------------------------------+------------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: I don't know how to make a test that runs the stage-1 compiler and it's not that important, so I'm closing without a regression test. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 12 15:20:43 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Nov 2013 15:20:43 -0000 Subject: [GHC] #8519: Make -XTemplateHaskell an error in a stage-1 compiler In-Reply-To: <046.3ef79a306c8292fd80a78cafcbd74b7f@haskell.org> References: <046.3ef79a306c8292fd80a78cafcbd74b7f@haskell.org> Message-ID: <061.1aff4f67c017e2851bd09838bd64cc58@haskell.org> #8519: Make -XTemplateHaskell an error in a stage-1 compiler -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonpj): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 12 15:23:43 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Nov 2013 15:23:43 -0000 Subject: [GHC] #5996: fix for CSE In-Reply-To: <046.b2e909f9afbf1125d7f000dbe03b3cc0@haskell.org> References: <046.b2e909f9afbf1125d7f000dbe03b3cc0@haskell.org> Message-ID: <061.a84699db5fee6cc83a0a1bd2a9467a8e@haskell.org> #5996: fix for CSE --------------------------------------------+------------------------------ Reporter: michalt | Owner: simonpj Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonpj): Commit message properly formatted {{{ Fix egregious omission in CSE (Trac #5996) This patch fixes a bad omission in CSE, thanks to 'michaelt' for spotting it, and correctly identifying the fix (in cseRhs). The trouble was with x1 = C a b x2 = C x1 b y1 = C a b y2 = C y1 b we were not commoning up y2=x2, because we failed to substitute y1:=x1, so y2's RHS looked different to x2's I also refactoring, so taht the cs_map in a CSEnv map is cs_map :: CoreMap (OutExpr, Id) instead of cs_map :: CoreMap (OutExpr, OutExpr) Much nicer! This doesn't make much difference to allocation, but it gives a surprisingly big benefit to binary size. -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- ansi -1.7% -0.8% 0.00 0.00 +0.0% bspt -1.6% -1.5% 0.01 0.01 +0.0% cacheprof -1.8% -0.2% +1.6% +1.9% +2.7% fft -1.4% -1.3% 0.06 0.06 +11.1% ida -1.4% -1.0% 0.12 0.12 +0.0% rfib -1.4% -0.1% 0.03 0.03 +0.0% scs -1.6% -0.1% +1.5% +1.5% +0.0% spectral-norm -1.3% -0.1% -0.2% -0.2% +0.0% tak -1.4% -0.1% 0.02 0.02 +0.0% veritas -1.4% -0.1% 0.00 0.00 +0.0% -------------------------------------------------------------------------------- Min -2.5% -1.5% -11.8% -11.8% -8.0% Max -1.0% +0.0% +2.7% +2.5% +11.1% Geometric Mean -1.3% -0.1% -2.6% -2.6% +0.0% }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 12 15:26:13 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Nov 2013 15:26:13 -0000 Subject: [GHC] #8518: panic ghci when probably using type families incorrectly In-Reply-To: <048.6fb8bd551db19740f383c6e83d846014@haskell.org> References: <048.6fb8bd551db19740f383c6e83d846014@haskell.org> Message-ID: <063.c8fe68bde3f189cc561a49041f96bb39@haskell.org> #8518: panic ghci when probably using type families incorrectly -------------------------------------------------+------------------------- Reporter: HanStolpo | Owner: Type: bug | Status: Priority: normal | closed Component: Compiler | Milestone: Resolution: fixed | Version: 7.6.3 Operating System: Unknown/Multiple | Keywords: ghci Type of failure: GHCi crash | panic Test Case: | Architecture: x86 indexed_types/should_fail/T8518 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by simonpj): * testcase: => indexed_types/should_fail/T8518 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 12 15:26:38 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Nov 2013 15:26:38 -0000 Subject: [GHC] #8522: exprType incorrect for let expressions which bind types In-Reply-To: <046.74e9c81df2ed72c1bafb41228d3f51e0@haskell.org> References: <046.74e9c81df2ed72c1bafb41228d3f51e0@haskell.org> Message-ID: <061.0a76c8a6379c81bd92a3804655bf2d3b@haskell.org> #8522: exprType incorrect for let expressions which bind types -------------------------------------+------------------------------------ Reporter: afarmer | Owner: Type: bug | Status: patch Priority: high | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): OK done. I'd implemented it slightly differently -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 12 15:27:06 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Nov 2013 15:27:06 -0000 Subject: [GHC] #8522: exprType incorrect for let expressions which bind types In-Reply-To: <046.74e9c81df2ed72c1bafb41228d3f51e0@haskell.org> References: <046.74e9c81df2ed72c1bafb41228d3f51e0@haskell.org> Message-ID: <061.ea68b3546436df905c5784d1af6f5ad4@haskell.org> #8522: exprType incorrect for let expressions which bind types -------------------------------------+------------------------------------ Reporter: afarmer | Owner: Type: bug | Status: closed Priority: high | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonpj): * status: patch => closed * resolution: => fixed Comment: It's not easy to make a test case, so closing. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 12 15:27:35 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Nov 2013 15:27:35 -0000 Subject: [GHC] #7229: Detecting if a process was killed by a signal is impossible In-Reply-To: <049.04c6e7b70db678da0226fa39d069be65@haskell.org> References: <049.04c6e7b70db678da0226fa39d069be65@haskell.org> Message-ID: <064.703f07b1f7b7e52e59c0c20abf355493@haskell.org> #7229: Detecting if a process was killed by a signal is impossible --------------------------------------+------------------------------------ Reporter: benmachine | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: libraries/process | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by duncan): Unclear if we also want to do something with `fastExit`, as used by `runIOFastExit` and `topHandlerFastExit`. If so, we need an extra function like `shutdownHaskellAndSignal` but that doesn't do the hs_exit_() call. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 12 15:30:10 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Nov 2013 15:30:10 -0000 Subject: [GHC] #8514: Non-ideal error with a kind error in a tuple In-Reply-To: <047.4c9258367aa20f601907b38889acede0@haskell.org> References: <047.4c9258367aa20f601907b38889acede0@haskell.org> Message-ID: <062.4fc8cf2826b277294c48365aef417823@haskell.org> #8514: Non-ideal error with a kind error in a tuple --------------------------------------------+------------------------------ Reporter: monoidal | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler (Type checker) | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #7410 --------------------------------------------+------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"286b45a1dce09eb7b057df5d137b629b3acc97d4/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="286b45a1dce09eb7b057df5d137b629b3acc97d4" Test Trac #8514 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 12 15:32:16 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Nov 2013 15:32:16 -0000 Subject: [GHC] #8514: Non-ideal error with a kind error in a tuple In-Reply-To: <047.4c9258367aa20f601907b38889acede0@haskell.org> References: <047.4c9258367aa20f601907b38889acede0@haskell.org> Message-ID: <062.324ea6640d23c5d6e3864db9c870a6d2@haskell.org> #8514: Non-ideal error with a kind error in a tuple ------------------------------------------------+-------------------------- Reporter: monoidal | Owner: Type: bug | Status: closed Priority: lowest | Milestone: Component: Compiler (Type checker) | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: typecheck/should_fail/T8514 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: #7410 ------------------------------------------------+-------------------------- Changes (by simonpj): * status: new => closed * testcase: => typecheck/should_fail/T8514 * resolution: => fixed Comment: Thank you! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 12 16:20:53 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Nov 2013 16:20:53 -0000 Subject: [GHC] #7229: Detecting if a process was killed by a signal is impossible In-Reply-To: <049.04c6e7b70db678da0226fa39d069be65@haskell.org> References: <049.04c6e7b70db678da0226fa39d069be65@haskell.org> Message-ID: <064.2a93a98771bb5b8987f86e7e2ca33aa0@haskell.org> #7229: Detecting if a process was killed by a signal is impossible --------------------------------------+------------------------------------ Reporter: benmachine | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: libraries/process | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Changes (by hvr): * priority: high => highest Comment: (just upgrading priority to increase visibility of this ticket) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 12 18:06:42 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Nov 2013 18:06:42 -0000 Subject: [GHC] #8224: Excessive system time -- new IO manager problem? In-Reply-To: <047.560f2473b19a53c27f0a194339ba0f97@haskell.org> References: <047.560f2473b19a53c27f0a194339ba0f97@haskell.org> Message-ID: <062.52d141fb4146eeee93013d4a4b2e8e5a@haskell.org> #8224: Excessive system time -- new IO manager problem? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Resolution: | Keywords: IO Manager, Operating System: Linux | System Time Type of failure: Runtime | Architecture: x86_64 (amd64) performance bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by AndreasVoellmy): I'm not sure about the 8 minutes problem, but the 200ms system time for the empty program does indeed seem to be related to the parallel IO manager changes. I just modified the IO manager to start only one epoll instance and I get about 50 ms system time, whereas with HEAD I get about 200ms still. I will upload the patch to make the IO manager use just one poller in case anyone else wants to try it. Some data... With just one poller, strace -C gives: {{{ % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 100.00 0.000046 1 40 getrusage 0.00 0.000000 0 7 read 0.00 0.000000 0 1 write 0.00 0.000000 0 51 42 open 0.00 0.000000 0 9 close 0.00 0.000000 0 8 6 stat 0.00 0.000000 0 8 fstat 0.00 0.000000 0 90 mmap 0.00 0.000000 0 46 mprotect 0.00 0.000000 0 15 munmap 0.00 0.000000 0 16 brk 0.00 0.000000 0 12 rt_sigaction 0.00 0.000000 0 7 rt_sigprocmask 0.00 0.000000 0 1 rt_sigreturn 0.00 0.000000 0 1 ioctl 0.00 0.000000 0 8 8 access 0.00 0.000000 0 1 pipe 0.00 0.000000 0 32 clone 0.00 0.000000 0 1 execve 0.00 0.000000 0 8 fcntl 0.00 0.000000 0 1 getrlimit 0.00 0.000000 0 1 getuid 0.00 0.000000 0 1 getgid 0.00 0.000000 0 1 geteuid 0.00 0.000000 0 1 getegid 0.00 0.000000 0 1 arch_prctl 0.00 0.000000 0 101 2 futex 0.00 0.000000 0 1 epoll_create 0.00 0.000000 0 1 set_tid_address 0.00 0.000000 0 1 timer_create 0.00 0.000000 0 2 timer_settime 0.00 0.000000 0 1 timer_delete 0.00 0.000000 0 2 epoll_ctl 0.00 0.000000 0 1 set_robust_list 0.00 0.000000 0 1 eventfd2 ------ ----------- ----------- --------- --------- ---------------- 100.00 0.000046 479 58 total }}} On the other hand, with N pollers (i.e. HEAD) strace -C gives: {{{ % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 86.21 0.002356 21 114 2 futex 8.67 0.000237 18 13 rt_sigaction 5.12 0.000140 1 263 fcntl 0.00 0.000000 0 8 read 0.00 0.000000 0 1 write 0.00 0.000000 0 52 42 open 0.00 0.000000 0 10 close 0.00 0.000000 0 8 6 stat 0.00 0.000000 0 9 fstat 0.00 0.000000 0 74 mmap 0.00 0.000000 0 46 mprotect 0.00 0.000000 0 10 munmap 0.00 0.000000 0 19 brk 0.00 0.000000 0 5 rt_sigprocmask 0.00 0.000000 0 1 rt_sigreturn 0.00 0.000000 0 1 ioctl 0.00 0.000000 0 8 8 access 0.00 0.000000 0 33 pipe 0.00 0.000000 0 32 clone 0.00 0.000000 0 1 execve 0.00 0.000000 0 1 getrlimit 0.00 0.000000 0 1 getuid 0.00 0.000000 0 1 getgid 0.00 0.000000 0 1 geteuid 0.00 0.000000 0 1 getegid 0.00 0.000000 0 1 arch_prctl 0.00 0.000000 0 32 epoll_create 0.00 0.000000 0 1 set_tid_address 0.00 0.000000 0 1 timer_create 0.00 0.000000 0 2 timer_settime 0.00 0.000000 0 1 timer_delete 0.00 0.000000 0 4 clock_gettime 0.00 0.000000 0 64 epoll_ctl 0.00 0.000000 0 1 set_robust_list 0.00 0.000000 0 33 eventfd2 ------ ----------- ----------- --------- --------- ---------------- 100.00 0.002733 853 58 total }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 12 18:57:22 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Nov 2013 18:57:22 -0000 Subject: [GHC] #8224: Excessive system time -- new IO manager problem? In-Reply-To: <047.560f2473b19a53c27f0a194339ba0f97@haskell.org> References: <047.560f2473b19a53c27f0a194339ba0f97@haskell.org> Message-ID: <062.f45bb50f8d8931ff63a10bb81ade453a@haskell.org> #8224: Excessive system time -- new IO manager problem? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Resolution: | Keywords: IO Manager, Operating System: Linux | System Time Type of failure: Runtime | Architecture: x86_64 (amd64) performance bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by AndreasVoellmy): Replying to [comment:8 simonmar]: > 200ms spent doing unspecified "initialization" should definitely be investigated, that's a lot. I can't see anything useful in that call stack, it looks like it might be related to signals or epoll() but it's hard to tell anything else. > > What does the `+RTS -s` look like? With my "one poller" hack: {{{ 48,624 bytes allocated in the heap 40 bytes copied during GC 38,592 bytes maximum residency (1 sample(s)) 268,608 bytes maximum slop 32 MB total memory in use (15 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 0 colls, 0 par 0.00s 0.00s 0.0000s 0.0000s Gen 1 1 colls, 0 par 0.00s 0.00s 0.0003s 0.0003s Parallel GC work balance: -nan (0 / 0, ideal 32) MUT time (elapsed) GC time (elapsed) Task 0 (worker) : 0.00s ( 0.00s) 0.00s ( 0.00s) Task 1 (worker) : 0.00s ( 0.00s) 0.00s ( 0.00s) Task 2 (bound) : 0.00s ( 0.00s) 0.00s ( 0.00s) Task 3 (worker) : 0.01s ( 0.01s) 0.00s ( 0.00s) Task 4 (worker) : 0.02s ( 0.01s) 0.00s ( 0.00s) Task 5 (worker) : 0.01s ( 0.01s) 0.00s ( 0.00s) Task 6 (worker) : 0.01s ( 0.01s) 0.00s ( 0.00s) Task 7 (worker) : 0.01s ( 0.01s) 0.00s ( 0.00s) Task 8 (worker) : 0.02s ( 0.01s) 0.00s ( 0.00s) Task 9 (worker) : 0.01s ( 0.01s) 0.00s ( 0.00s) Task 10 (worker) : 0.02s ( 0.01s) 0.00s ( 0.00s) Task 11 (worker) : 0.01s ( 0.01s) 0.00s ( 0.00s) Task 12 (worker) : 0.02s ( 0.01s) 0.00s ( 0.00s) Task 13 (worker) : 0.01s ( 0.01s) 0.00s ( 0.00s) Task 14 (worker) : 0.01s ( 0.01s) 0.00s ( 0.00s) Task 15 (worker) : 0.01s ( 0.01s) 0.00s ( 0.00s) Task 16 (worker) : 0.01s ( 0.01s) 0.00s ( 0.00s) Task 17 (worker) : 0.01s ( 0.01s) 0.00s ( 0.00s) Task 18 (worker) : 0.01s ( 0.01s) 0.00s ( 0.00s) Task 19 (worker) : 0.01s ( 0.01s) 0.00s ( 0.00s) Task 20 (worker) : 0.01s ( 0.01s) 0.00s ( 0.00s) Task 21 (worker) : 0.01s ( 0.01s) 0.00s ( 0.00s) Task 22 (worker) : 0.01s ( 0.01s) 0.00s ( 0.00s) Task 23 (worker) : 0.01s ( 0.01s) 0.00s ( 0.00s) Task 24 (worker) : 0.00s ( 0.01s) 0.00s ( 0.00s) Task 25 (worker) : 0.00s ( 0.01s) 0.00s ( 0.00s) Task 26 (worker) : 0.00s ( 0.01s) 0.00s ( 0.00s) Task 27 (worker) : 0.00s ( 0.01s) 0.00s ( 0.00s) Task 28 (worker) : 0.01s ( 0.01s) 0.00s ( 0.00s) Task 29 (worker) : 0.01s ( 0.01s) 0.00s ( 0.00s) Task 30 (worker) : 0.01s ( 0.01s) 0.00s ( 0.00s) Task 31 (worker) : 0.01s ( 0.01s) 0.00s ( 0.00s) Task 32 (worker) : 0.01s ( 0.01s) 0.00s ( 0.00s) Task 33 (worker) : 0.01s ( 0.01s) 0.00s ( 0.00s) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.00s ( 0.01s elapsed) MUT time 0.00s ( 0.00s elapsed) GC time 0.00s ( 0.00s elapsed) EXIT time 0.01s ( 0.00s elapsed) Total time 0.02s ( 0.01s elapsed) Alloc rate 2,431,200 bytes per MUT second Productivity 80.0% of total user, 132.3% of total elapsed gc_alloc_block_sync: 0 whitehole_spin: 0 gen[0].sync: 0 gen[1].sync: 0 }}} With HEAD: {{{ 543,096 bytes allocated in the heap 64 bytes copied during GC 412,256 bytes maximum residency (1 sample(s)) 279,968 bytes maximum slop 18 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 0 colls, 0 par 0.00s 0.00s 0.0000s 0.0000s Gen 1 1 colls, 0 par 0.00s 0.00s 0.0009s 0.0009s Parallel GC work balance: -nan% (serial 0%, perfect 100%) TASKS: 65 (1 bound, 64 peak workers (64 total), using -N32) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.04s ( 0.03s elapsed) MUT time 0.00s ( -0.00s elapsed) GC time 0.00s ( 0.00s elapsed) EXIT time 0.01s ( 0.00s elapsed) Total time 0.05s ( 0.04s elapsed) Alloc rate 0 bytes per MUT second Productivity 17.4% of total user, 24.7% of total elapsed gc_alloc_block_sync: 0 whitehole_spin: 0 gen[0].sync: 0 gen[1].sync: 0 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 12 19:16:39 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Nov 2013 19:16:39 -0000 Subject: [GHC] #2301: Proper handling of SIGINT/SIGQUIT In-Reply-To: <045.f06a53427920f75d02000e2372e27573@haskell.org> References: <045.f06a53427920f75d02000e2372e27573@haskell.org> Message-ID: <060.3e46b2bff8ea120e5d871832dd489588@haskell.org> #2301: Proper handling of SIGINT/SIGQUIT -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: | Version: 6.12.3 libraries/process | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: POSIX | Difficulty: Unknown Type of failure: Incorrect result | Blocked By: at runtime | Related Tickets: Test Case: | #3994,#5766,#7229,#4274,#3318,#1619 Blocking: | -------------------------------------+------------------------------------- Changes (by hvr): * cc: hvr (added) * priority: normal => high * os: Unknown/Multiple => POSIX * milestone: 7.6.2 => 7.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 12 21:11:50 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Nov 2013 21:11:50 -0000 Subject: [GHC] #8526: -fforce-recomp does not re-summarise modules Message-ID: <044.a874b1b60feee8d3abbe2c98f3ab0e0a@haskell.org> #8526: -fforce-recomp does not re-summarise modules ------------------------------------+------------------------------------- Reporter: parcs | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- -fforce-recomp should re-summarise modules so that the source file will get re-preprocessed. Otherwise a modification to an `#include`'d file will not get picked up. {{{ $ ghci -XCPP -v0 -fforce-recomp Prelude> :! echo '#include "A.hs-inc"' > A.hs Prelude> :! echo 'a = True' > A.hs-inc Prelude> :l A *Main> a True *Main> :! echo 'a = False' > A.hs-inc *Main> :r *Main> a True *Main> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 12 21:18:56 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Nov 2013 21:18:56 -0000 Subject: [GHC] #4900: DEPENDS pragma In-Reply-To: <046.52f138a2609bf72d7f5381a2c64d358e@haskell.org> References: <046.52f138a2609bf72d7f5381a2c64d358e@haskell.org> Message-ID: <061.6150a88b413db024416274911dfd7825@haskell.org> #4900: DEPENDS pragma -------------------------------------+------------------------------------ Reporter: cdsmith | Owner: parcs Type: feature request | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: TH_Depends | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by parcs): I hit a couple of obstacles regarding the implementation: 1. There is no way to distinguish between usage files added via TH and other usage files (e.g. #included files). This is necessary to avoid re- summarization when only the former kind of usage file has changed. 2. The usage files of a boot module get lost after compiling the corresponding source module. This means that modifying a usage file included by a boot module will not trigger recompilation in GHCi. The first obstacle could be solved by adding a new field to the `UsageFile` constructor containing the kind of usage file (LINE pragma, #include, TH, etc..) and checking only the relevant kinds of usage files during re-summarisation. I don't know what could be done about 2nd obstacle, though. It looks like we can't depend on reading the HPT during the downsweep since the the boot interface gets overwritten by the source interface after the source module gets compiled. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 12 22:54:52 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Nov 2013 22:54:52 -0000 Subject: [GHC] #7229: Detecting if a process was killed by a signal is impossible In-Reply-To: <049.04c6e7b70db678da0226fa39d069be65@haskell.org> References: <049.04c6e7b70db678da0226fa39d069be65@haskell.org> Message-ID: <064.20e4b0d1ddb6125e334daad41bc92f89@haskell.org> #7229: Detecting if a process was killed by a signal is impossible --------------------------------------+------------------------------------ Reporter: benmachine | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: libraries/process | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by Herbert Valerio Riedel ): In [changeset:"ffe7773c7fd222a946d17f489020098a45b5c8af/process"]: {{{ #!CommitTicketReference repository="process" revision="ffe7773c7fd222a946d17f489020098a45b5c8af" Change exit code encoding of `waitForProcess` yet again This changes the exit code encoding from `(128+signum)` (as introduced via 5403824028) to {{{#!hs if coredump then 0x8000 else 0 .|. signum `shiftL` 8 .|. exitstatus }}} in order to address the `process`-package part of #7229 Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 12 23:42:41 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Nov 2013 23:42:41 -0000 Subject: [GHC] #5996: fix for CSE In-Reply-To: <046.b2e909f9afbf1125d7f000dbe03b3cc0@haskell.org> References: <046.b2e909f9afbf1125d7f000dbe03b3cc0@haskell.org> Message-ID: <061.7f3c77a5b3ef55b1fc0e7d9e16cd01c2@haskell.org> #5996: fix for CSE --------------------------------------------+------------------------------ Reporter: michalt | Owner: simonpj Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"a80663d37b7a8c834537c700528383a65e50fbdf/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="a80663d37b7a8c834537c700528383a65e50fbdf" Test Trac #5996 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 12 23:44:42 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Nov 2013 23:44:42 -0000 Subject: [GHC] #5996: fix for CSE In-Reply-To: <046.b2e909f9afbf1125d7f000dbe03b3cc0@haskell.org> References: <046.b2e909f9afbf1125d7f000dbe03b3cc0@haskell.org> Message-ID: <061.8add2576ac91100ceb914090c3683129@haskell.org> #5996: fix for CSE -------------------------------------------------+------------------------- Reporter: michalt | Owner: Type: bug | simonpj Priority: normal | Status: Component: Compiler | closed Resolution: fixed | Milestone: 7.8.1 Operating System: Unknown/Multiple | Version: 7.5 Type of failure: Runtime performance bug | Keywords: Test Case: | Architecture: simplCore/should_compile/T5996 | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by simonpj): * status: patch => closed * testcase: => simplCore/should_compile/T5996 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 13 00:30:45 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Nov 2013 00:30:45 -0000 Subject: [GHC] #8224: Excessive system time -- new IO manager problem? In-Reply-To: <047.560f2473b19a53c27f0a194339ba0f97@haskell.org> References: <047.560f2473b19a53c27f0a194339ba0f97@haskell.org> Message-ID: <062.636dc1651d4e8d4f8ba580386d8b17e2@haskell.org> #8224: Excessive system time -- new IO manager problem? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Resolution: | Keywords: IO Manager, Operating System: Linux | System Time Type of failure: Runtime | Architecture: x86_64 (amd64) performance bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by AndreasVoellmy): I did some more experiments, and I now think it has to do with making "safe" foreign calls from all of the 32 threads. I modified the IO manager so that all of the polling threads (and their epoll backends) are created. Only one of the them is used (on cap 0) is used to register files. I then modified the poll loops so that only the one on cap 0 is running the normal polling loop and the others simply return right away. With this setup, the performance is good (about 40-50 ms for -N32). However, if I have all poll loops (except the one normal poll loop for cap 0) simply make a "safe" call to `usleep(10)` then the performance goes back to about 200ms. I'll post a patch here so that others can see. So it looks to be related to the cost of doing safe foreign calls. With the parallel IO manager each of the N pollers will make a safe foreign call when there is no work to do. I'm not sure that this will have much of an impact on most programs, but for the empty program it represents a large part of the work. I'm also not sure this is related to the 8 minute system time mentioned in the original report. rnewton, can you provide a recipe for how to recreate this? Is the 200 ms startup time for 32 cores an issue? At 16 cores it is about 50-60ms and at 8 cores about 10-20ms. One possible resolution (besides doing nothing or making safe foreign calls cheaper) would be to provide an RTS option to use a specific number of IO managers, or at least to differentiate between using 1 or using N. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 13 02:44:14 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Nov 2013 02:44:14 -0000 Subject: [GHC] #8527: container's Typeable.h is being shadowed by base's Typeable.h during preprocessing Message-ID: <044.9e25da1df7745d2b97e644bd03393477@haskell.org> #8527: container's Typeable.h is being shadowed by base's Typeable.h during preprocessing ------------------------------------+------------------------------------- Reporter: parcs | Owner: parcs Type: bug | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Here's a reduced test case: == cpp.hs == {{{ #!haskell {-# LANGUAGE CPP #-} #include "Typeable.h" main = return () }}} == command line == {{{ $ ghc-stage2 -c -package base cpp.hs In file included from cpp.hs:4:0: /home/patrick/code/ghc/libraries/base/include/Typeable.h:17:2: warning: #warning is obsolete and will be removed in GHC 7.10 [-Wcpp] #warning is obsolete and will be removed in GHC 7.10 ^ compilation IS NOT required $ ghc-stage2 -c -package base -package containers cpp.hs compilation IS NOT required $ ghc-stage2 -c -package containers -package base cpp.hs }}} Notice that if I pass `-package containers` to ghc, the cpp warning from Typeable.h (from the base library) doesn't appear. This is because containers also has a Typeable.h in its include path, and in the invocation of the preprocessor, containers' include path precedes base's no matter how I order the `-package` directives. This behavior is intuitive and limiting. To fix this, I think that the ordering of -I directives passed to the preprocessor should be consistent with the ordering of -package directives passed to ghc. For example, in the above test case, a warning should be shown in the 1st and 2nd invocations of ghc but not the 3rd, because in the 3rd invocation containers precedes base. Does this sound okay? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 13 02:47:01 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Nov 2013 02:47:01 -0000 Subject: [GHC] #8526: -fforce-recomp does not re-summarise modules In-Reply-To: <044.a874b1b60feee8d3abbe2c98f3ab0e0a@haskell.org> References: <044.a874b1b60feee8d3abbe2c98f3ab0e0a@haskell.org> Message-ID: <059.b5ee3a15adfe5da9fd2c06d576cba1cf@haskell.org> #8526: -fforce-recomp does not re-summarise modules -------------------------------------+------------------------------------ Reporter: parcs | Owner: parcs Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by parcs): * owner: => parcs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 13 03:39:56 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Nov 2013 03:39:56 -0000 Subject: [GHC] #8527: container's Typeable.h is being shadowed by base's Typeable.h during preprocessing In-Reply-To: <044.9e25da1df7745d2b97e644bd03393477@haskell.org> References: <044.9e25da1df7745d2b97e644bd03393477@haskell.org> Message-ID: <059.2a74150d39a09ebbcfc5f5c6820f63d5@haskell.org> #8527: container's Typeable.h is being shadowed by base's Typeable.h during preprocessing -------------------------------------+------------------------------------ Reporter: parcs | Owner: parcs Type: bug | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Patrick Palka ): In [changeset:"117b6b8d8088ff237fc72f75e290fc30207e7bed/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="117b6b8d8088ff237fc72f75e290fc30207e7bed" Remove unnecessary and deprecated inclusions of Typeable.h The build system would've complained loudly about these inclusions if it weren't for #8527. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 13 06:19:21 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Nov 2013 06:19:21 -0000 Subject: [GHC] #8528: Preprocessor issues building GHC HEAD on Mavericks Message-ID: <044.9e43150f2d22b2782c0ffcb891a3cae9@haskell.org> #8528: Preprocessor issues building GHC HEAD on Mavericks ----------------------------------+---------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: Building GHC failed Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+---------------------------------------- I can't build GHC HEAD on Mavericks with Xcode 5 and GCC 4.2. My system: * Mavericks, Xcode 5. * Building with GHC 7.6.3 x64 installed from . * Apple GCC 4.2 installed via homebrew. In /Library/Frameworks/GHC.framework/Versions/7.6.3-x86_64/usr/lib/ghc-7.6.3/settings, I've changed the compiled to this: ("C compiler command", "/Users/nkpart/bin/gcc"), ~/bin/gcc is #!/bin/sh echo $* >> ~/bin/gcc_log gcc-4.2 $@ I have run: $ git clone .. $ perl boot $ ./configure $ make The error I get is: "/usr/bin/ghc" -M -static -H64m -O0 -fasm -package-db libraries/bootstrapping.conf -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 -dep-makefile utils/genprimopcode/dist/build/.depend.haskell.tmp -dep-suffix "" -include-pkg-deps utils/genprimopcode/dist/build/Lexer.hs utils/genprimopcode/./Main.hs utils/genprimopcode/./ParserM.hs utils/genprimopcode/dist/build/Parser.hs utils/genprimopcode/./Syntax.hs line-map.c: file "templates/GenericTemplate.hs" left but not entered utils/genprimopcode/dist/build/Lexer.hs:143:0: error: #else without #if utils/genprimopcode/dist/build/Lexer.hs:144:0: warning: "GTE" redefined utils/genprimopcode/dist/build/Lexer.hs:141:0: warning: this is the location of the previous definition utils/genprimopcode/dist/build/Lexer.hs:145:0: warning: "EQ" redefined utils/genprimopcode/dist/build/Lexer.hs:142:0: warning: this is the location of the previous definition utils/genprimopcode/dist/build/Lexer.hs:146:0: error: #endif without #if utils/genprimopcode/dist/build/Lexer.hs:197:0: error: #else without #if utils/genprimopcode/dist/build/Lexer.hs:200:0: error: #endif without #if make[1]: *** [utils/genprimopcode/dist/build/.depend.haskell] Error 1 make: *** [all] Error 2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 13 06:54:29 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Nov 2013 06:54:29 -0000 Subject: [GHC] #8528: Preprocessor issues building GHC HEAD on Mavericks In-Reply-To: <044.9e43150f2d22b2782c0ffcb891a3cae9@haskell.org> References: <044.9e43150f2d22b2782c0ffcb891a3cae9@haskell.org> Message-ID: <059.c2dbb3b791a221eaf13ceb42e9168933@haskell.org> #8528: Preprocessor issues building GHC HEAD on Mavericks ----------------------------------------+---------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by nkpart): The gcc command that it fails on is this: {{{ gcc -E -undef -traditional -m64 -fno-stack-protector -m64 -I utils/genprimopcode/dist/build -I utils/genprimopcode/dist/build -I utils/genprimopcode/dist/build/autogen -I /Library/Frameworks/GHC.framework/Versions/7.6.3-x86_64/usr/lib/ghc-7.6.3/base-4.6.0.1/include -I /Library/Frameworks/GHC.framework/Versions/7.6.3-x86_64/usr/lib/ghc-7.6.3/include -D__GLASGOW_HASKELL__=706 -Ddarwin_BUILD_OS=1 -Dx86_64_BUILD_ARCH=1 -Ddarwin_HOST_OS=1 -Dx86_64_HOST_ARCH=1 -U __PIC__ -D__PIC__ -x c utils/genprimopcode/dist/build/Lexer.hs -o /var/folders/s6/tzn1w8qn3vbdym7p74zs62lr0000gn/T/ghc49990_0/ghc49990_0.hscpp }}} I can run that command outside of the build and replicate the failure (as long as I change the `-o`). It fails with gcc-4.2 and gcc-4.8. However, it works with clang. Does the build try and guess if I've got fake clang gcc or apple-gcc installed? Could it be getting that wrong? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 13 07:26:28 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Nov 2013 07:26:28 -0000 Subject: [GHC] #8528: Preprocessor issues building GHC HEAD on Mavericks In-Reply-To: <044.9e43150f2d22b2782c0ffcb891a3cae9@haskell.org> References: <044.9e43150f2d22b2782c0ffcb891a3cae9@haskell.org> Message-ID: <059.ca92aed67a08e97a053bbd4b0a86759d@haskell.org> #8528: Preprocessor issues building GHC HEAD on Mavericks ----------------------------------------+---------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by carter): huh, this is really weird! Can we get someone else with a machine that has Mavericks to try to repro this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 13 07:59:49 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Nov 2013 07:59:49 -0000 Subject: [GHC] #8528: Preprocessor issues building GHC HEAD on Mavericks In-Reply-To: <044.9e43150f2d22b2782c0ffcb891a3cae9@haskell.org> References: <044.9e43150f2d22b2782c0ffcb891a3cae9@haskell.org> Message-ID: <059.7f992d35d145566e44bc55b5cf92c652@haskell.org> #8528: Preprocessor issues building GHC HEAD on Mavericks ----------------------------------------+---------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: clang Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8480 ----------------------------------------+---------------------------------- Changes (by hvr): * keywords: => clang * priority: normal => high * related: => #8480 Old description: > I can't build GHC HEAD on Mavericks with Xcode 5 and GCC 4.2. > > My system: > > * Mavericks, Xcode 5. > * Building with GHC 7.6.3 x64 installed from . > * Apple GCC 4.2 installed via homebrew. > > In > /Library/Frameworks/GHC.framework/Versions/7.6.3-x86_64/usr/lib/ghc-7.6.3/settings, > I've changed the compiled to this: > > ("C compiler command", "/Users/nkpart/bin/gcc"), > > ~/bin/gcc is > > #!/bin/sh > echo $* >> ~/bin/gcc_log > gcc-4.2 $@ > > I have run: > > $ git clone .. > $ perl boot > $ ./configure > $ make > > The error I get is: > > "/usr/bin/ghc" -M -static -H64m -O0 -fasm -package-db > libraries/bootstrapping.conf -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 -dep-makefile > utils/genprimopcode/dist/build/.depend.haskell.tmp -dep-suffix "" > -include-pkg-deps utils/genprimopcode/dist/build/Lexer.hs > utils/genprimopcode/./Main.hs utils/genprimopcode/./ParserM.hs > utils/genprimopcode/dist/build/Parser.hs utils/genprimopcode/./Syntax.hs > line-map.c: file "templates/GenericTemplate.hs" left but not entered > > utils/genprimopcode/dist/build/Lexer.hs:143:0: > error: #else without #if > > utils/genprimopcode/dist/build/Lexer.hs:144:0: > warning: "GTE" redefined > > utils/genprimopcode/dist/build/Lexer.hs:141:0: > warning: this is the location of the previous definition > > utils/genprimopcode/dist/build/Lexer.hs:145:0: > warning: "EQ" redefined > > utils/genprimopcode/dist/build/Lexer.hs:142:0: > warning: this is the location of the previous definition > > utils/genprimopcode/dist/build/Lexer.hs:146:0: > error: #endif without #if > > utils/genprimopcode/dist/build/Lexer.hs:197:0: > error: #else without #if > > utils/genprimopcode/dist/build/Lexer.hs:200:0: > error: #endif without #if > make[1]: *** [utils/genprimopcode/dist/build/.depend.haskell] Error 1 > make: *** [all] Error 2 New description: I can't build GHC HEAD on Mavericks with Xcode 5 and GCC 4.2. My system: * Mavericks, Xcode 5. * Building with GHC 7.6.3 x64 installed from . * Apple GCC 4.2 installed via homebrew. In `/Library/Frameworks/GHC.framework/Versions/7.6.3-x86_64/usr/lib/ghc-7.6.3/settings`, I've changed the compiled to this: {{{ ("C compiler command", "/Users/nkpart/bin/gcc"), }}} `~/bin/gcc` is {{{ #!/bin/sh echo $* >> ~/bin/gcc_log gcc-4.2 $@ }}} I have run: {{{ $ git clone .. $ perl boot $ ./configure $ make }}} The error I get is: {{{ "/usr/bin/ghc" -M -static -H64m -O0 -fasm -package-db libraries/bootstrapping.conf -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 -dep-makefile utils/genprimopcode/dist/build/.depend.haskell.tmp -dep-suffix "" -include-pkg-deps utils/genprimopcode/dist/build/Lexer.hs utils/genprimopcode/./Main.hs utils/genprimopcode/./ParserM.hs utils/genprimopcode/dist/build/Parser.hs utils/genprimopcode/./Syntax.hs line-map.c: file "templates/GenericTemplate.hs" left but not entered utils/genprimopcode/dist/build/Lexer.hs:143:0: error: #else without #if utils/genprimopcode/dist/build/Lexer.hs:144:0: warning: "GTE" redefined utils/genprimopcode/dist/build/Lexer.hs:141:0: warning: this is the location of the previous definition utils/genprimopcode/dist/build/Lexer.hs:145:0: warning: "EQ" redefined utils/genprimopcode/dist/build/Lexer.hs:142:0: warning: this is the location of the previous definition utils/genprimopcode/dist/build/Lexer.hs:146:0: error: #endif without #if utils/genprimopcode/dist/build/Lexer.hs:197:0: error: #else without #if utils/genprimopcode/dist/build/Lexer.hs:200:0: error: #endif without #if make[1]: *** [utils/genprimopcode/dist/build/.depend.haskell] Error 1 make: *** [all] Error 2 }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 13 08:36:43 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Nov 2013 08:36:43 -0000 Subject: [GHC] #8512: Add flag like '-xc' that only reports uncaught exceptions In-Reply-To: <048.82b1fcc5113161d6daef1f786f24006e@haskell.org> References: <048.82b1fcc5113161d6daef1f786f24006e@haskell.org> Message-ID: <063.90a07d0d633b8d5a95319becf05578bd@haskell.org> #8512: Add flag like '-xc' that only reports uncaught exceptions -------------------------------------+------------------------------------ Reporter: blitzcode | Owner: simonmar Type: feature request | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => wontfix Comment: The problem is that there are never any uncaught exceptions. All exceptions are caught at by something, even if it is only the outermost default exception handler that we install for all threads. Typically most exceptions will be caught and re-thrown multiple times by things like `bracket`. I agree it's noisy and undesirable, but I don't think there's anything we can do at the RTS level for `-xc`. However, there is ongoing work on stack traces which should eventually provide better facilities here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 13 09:16:48 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Nov 2013 09:16:48 -0000 Subject: [GHC] #8224: Excessive system time -- new IO manager problem? In-Reply-To: <047.560f2473b19a53c27f0a194339ba0f97@haskell.org> References: <047.560f2473b19a53c27f0a194339ba0f97@haskell.org> Message-ID: <062.0c68239e51b84bd14281506a09aa4a3b@haskell.org> #8224: Excessive system time -- new IO manager problem? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Resolution: | Keywords: IO Manager, Operating System: Linux | System Time Type of failure: Runtime | Architecture: x86_64 (amd64) performance bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by simonmar): The first safe call on each Capability will cause the creation of a new OS thread, which probably accounts for some of the cost. From the strace profile it looks like there is some contention too. It might be useful to do some mutex profiling to see what lock is being contended for - perhaps it is `all_tasks_mutex`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 13 09:24:44 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Nov 2013 09:24:44 -0000 Subject: [GHC] #4268: Warning for ANN pragmas when GHCi is not supported In-Reply-To: <047.ede29838e1cb563fb2d34f66fbf6c1b7@haskell.org> References: <047.ede29838e1cb563fb2d34f66fbf6c1b7@haskell.org> Message-ID: <062.d96a69776e872fc9f6420ae43818e22a@haskell.org> #4268: Warning for ANN pragmas when GHCi is not supported -------------------------------+------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.0.4 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: Other | Blocked By: Test Case: | Related Tickets: #8312, #5105 Blocking: | -------------------------------+------------------------------------------- Comment (by simonmar): Might have been slightly better to say "this is a stage-1 compiler or doesn't support GHCi" or somesuch, because some platforms just don't support GHCi. Not a big deal though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 13 09:27:39 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Nov 2013 09:27:39 -0000 Subject: [GHC] #8521: Tight loop prevents other threads from running in available cores In-Reply-To: <056.1462ccb14964f58201abc5dcbd1962c4@haskell.org> References: <056.1462ccb14964f58201abc5dcbd1962c4@haskell.org> Message-ID: <071.5e62f09b4dfe540f50d553c1e7c4241e@haskell.org> #8521: Tight loop prevents other threads from running in available cores --------------------------------------+---------------------------------- Reporter: facundo.dominguez | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+---------------------------------- Changes (by simonmar): * status: new => closed * resolution: => duplicate Comment: Dup of #367 If `-fno-omit-yields` does ''not'' fix the problem (with GHC 7.7+), then please re-open the ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 13 09:43:58 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Nov 2013 09:43:58 -0000 Subject: [GHC] #8198: One-shot mode is buggy w.r.t. hs-boot files In-Reply-To: <044.066addbaba47f1aa4fead928a038d103@haskell.org> References: <044.066addbaba47f1aa4fead928a038d103@haskell.org> Message-ID: <059.c122a53b569887f16710c6dde881e31b@haskell.org> #8198: One-shot mode is buggy w.r.t. hs-boot files -------------------------------------------------+------------------------- Reporter: parcs | Owner: parcs Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Driver | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect warning at | Unknown/Multiple compile-time | Difficulty: Test Case: | Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by simonmar): ooh, inline diffs. Funky. It's not true that "every location in the finder cache corresponds to a module's source files only". In one-shot mode, the finder cache is full of locations that only have `.hi` files. See `findHomeModule`, and `hi_exts`. I think we should be calling `mkHiOnlyModLocation` here, because in one- shot mode that is what is normally used to create `ModLocation`s that go in the finder cache. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 13 10:03:24 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Nov 2013 10:03:24 -0000 Subject: [GHC] #5899: RTS crash w/ strange closure type 603975781 on OS X 10.8 In-Reply-To: <046.0180bf563efb64918c194490fa2c58fe@haskell.org> References: <046.0180bf563efb64918c194490fa2c58fe@haskell.org> Message-ID: <061.30b1df7b97ec874c3b37b85488dae5bc@haskell.org> #5899: RTS crash w/ strange closure type 603975781 on OS X 10.8 -------------------------+------------------------------------------------- Reporter: | Owner: dylukes | Status: closed Type: bug | Milestone: 7.4.2 Priority: high | Version: 7.4.1 Component: | Keywords: rts, strange closure, Runtime System | internal error, os x Resolution: | Architecture: x86_64 (amd64) worksforme | Difficulty: Unknown Operating System: | Blocked By: MacOS X | Related Tickets: Type of failure: | Runtime crash | Test Case: | Blocking: | -------------------------+------------------------------------------------- Comment (by simonmar): CoreyOConnor: this particular error message indicates general corruption in the heap, and has many different causes. This particular ticket turned out to be a bug in the XCode linker, which went away subsequently. Please open a separate ticket. My educated guess is that your bug will turn out to be something related to the plugins package that yi uses. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 13 10:13:07 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Nov 2013 10:13:07 -0000 Subject: [GHC] #8528: Preprocessor issues building GHC HEAD on Mavericks In-Reply-To: <044.9e43150f2d22b2782c0ffcb891a3cae9@haskell.org> References: <044.9e43150f2d22b2782c0ffcb891a3cae9@haskell.org> Message-ID: <059.e7f897147a60522a8ba36c881950a8d3@haskell.org> #8528: Preprocessor issues building GHC HEAD on Mavericks ----------------------------------------+---------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: clang Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8480 ----------------------------------------+---------------------------------- Comment (by nkpart): Aha! I have a fix. Although I'm still pretty confused about where the bug really is. Initially, I installed the latest versions of alex (3.1.2) and happy (1.19.1) available on hackage. These were updated in the last couple of days. Rolling back alex to 3.1.0 seems to resolve it. I the clean rebuild process I used was: {{{ # Change the alex link git clean -fdx perl boot ./configure make }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 13 11:02:54 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Nov 2013 11:02:54 -0000 Subject: [GHC] #8174: GHC should not load packages for TH if they are not used In-Reply-To: <042.1ed57189b3c7e645a380321c747a4ab5@haskell.org> References: <042.1ed57189b3c7e645a380321c747a4ab5@haskell.org> Message-ID: <057.314d6850c0304fb78b364eee45b6d158@haskell.org> #8174: GHC should not load packages for TH if they are not used -------------------------------------------------+------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time performance bug | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by akio): #2437 and #3560 seem to be related to this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 13 12:37:03 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Nov 2013 12:37:03 -0000 Subject: [GHC] #8529: Sequent reading from socket/connection on Windows fails Message-ID: <047.0bcc31cddfb5771ca556c838f2877e1c@haskell.org> #8529: Sequent reading from socket/connection on Windows fails -------------------------------------+------------------------------------- Reporter: Heimdell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.4.2 libraries/haskell2010 | Operating System: Windows Keywords: sockets, windows, | Type of failure: Incorrect result read failure | at runtime Architecture: Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- I wrote a simple TCP-client, which consumes and produces 8-byte packets. When I run it on linux, it works perfectly, being part of the loop (write- read-write-read-...). On windows it receives only first msg from the other side (write-read- write-write-...). The packets are still going, although. Before that, I used the sockets directly; changing to HandleStream didn't help. The code is: {{{ transmit :: Int -> HandleStream ByteString -> ByteString -> IO [Bytestring] transmit delay sock packet = do let input = timeout delay $ sock `readBlock` 8 <* putStrLn "\nData was read!" sock `writeBlock` pack strings <- whileJust input return [str | Right str <- strings] whileJust action = do result <- action case result of Just a -> (:) <$> return a <*> whileJust action Nothing -> return [] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 13 14:32:06 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Nov 2013 14:32:06 -0000 Subject: [GHC] #8224: Excessive system time -- new IO manager problem? In-Reply-To: <047.560f2473b19a53c27f0a194339ba0f97@haskell.org> References: <047.560f2473b19a53c27f0a194339ba0f97@haskell.org> Message-ID: <062.7d1f17bacd051a616e3c7e10c1c0a252@haskell.org> #8224: Excessive system time -- new IO manager problem? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Resolution: | Keywords: IO Manager, Operating System: Linux | System Time Type of failure: Runtime | Architecture: x86_64 (amd64) performance bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by AndreasVoellmy): I ran with mutrace and did see any obvious explanations. Is it possible that by having more safe foreign calls RTS threads spend more time in some spin locks? If so, which spin locks would those be? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 13 15:03:02 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Nov 2013 15:03:02 -0000 Subject: [GHC] #8224: Excessive system time -- new IO manager problem? In-Reply-To: <047.560f2473b19a53c27f0a194339ba0f97@haskell.org> References: <047.560f2473b19a53c27f0a194339ba0f97@haskell.org> Message-ID: <062.f23819396d59b0761be07b8202410338@haskell.org> #8224: Excessive system time -- new IO manager problem? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Resolution: | Keywords: IO Manager, Operating System: Linux | System Time Type of failure: Runtime | Architecture: x86_64 (amd64) performance bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by AndreasVoellmy): One interesting thing I just noticed is that `taskset` makes a big difference. `excessive_system_2_HEAD` is the empty program compiled with HEAD and `excessive_system_2_ONEACTIVELOOP` is the empty program compiled with only one IO manager loop being started. We see that for `excessive_system_2_HEAD` if we use `taskset` to restrict the threads to run on CPUs 0-9 (all on one NUMA node) we get a big difference: {{{ $ time ./excessive_system_2_HEAD +RTS -N32 real 0m0.046s user 0m0.020s sys 0m0.188s }}} {{{ $ time taskset -c 0-9 ./excessive_system_2_HEAD +RTS -N32 real 0m0.025s user 0m0.000s sys 0m0.056s }}} `excessive_system_2_ONEACTIVELOOP` also performs better with taskset but the difference is much smaller. Without taskset I see system tim from 30ms-60ms and with taskset it is about 10-20ms. So maybe the explanation is that with 31 extra safe foreign calls (from calls to `epoll_wait`) we get about 31 extra OS threads and if we are unlucky and the OS schedules these on different NUMA nodes we will get cache issues slowing down. And finally a spin lock burns longer accounting for more system time? Here is a run of `excessive_system_2_HEAD` using taskset to restrict to first NUMA node or no restrictions with perf stat: {{{ $ perf_3.2.0-25 stat taskset -c 0-9 ./excessive_system_2_HEAD +RTS -N32 Performance counter stats for 'taskset -c 0-9 ./excessive_system_2_HEAD +RTS -N32': 25.019318 task-clock # 0.900 CPUs utilized 584 context-switches # 0.023 M/sec 218 CPU-migrations # 0.009 M/sec 1,248 page-faults # 0.050 M/sec 36,387,323 cycles # 1.454 GHz [62.17%] 26,057,951 stalled-cycles-frontend # 71.61% frontend cycles idle [98.77%] 17,556,988 stalled-cycles-backend # 48.25% backend cycles idle 22,358,612 instructions # 0.61 insns per cycle # 1.17 stalled cycles per insn 4,300,427 branches # 171.884 M/sec 169,950 branch-misses # 3.95% of all branches [42.87%] 0.027811151 seconds time elapsed }}} {{{ $ perf_3.2.0-25 stat taskset -c 0-79 ./excessive_system_2_HEAD +RTS -N32 Performance counter stats for 'taskset -c 0-79 ./excessive_system_2_HEAD +RTS -N32': 157.684408 task-clock # 3.055 CPUs utilized 588 context-switches # 0.004 M/sec 147 CPU-migrations # 0.001 M/sec 1,245 page-faults # 0.008 M/sec 267,826,389 cycles # 1.698 GHz [54.94%] 227,802,954 stalled-cycles-frontend # 85.06% frontend cycles idle [66.06%] 184,677,238 stalled-cycles-backend # 68.95% backend cycles idle [86.81%] 70,842,584 instructions # 0.26 insns per cycle # 3.22 stalled cycles per insn [98.87%] 16,579,295 branches # 105.142 M/sec [96.70%] 233,921 branch-misses # 1.41% of all branches [97.31%] 0.051618204 seconds time elapsed }}} It is interesting that without restriction we get many more instructions executed and also fewer instructions per cycle. Also interesting, here are the top few entries perf recording with taskset 0-9 {{{ 5.64% excessive_syste [kernel.kallsyms] [k] update_sd_lb_stats 5.47% excessive_syste [kernel.kallsyms] [k] resched_task 4.97% excessive_syste excessive_system_2_HEAD [.] evacuate1 4.84% excessive_syste [kernel.kallsyms] [k] __ticket_spin_lock 4.18% excessive_syste libc-2.15.so [.] _int_malloc 3.85% excessive_syste [kernel.kallsyms] [k] __init_waitqueue_head 3.81% excessive_syste [kernel.kallsyms] [k] dequeue_entity 3.48% excessive_syste [kernel.kallsyms] [k] find_vma 3.14% excessive_syste [kernel.kallsyms] [k] native_write_msr_safe 3.12% excessive_syste [kernel.kallsyms] [k] source_load 3.12% excessive_syste [kernel.kallsyms] [k] idle_cpu 2.62% excessive_syste [kernel.kallsyms] [k] update_cfs_rq_blocked_load 2.33% excessive_syste [kernel.kallsyms] [k] perf_event_mmap_ctx 2.13% excessive_syste [kernel.kallsyms] [k] kmem_cache_alloc 2.07% excessive_syste excessive_system_2_HEAD [.] schedule }}} and with no restriction {{{ 43.82% excessive_syste [kernel.kallsyms] [k] __ticket_spin_lock 6.44% excessive_syste [kernel.kallsyms] [k] default_send_IPI_mask_sequence_phys 4.68% excessive_syste [kernel.kallsyms] [k] native_write_msr_safe 3.45% excessive_syste [kernel.kallsyms] [k] update_sd_lb_stats 3.31% excessive_syste libc-2.15.so [.] new_heap 2.86% excessive_syste [kernel.kallsyms] [k] idle_cpu 2.40% excessive_syste [kernel.kallsyms] [k] perf_event_mmap 1.61% excessive_syste [kernel.kallsyms] [k] __schedule 1.60% excessive_syste excessive_system_2_HEAD [.] s8Bc_info 1.56% excessive_syste [kernel.kallsyms] [k] inherit_event.isra.73 1.50% excessive_syste [kernel.kallsyms] [k] __init_waitqueue_head 1.49% excessive_syste libc-2.15.so [.] __clone 1.45% excessive_syste [kernel.kallsyms] [k] clear_page_c 1.44% excessive_syste [kernel.kallsyms] [k] try_to_wake_up }}} Pretty clearly spending more time in a spin lock when we run on all NUMA nodes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 13 17:00:22 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Nov 2013 17:00:22 -0000 Subject: [GHC] #8515: Biographical profiling (-hb) crashes, other profiling modes have truncated output In-Reply-To: <048.c7e4a832e375c0962ebd5fbc8e1e03c8@haskell.org> References: <048.c7e4a832e375c0962ebd5fbc8e1e03c8@haskell.org> Message-ID: <063.601be5ecf89c4a877baf4c18ab57bbfa@haskell.org> #8515: Biographical profiling (-hb) crashes, other profiling modes have truncated output -----------------------------------+---------------------------- Reporter: blitzcode | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86 Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+---------------------------- Changes (by simonmar): * priority: normal => highest * milestone: => 7.8.1 Comment: I am seeing some problems with `+RTS -hb`, which seem to be because the code generator is leaving slop in the heap sometimes. I've been working on a patch to the code generator to fix this, but unfortunately it doesn't validate yet because it makes stage2 crash (and nothing else, as far as I can tell). Still working on it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 13 17:39:42 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Nov 2013 17:39:42 -0000 Subject: [GHC] #7229: Detecting if a process was killed by a signal is impossible In-Reply-To: <049.04c6e7b70db678da0226fa39d069be65@haskell.org> References: <049.04c6e7b70db678da0226fa39d069be65@haskell.org> Message-ID: <064.5969eb52b82d09c28daf8aab6bee6a0e@haskell.org> #7229: Detecting if a process was killed by a signal is impossible --------------------------------------+------------------------------------ Reporter: benmachine | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: libraries/process | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by duncan): Heh, turns out python switched to using -N for signals. See popen. http://docs.python.org/2/library/subprocess.html#subprocess.Popen.returncode -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 13 18:00:05 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Nov 2013 18:00:05 -0000 Subject: [GHC] #7229: Detecting if a process was killed by a signal is impossible In-Reply-To: <049.04c6e7b70db678da0226fa39d069be65@haskell.org> References: <049.04c6e7b70db678da0226fa39d069be65@haskell.org> Message-ID: <064.adc50e50d74676cf09505e5da783edf4@haskell.org> #7229: Detecting if a process was killed by a signal is impossible --------------------------------------+------------------------------------ Reporter: benmachine | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: libraries/process | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by duncan): @andersk just to play devil's advocate for a moment: why not use negative encoding for signals, and just ignore the core dump bit? It gives an encoding that is very simple to use and very few people care about core dumps (and if they do, they can use the unix package). `-n` is a lot easier than {{{(n .&. 0x7f00) `shiftR` 8}}}. Indeed people are likely to do it wrong and just use {{{n `shiftR` 8}}} in which case they'll get tripped up whenever there is a core dump (which is platform configuration specific). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 14 00:24:36 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Nov 2013 00:24:36 -0000 Subject: [GHC] #8206: Add support for Portable Native Client In-Reply-To: <044.0e9301156a0eb3e01f0cb8995b726d63@haskell.org> References: <044.0e9301156a0eb3e01f0cb8995b726d63@haskell.org> Message-ID: <059.ca977036db2143208e08b4cc9336c74a@haskell.org> #8206: Add support for Portable Native Client -------------------------+------------------------------------------------- Reporter: | Owner: Alex Sayers guest | Status: new Type: | Milestone: feature request | Version: Priority: | Keywords: NaCl PNaCl Portable Native normal | Client pexe Component: | Architecture: Unknown/Multiple Compiler | Difficulty: Project (more than a week) Resolution: | Blocked By: Operating System: | Related Tickets: Unknown/Multiple | Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------+------------------------------------------------- Changes (by ydewit): * cc: ydewit@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 14 02:23:49 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Nov 2013 02:23:49 -0000 Subject: [GHC] #8528: Preprocessor issues building GHC HEAD on Mavericks In-Reply-To: <044.9e43150f2d22b2782c0ffcb891a3cae9@haskell.org> References: <044.9e43150f2d22b2782c0ffcb891a3cae9@haskell.org> Message-ID: <059.70e809732a7ca86c5eb766a9ac98df61@haskell.org> #8528: Preprocessor issues building GHC HEAD on Mavericks ----------------------------------------+---------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: clang Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8480 ----------------------------------------+---------------------------------- Comment (by nkpart): Diffing the generated Lexer.hs file: {{{ ? diff Lexer-3.1.0.hs Lexer-3.1.2.hs 123,124c123,124 < {-# LINE 1 "" #-} < {-# LINE 1 "templates/GenericTemplate.hs" #-} --- > # 1 "" 1 > # 1 "templates/GenericTemplate.hs" 2 133a134 > 140c141 < #if __GLASGOW_HASKELL__ > 706 --- > #if __GLASGOW_HASKELL__ > 706 146a148 > 194c196 < #if __GLASGOW_HASKELL__ < 503 --- > #if __GLASGOW_HASKELL__ < 503 281a284 > 297a301 > 301a306 > }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 14 02:43:54 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Nov 2013 02:43:54 -0000 Subject: [GHC] #8526: -fforce-recomp does not re-summarise modules In-Reply-To: <044.a874b1b60feee8d3abbe2c98f3ab0e0a@haskell.org> References: <044.a874b1b60feee8d3abbe2c98f3ab0e0a@haskell.org> Message-ID: <059.f582700d08a7308eb065eb0725537d0e@haskell.org> #8526: -fforce-recomp does not re-summarise modules -------------------------------------+------------------------------------ Reporter: parcs | Owner: parcs Type: bug | Status: patch Priority: normal | Milestone: Component: Driver | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by parcs): * status: new => patch Comment: Do this patch look OK? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 14 03:07:31 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Nov 2013 03:07:31 -0000 Subject: [GHC] #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough In-Reply-To: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> References: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> Message-ID: <062.32506bfb3bb0b58602cbbd65c7de66f5@haskell.org> #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): Posted this to ghc-devs. Realizing it makes more sense here: I've run up against a limitation of `Coercible` I'd like to know more about. Currently, the stage2 compiler on my branch fails to build because of the problem. In Module.lhs, there is this line: {{{ newtype PackageId = PId FastString deriving( Eq, Typeable ) }}} The deriving mechanism sensibly prefers to use the GND mechanism when it can, and it can (seemingly) for `Eq` here. But, I get this error: {{{ compiler/basicTypes/Module.lhs:297:46: No instance for (ghc-prim:GHC.Types.Coercible FastString PackageId) because ?PackageId? is a recursive type constuctor }}} This is curious, because `PackageId` is manifestly ''not'' recursive. A little poking around tells me that any datatype mentioned in a .hs-boot file is considered recursive. There is sense to this, but the error message sure is confusing. In any case, this opens up a broader issue: we want GND to work with recursive newtypes. For example: {{{ class C a where meth :: a instance C (Either a String) where meth = Right "" newtype RecNT = MkRecNT (Either RecNT String) deriving C }}} The above code works just fine in 7.6.3. But, if `Coercible` isn't allowed over recursive newtypes, then this wouldn't work if GND is implemented in terms of `coerce`. So, my question is: why have this restriction? And, if there is a good reason for it, it should probably be documented somewhere. I couldn't find mention of it in the user's guide or in the haddock docs. If we do keep this restriction, what to do about GND? Seems like this may kill the idea of implementing GND in terms of `coerce`, but that makes me sad. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 14 03:09:32 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Nov 2013 03:09:32 -0000 Subject: [GHC] #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough In-Reply-To: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> References: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> Message-ID: <062.fb4c227e90ac78fcd71f3a2cd5627b21@haskell.org> #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): Simon PJ's response: Ah, life is never as simple as you hope. The whole treatment of recursive types is a bit flaky in GHC. For newtypes here is the motivation {{{ newtype R = MkR R }}} Now if we have an instance {{{ instance Coercible a R => Coercible a R }}} we aren't going to make much progress. Mutual recursion is similar. This is very much a corner case. I think that if the recursion is under a type constructor eg {{{ newtype R1 = MkR [R1] }}} then we are fine. But the current test is conservative. I worry about {{{ newtype R2 a = MkR (F a) }}} because perhaps {{{ type instance F Int = R2 Int }}} and now `R2 Int` is just like `R`. But GHC won't spot this today. In any case, I suppose that, provided it was documented, GND could simply ignore the recursion problem, behave as advertised, and if that gives a loop it's the programmer's fault. Things in hs-boot files are treated (again conservatively) as if they might be recursive. A related thing is unpacking data types. Consider {{{ data T = MkT {-# UNPACK #-} !S data S = MkS {-# UNPAXCK #-} !Int {-# UNPAXCK #-} !Int }}} A `S`-value is represented as a pair of `Int#` values. And similarly `T`. But what about {{{ data S2 = MkS2 {-# UNPACK #-} !Int {-# UNPACK #-} !S2 }}} We don?t want to unpack infinitely. Strictness analysis also risks infinitely unpacking a strict argument. I think the rules for newtypes could be different (and perhaps more generous) than for data types. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 14 03:37:35 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Nov 2013 03:37:35 -0000 Subject: [GHC] #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough In-Reply-To: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> References: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> Message-ID: <062.98fd4576263f37f93a4d8800e0f5ae8a@haskell.org> #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): Yuck. I'm leery of creating a way for the type-checker to loop without turning on `UndecidableInstances`. And, with the `R2` example that Simon gives, the newtype and the relevant type family instance might be in different modules, so detecting even so simple an infinite regress may be problematic. (And, note that the pieces on their own are innocent- looking.) I've also just looked at `Note [Recursive newtypes]` in !TcDeriv. This note explains why GND ''works'' for recursive newtypes. I repeat it here: {{{ Note [Recursive newtypes] ~~~~~~~~~~~~~~~~~~~~~~~~~ Newtype deriving works fine, even if the newtype is recursive. e.g. newtype S1 = S1 [T1 ()] newtype T1 a = T1 (StateT S1 IO a ) deriving( Monad ) Remember, too, that type families are curretly (conservatively) given a recursive flag, so this also allows newtype deriving to work for type famillies. We used to exclude recursive types, because we had a rather simple minded way of generating the instance decl: newtype A = MkA [A] instance Eq [A] => Eq A -- Makes typechecker loop! But now we require a simple context, so it's ok. }}} I'm confused by the last line. In the code above the note, a context is generated that includes, for this example, `Eq [A]`! Where does the loop get broken? Regardless, here's a possible solution: if `Coercible` over recursive newtypes is sound but otherwise in danger of causing a loop, we could just require `UndecidableInstances` to get the `Coercible` mechanism to go down this road. In this scenario, my example (with `RecNT`) would fail to use GND without `UndecidableInstances` but should succeed with it. We can even give a helpful error message in this scenario. Or, perhaps even better: could the `Coercible` mechanism use `TyCon.checkRecTc`? That function seems to be designed for exactly this scenario, which is where we need to do newtype expansion but don't want to fall into a black hole. That might complicate the `Coercible` code, but I think it would be a step in the right direction. We could still allow users to specify `UndecidableInstances` to bypass even this check... but my guess is that `checkRecTc` would work exactly in the correct cases, meaning that bypassing the check is sure to cause the type-checker to loop. Other, more informed opinions are very welcome here. Lastly, is there a solid reason to require that the recursiveness of a type in a hs-boot file and the recursiveness of the real type are the same? It looks to me that it would be sound to assume types in hs-boot files are recursive, but then not to inherit this trait when processing the real thing. That would fix the problem with compiling Module.lhs, and it would save some embarrassment if we were to suggest `UndecidableInstances` to compile a very ordinary-looking newtype! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 14 04:56:37 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Nov 2013 04:56:37 -0000 Subject: [GHC] #8530: ghc: Unknown PEi386 section name `.drectve' Message-ID: <044.7a34b006f5eeb3636432dbd6b0b0f616@haskell.org> #8530: ghc: Unknown PEi386 section name `.drectve' ----------------------------+------------------------------------- Reporter: jamer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: x86 | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+------------------------------------- Hello, Bug: - GHC crashes when running "cabal install scion-browser". Expected result: - scion-browser builds and installs successfully. Steps to reproduce: - Install Haskell Platform 2013.02.0.0 - cabal update - cabal install cabal-install - cabal install scion-browser I have not tried to reproduce this problem outside of 32-bit Windows 7. A log of the output from "cabal install scion-browser" is attached. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 14 05:30:39 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Nov 2013 05:30:39 -0000 Subject: [GHC] #8531: ghc crash from kinds Message-ID: <044.ac4a84b30b488e8c5ce720cd2e159edd@haskell.org> #8531: ghc crash from kinds -----------------------------------+--------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: MacOS X Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- When I run this in ghci: {{{ let x :: MaybeT IO (Ptr Int); x = (lift newCString "hi") >>= nullableToMaybeT }}} I get this output: {{{ Couldn't match kind `* -> *' with `*' Expected type: [Char] -> MaybeT IO (Ptr Int) Actual type: [Char] -> MaybeT IO (Ptr Int) Kind incompatibility when matching types: [Char] :: * -> * [Char] :: * The function `lift'ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-apple-darwin): kindFunResult <
> }}} where nullToMaybeT is: {{{ nullableToMaybeT :: Monad m => Ptr a -> MaybeT m (Ptr a) nullableToMaybeT ptr = do case (ptr == nullPtr) of True -> (MaybeT . return) Nothing False -> return ptr }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 14 05:39:29 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Nov 2013 05:39:29 -0000 Subject: [GHC] #8530: ghc: Unknown PEi386 section name `.drectve' In-Reply-To: <044.7a34b006f5eeb3636432dbd6b0b0f616@haskell.org> References: <044.7a34b006f5eeb3636432dbd6b0b0f616@haskell.org> Message-ID: <059.5cfcc711811d1fada8c78c5ec5c8316b@haskell.org> #8530: ghc: Unknown PEi386 section name `.drectve' -------------------------------------+--------------------------- Reporter: jamer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+--------------------------- Comment (by carter): have you reported the issue with the scion issue tracker yet? https://github.com/JPMoresmau/scion-class-browser/issues -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 14 08:11:41 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Nov 2013 08:11:41 -0000 Subject: [GHC] #8528: Preprocessor issues building GHC HEAD on Mavericks In-Reply-To: <044.9e43150f2d22b2782c0ffcb891a3cae9@haskell.org> References: <044.9e43150f2d22b2782c0ffcb891a3cae9@haskell.org> Message-ID: <059.bf06962b27b8fb338f7c91ffaae0ae63@haskell.org> #8528: Preprocessor issues building GHC HEAD on Mavericks ----------------------------------------+---------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: clang Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8480 ----------------------------------------+---------------------------------- Comment (by hvr): Btw, deciding whether Alex is to blame or rather GHC, and how to actually *fix* the situation really depends on what the formal specification for `{-# LANGUAGE CPP #-}` actually is... but I couldn't find any :-/ The way I understand it, Haskell code on Hackage using CPP seems to have implicitly assumed for several years that http://gcc.gnu.org/onlinedocs/cpp/Traditional-Mode.html is the underlying CPP model. However, Clang's cpp obviously implements different semantics and/or doesn't implement traditional mode at all. So this actually a much larger issue, and it isn't enough to just patch code to compile with both Clang's cpp and GCC's cpp (and hope it doesn't break again, as developers generally don't have both cpp implementation available for testing) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 14 09:20:06 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Nov 2013 09:20:06 -0000 Subject: [GHC] #8530: ghc: Unknown PEi386 section name `.drectve' In-Reply-To: <044.7a34b006f5eeb3636432dbd6b0b0f616@haskell.org> References: <044.7a34b006f5eeb3636432dbd6b0b0f616@haskell.org> Message-ID: <059.e297867fd50c2ec6f4eab8592a481f50@haskell.org> #8530: ghc: Unknown PEi386 section name `.drectve' -------------------------------------+--------------------------- Reporter: jamer | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: 7056 Blocking: | Related Tickets: -------------------------------------+--------------------------- Changes (by ezyang): * status: new => closed * resolution: => duplicate * blockedby: => 7056 Comment: Duplicate of #7056 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 14 09:28:02 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Nov 2013 09:28:02 -0000 Subject: [GHC] #8528: Preprocessor issues building GHC HEAD on Mavericks In-Reply-To: <044.9e43150f2d22b2782c0ffcb891a3cae9@haskell.org> References: <044.9e43150f2d22b2782c0ffcb891a3cae9@haskell.org> Message-ID: <059.7f1e2d6cc0916ea00f26cab9fa842f9f@haskell.org> #8528: Preprocessor issues building GHC HEAD on Mavericks ----------------------------------------+---------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: clang Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8480 ----------------------------------------+---------------------------------- Comment (by simonmar): I'm without a clue about what the problem is and how to fix it, and I don't have a Mac. Pull requests gladly accepted :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 14 10:07:39 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Nov 2013 10:07:39 -0000 Subject: [GHC] #8528: Preprocessor issues building GHC HEAD on Mavericks In-Reply-To: <044.9e43150f2d22b2782c0ffcb891a3cae9@haskell.org> References: <044.9e43150f2d22b2782c0ffcb891a3cae9@haskell.org> Message-ID: <059.6a2cb279ad0dcdc31d63f23728361247@haskell.org> #8528: Preprocessor issues building GHC HEAD on Mavericks ----------------------------------------+---------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: clang Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8480 ----------------------------------------+---------------------------------- Comment (by hvr): Replying to [comment:7 simonmar]: > I'm without a clue about what the problem is and how to fix it, and I don't have a Mac. Pull requests gladly accepted :-) One of the problems is that tradional CPP has different semantics, GNU cpp has the `-Wtraditional` flag that warns about some problematic constructs which differ between traditional/non-traditional CPP mode, e.g. assume the following `foo.hs` file: {{{ #if __GLASGOW_HASKELL__ > 706 -- ... #endif }}} then `cpp -Wtraditional foo.hs` would explain that {{{ # 1 "foo.hs" foo.hs:1:3: warning: traditional C ignores #if with the # indented [-Wtraditional] #if __GLASGOW_HASKELL__ > 706 ^ foo.hs:3:3: warning: traditional C ignores #endif with the # indented [-Wtraditional] #endif ^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 14 10:09:58 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Nov 2013 10:09:58 -0000 Subject: [GHC] #8531: ghc crash from kinds In-Reply-To: <044.ac4a84b30b488e8c5ce720cd2e159edd@haskell.org> References: <044.ac4a84b30b488e8c5ce720cd2e159edd@haskell.org> Message-ID: <059.9626699008e2e6bc0d5b4df61b8913a1@haskell.org> #8531: ghc crash from kinds ---------------------------------------+----------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Changes (by guest): * priority: lowest => normal -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 14 12:00:12 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Nov 2013 12:00:12 -0000 Subject: [GHC] #8532: Hyperbolic arc cosine fails on (-1) :: Complex r. Message-ID: <054.2188bb19676a701eab2890d90541afc2@haskell.org> #8532: Hyperbolic arc cosine fails on (-1) :: Complex r. -------------------------------------+------------------------------------- Reporter: leftaroundabout | Owner: Type: bug | Status: new Priority: low | Milestone: Component: libraries/base | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Incorrect result Difficulty: Easy (less than 1 | at runtime hour) | Test Case: acosh(-1) :: Blocked By: | Complex Double Related Tickets: | Blocking: -------------------------------------+------------------------------------- When allowing for complex results, the hyperbolic arc cosine is continuously defined on all ?. In the {{{(x < (-1))}}} real ray of the complex plane, {{{acosh}}} equals {{{\z -> i * pi + acosh(abs z)}}}, which works fine for almost all arguments. Thus, {{{acosh (-1)}}} should equal {{{i * pi}}}; however due to the implementation as {{{ acosh z = log (z + (z+1) * sqrt ((z-1)/(z+1))) }}} where the denominator in the root becomes zero at {{{z = -1}}}, this comes out as {{{NaN :+ NaN}}}. Could be fixed trivially by adding a special case {{{ acosh ((-1):+0) = 0:+pi }}} to the {{{instance (RealFloat a) => Floating (Complex a)}}} in {{{Data.Complex}}}. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 14 12:07:38 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Nov 2013 12:07:38 -0000 Subject: [GHC] #8298: +RTS -hb crash when blocking on empty TChan In-Reply-To: <046.232eb20acd88087609f3969b7dc1b1a0@haskell.org> References: <046.232eb20acd88087609f3969b7dc1b1a0@haskell.org> Message-ID: <061.fc747b183035f676438e33f9e82d90d9@haskell.org> #8298: +RTS -hb crash when blocking on empty TChan --------------------------+------------------------------------------------ Reporter: | Owner: exFalso | Status: new Type: bug | Milestone: Priority: | Version: 7.6.3 normal | Keywords: biographical stm tchan block Component: | Architecture: x86_64 (amd64) Runtime System | Difficulty: Unknown Resolution: | Blocked By: 8275 Operating System: Linux | Related Tickets: Type of failure: | Runtime crash | Test Case: | Blocking: | --------------------------+------------------------------------------------ Comment (by Simon Marlow ): In [changeset:"ad0b943293cce74baf06ea36e1a4d51a3631dfdf/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="ad0b943293cce74baf06ea36e1a4d51a3631dfdf" Fix some cases where we were leaving slop in the heap (#8515, #8298) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 14 12:07:39 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Nov 2013 12:07:39 -0000 Subject: [GHC] #8515: Biographical profiling (-hb) crashes, other profiling modes have truncated output In-Reply-To: <048.c7e4a832e375c0962ebd5fbc8e1e03c8@haskell.org> References: <048.c7e4a832e375c0962ebd5fbc8e1e03c8@haskell.org> Message-ID: <063.9b2b9297c5dac93a2068de9ae3633411@haskell.org> #8515: Biographical profiling (-hb) crashes, other profiling modes have truncated output -----------------------------------+---------------------------- Reporter: blitzcode | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86 Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+---------------------------- Comment (by Simon Marlow ): In [changeset:"ad0b943293cce74baf06ea36e1a4d51a3631dfdf/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="ad0b943293cce74baf06ea36e1a4d51a3631dfdf" Fix some cases where we were leaving slop in the heap (#8515, #8298) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 14 12:15:17 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Nov 2013 12:15:17 -0000 Subject: [GHC] #8528: Preprocessor issues building GHC HEAD on Mavericks In-Reply-To: <044.9e43150f2d22b2782c0ffcb891a3cae9@haskell.org> References: <044.9e43150f2d22b2782c0ffcb891a3cae9@haskell.org> Message-ID: <059.f9b65c4b4409044eea2ed511ca94269a@haskell.org> #8528: Preprocessor issues building GHC HEAD on Mavericks ----------------------------------------+---------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: clang Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8480 ----------------------------------------+---------------------------------- Comment (by simonmar): Yes I understand that clang's cpp doesn't support the same syntax as `cpp -traditional`. What I don't understand is what broke in Alex and how to fix it. I didn't write any indented cpp directives, and there were no changes to `GenericTemplate.hs` between 3.1.0 and 3.1.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 14 12:15:50 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Nov 2013 12:15:50 -0000 Subject: [GHC] #8528: Preprocessor issues building GHC HEAD on Mavericks In-Reply-To: <044.9e43150f2d22b2782c0ffcb891a3cae9@haskell.org> References: <044.9e43150f2d22b2782c0ffcb891a3cae9@haskell.org> Message-ID: <059.57d6e7160c48c24d4a3bc8b730d50d15@haskell.org> #8528: Preprocessor issues building GHC HEAD on Mavericks ----------------------------------------+---------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: clang Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8480 ----------------------------------------+---------------------------------- Comment (by nkpart): Turns out that rolling back alex was a red herring. I needed to make sure that alex was being built with GCC, not with clang. Alex can be built with clang (pretending to be gcc), but if you later call it with gcc (actually being gcc) then it fails in the way you see above. So at the moment, do not build alex with clang-as-gcc, then later call it with gcc-as-gcc. The diff in the Lexer.hs file that I posted above are actually the changes that arise when you switch from a GCC-compiled Alex (what I labeled 3.1.0) to a Clang-compiled Alex (3.1.2). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 14 12:16:50 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Nov 2013 12:16:50 -0000 Subject: [GHC] #8515: Biographical profiling (-hb) crashes, other profiling modes have truncated output In-Reply-To: <048.c7e4a832e375c0962ebd5fbc8e1e03c8@haskell.org> References: <048.c7e4a832e375c0962ebd5fbc8e1e03c8@haskell.org> Message-ID: <063.efd3e777528ad4759ef836aa50cbe0c6@haskell.org> #8515: Biographical profiling (-hb) crashes, other profiling modes have truncated output -----------------------------------+---------------------------- Reporter: blitzcode | Owner: simonmar Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: Runtime System | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86 Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+---------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: This fixes the crashes I saw with +RTS -hb here.. Please re-open if you still have problems. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 14 12:18:05 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Nov 2013 12:18:05 -0000 Subject: [GHC] #8298: +RTS -hb crash when blocking on empty TChan In-Reply-To: <046.232eb20acd88087609f3969b7dc1b1a0@haskell.org> References: <046.232eb20acd88087609f3969b7dc1b1a0@haskell.org> Message-ID: <061.06bd6c35c71a1a6a3a9a70d834a238e4@haskell.org> #8298: +RTS -hb crash when blocking on empty TChan --------------------------+------------------------------------------------ Reporter: | Owner: exFalso | Status: closed Type: bug | Milestone: Priority: | Version: 7.6.3 normal | Keywords: biographical stm tchan block Component: | Architecture: x86_64 (amd64) Runtime System | Difficulty: Unknown Resolution: fixed | Blocked By: Operating System: Linux | Related Tickets: Type of failure: | Runtime crash | Test Case: | Blocking: | --------------------------+------------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => fixed * blockedby: 8275 => Comment: Optimistically assuming fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 14 12:20:16 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Nov 2013 12:20:16 -0000 Subject: [GHC] #3693: Show stack traces In-Reply-To: <043.7c288f8e774d3806292d73b1513892ec@haskell.org> References: <043.7c288f8e774d3806292d73b1513892ec@haskell.org> Message-ID: <058.5606732aaa0efb78a72d783e604e9af0@haskell.org> #3693: Show stack traces -------------------------------------+------------------------------------ Reporter: jpet | Owner: Tarrasch Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 6.10.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by Tarrasch): * cc: miffoljud@?, simonmar (added) * owner: => Tarrasch * milestone: 7.6.2 => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 14 12:20:21 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Nov 2013 12:20:21 -0000 Subject: [GHC] #8528: Preprocessor issues building GHC HEAD on Mavericks In-Reply-To: <044.9e43150f2d22b2782c0ffcb891a3cae9@haskell.org> References: <044.9e43150f2d22b2782c0ffcb891a3cae9@haskell.org> Message-ID: <059.a982f07bdf70dac74cc78f36e898a288@haskell.org> #8528: Preprocessor issues building GHC HEAD on Mavericks ----------------------------------------+---------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: clang Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8480 ----------------------------------------+---------------------------------- Comment (by simonmar): Right, that makes sense. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 14 13:26:28 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Nov 2013 13:26:28 -0000 Subject: [GHC] #8520: ghc.exe: internal error: loadArchive: error whilst reading `C' In-Reply-To: <044.7423adcbc9658116359111a685ed6de6@haskell.org> References: <044.7423adcbc9658116359111a685ed6de6@haskell.org> Message-ID: <059.448c966b54a4418868c333bdf393c664@haskell.org> #8520: ghc.exe: internal error: loadArchive: error whilst reading `C' ----------------------------------+--------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+--------------------------- Comment (by akio): I tried to reproduce it because I thought this might be my fault. However the compilation was successful for me. (GHC 7.7.201311108, i386_unknown_mingw32) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 14 13:34:18 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Nov 2013 13:34:18 -0000 Subject: [GHC] #8531: ghc crash from kinds In-Reply-To: <044.ac4a84b30b488e8c5ce720cd2e159edd@haskell.org> References: <044.ac4a84b30b488e8c5ce720cd2e159edd@haskell.org> Message-ID: <059.12f5c83fe6503b40f105059286854dc2@haskell.org> #8531: ghc crash from kinds ---------------------------------------+----------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: duplicate | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Changes (by goldfire): * status: new => closed * resolution: => duplicate Comment: This is fixed in HEAD and will be fixed in 7.8. Thanks for reporting! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 14 16:12:39 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Nov 2013 16:12:39 -0000 Subject: [GHC] #8520: ghc.exe: internal error: loadArchive: error whilst reading `C' In-Reply-To: <044.7423adcbc9658116359111a685ed6de6@haskell.org> References: <044.7423adcbc9658116359111a685ed6de6@haskell.org> Message-ID: <059.d14eb8e750acd2560518c47e7c7891fc@haskell.org> #8520: ghc.exe: internal error: loadArchive: error whilst reading `C' ----------------------------------+--------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+--------------------------- Comment (by awson): The culprit is, I think, you didn't use --split-objs (--enable-split-objs for cabal-install) when building packages Agda depends on. I always test things to work with --split-objs. When I had rebuilt a couple of packages with no --split-objs flag this bug "moved further down": {{{ [ 86 of 258] Compiling Agda.TypeChecking.Monad.Base[boot] ( src\full\Agda\TypeChecking\Monad\Base.hs-boot, dist\build\Agda\TypeChecking\Monad\Base.o-boot ) [ 87 of 258] Compiling Agda.Interaction.Response[boot] ( src\full\Agda\Interaction\Response.hs-boot, dist\build\Agda\Interaction\Response.o-boot ) [ 88 of 258] Compiling Agda.Interaction.FindFile[boot] ( src\full\Agda\Interaction\FindFile.hs-boot, dist\build\Agda\Interaction\FindFile.o-boot ) [ 89 of 258] Compiling Agda.Syntax.Abstract ( src\full\Agda\Syntax\Abstract.hs, dist\build\Agda\Syntax\Abstract.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... 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 zlib-0.5.4.1 ... linking ... done. Loading package xhtml-3000.2.1 ... linking ... done. Loading package text-0.11.3.1 ... linking ... done. Loading package hashable-1.2.1.0 ... linking ... done. Loading package unordered-containers-0.2.3.3 ... linking ... done. Loading package Win32-2.3.0.0 ... 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.1 ... linking ... done. Loading package directory-1.2.0.2 ... linking ... done. Loading package process-1.2.0.0 ... linking ... done. Loading package containers-0.5.3.1 ... linking ... done. Loading package parallel-3.2.0.4 ... linking ... done. Loading package old-time-1.1.0.2 ... linking ... done. Loading package cpphs-1.17.1 ... linking ... done. Loading package pretty-1.1.1.1 ... linking ... done. Loading package haskell-src-exts-1.14.0 ... linking ... done. Loading package transformers-0.3.0.0 ... linking ... done. Loading package haskeline-0.7.0.3 ... linking ... done. Loading package primitive-0.5.1.0 ... linking ... done. Loading package vector-0.10.9.1 ... linking ... done. Loading package hashtables-1.1.2.1 ... linking ... done. Loading package mtl-2.1.2 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package geniplate-0.6.0.3 ... linking ... done. Loading package binary-0.7.1.0 ... linking ... done. Loading package random-1.0.1.1 ... linking ... done. Loading package QuickCheck-2.6 ... ghc.exe: internal error: loadArchive: error whilst reading `C' (GHC version 7.7.20131108 for i386_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} And I'm almost sure if all dependencies are built without --split-objs the bug won't manifest itself. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 14 16:26:50 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Nov 2013 16:26:50 -0000 Subject: [GHC] #8520: ghc.exe: internal error: loadArchive: error whilst reading `C' In-Reply-To: <044.7423adcbc9658116359111a685ed6de6@haskell.org> References: <044.7423adcbc9658116359111a685ed6de6@haskell.org> Message-ID: <059.ed2d99dab3a414a77814e942ff6d467e@haskell.org> #8520: ghc.exe: internal error: loadArchive: error whilst reading `C' ----------------------------------+--------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+--------------------------- Comment (by awson): Also mention should be made this bug is somewhat nondeterministic - when building sequentially (no -j3 GHC flag) the first build crash at haskeline, and subsequent builds fail at vector. It probably can depend on particular machine also. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 14 21:07:01 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Nov 2013 21:07:01 -0000 Subject: [GHC] #8533: Extend new getPhysicalMemorySize ifdef to ios_HOST_OS Message-ID: <045.661111d53a8a05cd8e37eab898a245cc@haskell.org> #8533: Extend new getPhysicalMemorySize ifdef to ios_HOST_OS -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Other Architecture: arm | Type of failure: Building GHC Difficulty: Easy (less than 1 | failed hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- A very tiny patch to extend thoughtpoice's recent commit "Fix getPhysicalMemorySize on OS X (#8481)" to extend the ifdef to ios_HOST_OS, which also requires the fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 14 23:20:06 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Nov 2013 23:20:06 -0000 Subject: [GHC] #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough In-Reply-To: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> References: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> Message-ID: <062.423c0020f578e27a33c68a9925c34a82@haskell.org> #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): I was conservative when disallowing recursive newtypes for `Coercible`, but quite possibly too conservative. I also wanted to keep the code simple (Note that it just keeps generating constraints and passing them back to the constraint solver; it does *not* build the whole coercion in one go). I wasn?t aware of `TyCon.checkRecTc` and I?ll look into it. Thanks for pointing that out. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 14 23:25:09 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Nov 2013 23:25:09 -0000 Subject: [GHC] #7229: Detecting if a process was killed by a signal is impossible In-Reply-To: <049.04c6e7b70db678da0226fa39d069be65@haskell.org> References: <049.04c6e7b70db678da0226fa39d069be65@haskell.org> Message-ID: <064.4136f2f278d528196a191b5a85de2359@haskell.org> #7229: Detecting if a process was killed by a signal is impossible --------------------------------------+------------------------------------ Reporter: benmachine | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: libraries/process | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Changes (by duncan): * status: new => closed * resolution: => fixed Comment: So I've pushed patches to process, base and the rts to implement this, using the -signum encoding. * process [changeset:"3ebbe13a82b4f4beb382bb8a07f98e57a8354a85/process"] * base [changeset:"6b22a6ef9e59c6562ef6adfad7cd94e27aedec2c/base"] * ghc [changeset:"a987b8004e83c694e00cdd47cbf43a9588eb47d4/ghc"] There's also haddock docs, and tests (in separate commits). I think we can declare this done. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 14 23:41:21 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Nov 2013 23:41:21 -0000 Subject: [GHC] #2301: Proper handling of SIGINT/SIGQUIT In-Reply-To: <045.f06a53427920f75d02000e2372e27573@haskell.org> References: <045.f06a53427920f75d02000e2372e27573@haskell.org> Message-ID: <060.72138041359a510b01e0cd7156944dae@haskell.org> #2301: Proper handling of SIGINT/SIGQUIT -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: | Version: 6.12.3 libraries/process | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: POSIX | Difficulty: Unknown Type of failure: Incorrect result | Blocked By: at runtime | Related Tickets: Test Case: | #3994,#5766,#7229,#4274,#3318,#1619 Blocking: | -------------------------------------+------------------------------------- Comment (by duncan): I have a patch to fix this. It adds a new `delegate_ctlc :: Bool` to the `CreateProcess` options record for delegating control C handling. If you turn that on, then `createProcess` will make the parent process ignore SIGINT until `waitForProcess` returns (or `getProcessExitCode` returns non-Nothing). Then `waitForProcess` (or `getProcessExitCode`) will throw `UserInterrupt` if we were delegating, and the process did exit due to SIGINT. This should implement the "WCE" protocol ok. It should correctly handle the case of there being multiple concurrent processes to which we're delegating (unlike the current `system`/`rawSystem` which will end up with the wrong signal handlers installed). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 15 00:39:33 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Nov 2013 00:39:33 -0000 Subject: [GHC] #4175: GHCi support for type/data families should match that of related features In-Reply-To: <044.9e9574a9cfdee96c30054a406b748567@haskell.org> References: <044.9e9574a9cfdee96c30054a406b748567@haskell.org> Message-ID: <059.757c6e0e9718e8a0eecbc5634b7a1720@haskell.org> #4175: GHCi support for type/data families should match that of related features ---------------------------------------+----------------------------------- Reporter: claus | Owner: Type: bug | Status: closed Priority: low | Milestone: 7.6.2 Component: GHCi | Version: 6.12.3 Resolution: fixed | Keywords: FD TF Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: ghci/scripts/T4175 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Comment (by Patrick Palka ): In [changeset:"eb8fb434ff5e962a54247cacc5d3340972d5daf4/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="eb8fb434ff5e962a54247cacc5d3340972d5daf4" Simplify and improve coverage of ":info" instance lookup During instance lookup, we can treat classes and data families like any other TyCon instead of special-casing them. This approach, aside from being simpler, has the benefit of returning extra relevant instances for classes and data families. For example, given class A a instance B (a :: Constraint) instance A B ":info B" will now also print "instance A B" where previously it didn't due to the special casing of class TyCons in lookupInsts. This improves upon the existing patch for Trac #4175 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 15 00:40:45 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Nov 2013 00:40:45 -0000 Subject: [GHC] #4175: GHCi support for type/data families should match that of related features In-Reply-To: <044.9e9574a9cfdee96c30054a406b748567@haskell.org> References: <044.9e9574a9cfdee96c30054a406b748567@haskell.org> Message-ID: <059.b2fef7994b19660693ab9e2311208e3f@haskell.org> #4175: GHCi support for type/data families should match that of related features ---------------------------------------+----------------------------------- Reporter: claus | Owner: Type: bug | Status: closed Priority: low | Milestone: 7.6.2 Component: GHCi | Version: 6.12.3 Resolution: fixed | Keywords: FD TF Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: ghci/scripts/T4175 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Comment (by Patrick Palka ): In [changeset:"3d6debaa48f48812878e8f66cc64c49b1fb81d35/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="3d6debaa48f48812878e8f66cc64c49b1fb81d35" Increase coverage of #4175 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 15 02:58:21 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Nov 2013 02:58:21 -0000 Subject: [GHC] #8534: DeriveFunctor and PolyKinds Message-ID: <047.c19c17e271106ecdf2c2cb0268320d27@haskell.org> #8534: DeriveFunctor and PolyKinds -------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.6.3 checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: Unknown/Multiple | valid program Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- A tiny infelicity: {{{ {-# LANGUAGE DeriveFunctor #-} data A a = A deriving Functor }}} works only if `PolyKinds` is disabled, otherwise it reports that `A` has kind `k -> *` instead of expected `* -> *`. On the other hand, standalone deriving works fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 15 03:09:55 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Nov 2013 03:09:55 -0000 Subject: [GHC] #8535: :info (->) doesn't print all relevant instances Message-ID: <044.14f3aac2591ade4afa7f287a68e9af5d@haskell.org> #8535: :info (->) doesn't print all relevant instances ------------------------------------+------------------------------------- Reporter: parcs | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I noticed that ":info (->)" does not does not print all relevant instances, specifically instances whose heads use `->` in an infix way. For example, {{{ $ ghci -v0 Prelude> import Data.Monoid Prelude Data.Monoid> :i (->) data (->) a b -- Defined in `GHC.Prim' instance Monad ((->) r) -- Defined in `GHC.Base' instance Functor ((->) r) -- Defined in `GHC.Base' Prelude Data.Monoid> }}} The instance `Monoid b => Monoid (a -> b)` is not printed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 15 03:19:54 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Nov 2013 03:19:54 -0000 Subject: [GHC] #8535: :info (->) doesn't print all relevant instances In-Reply-To: <044.14f3aac2591ade4afa7f287a68e9af5d@haskell.org> References: <044.14f3aac2591ade4afa7f287a68e9af5d@haskell.org> Message-ID: <059.c861b6da81601a272eeed0ceec696b8f@haskell.org> #8535: :info (->) doesn't print all relevant instances -------------------------------------+------------------------------------ Reporter: parcs | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by parcs): * status: new => patch Comment: Here's a validated diff that fixes this issue: {{{ #!diff diff --git a/compiler/typecheck/TcType.lhs b/compiler/typecheck/TcType.lhs index 9ccb08a..430dfb0 100644 --- a/compiler/typecheck/TcType.lhs +++ b/compiler/typecheck/TcType.lhs @@ -1316,7 +1316,9 @@ orphNamesOfType (TyVarTy _) = emptyNameSet orphNamesOfType (TyConApp tycon tys) = orphNamesOfTyCon tycon `unionNameSets` orphNamesOfTypes tys orphNamesOfType (LitTy {}) = emptyNameSet -orphNamesOfType (FunTy arg res) = orphNamesOfType arg `unionNameSets` orphNamesOfType res +orphNamesOfType (FunTy arg res) = orphNamesOfTyCon funTyCon `unionNameSets` + orphNamesOfType arg `unionNameSets` + orphNamesOfType res orphNamesOfType (AppTy fun arg) = orphNamesOfType fun `unionNameSets` orphNamesOfType arg orphNamesOfType (ForAllTy _ ty) = orphNamesOfType ty }}} I am not sure how this diff affects the other callers (aside from the ":info" machinery, that is) of `orphNamesOfType`. It passes validation, at least. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 15 03:58:38 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Nov 2013 03:58:38 -0000 Subject: [GHC] #7651: Buiding GHC with parallel IO manager freezes on Mac (not on FreeBSD) In-Reply-To: <052.b5316a423cedc87fa6cecb2672f617b3@haskell.org> References: <052.b5316a423cedc87fa6cecb2672f617b3@haskell.org> Message-ID: <067.f9ef8b73f8250b8b56b901ec6fdd4850@haskell.org> #7651: Buiding GHC with parallel IO manager freezes on Mac (not on FreeBSD) ----------------------------------------+---------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by kazu-yamamoto): I can build GHC head in parallel even on Mavericks. See #8497 and #8102. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 15 04:46:37 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Nov 2013 04:46:37 -0000 Subject: [GHC] #8532: Hyperbolic arc cosine fails on (-1) :: Complex r. In-Reply-To: <054.2188bb19676a701eab2890d90541afc2@haskell.org> References: <054.2188bb19676a701eab2890d90541afc2@haskell.org> Message-ID: <069.d5779ae3ae246c95273eb09ac7e31a8d@haskell.org> #8532: Hyperbolic arc cosine fails on (-1) :: Complex r. -------------------------------------+------------------------------------- Reporter: leftaroundabout | Owner: Type: bug | Status: new Priority: low | Milestone: Component: libraries/base | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Incorrect result | Difficulty: Easy (less than 1 at runtime | hour) Test Case: acosh(-1) :: | Blocked By: Complex Double | Related Tickets: Blocking: | -------------------------------------+------------------------------------- Comment (by carter): does this behave as expected in the a small radius around -1? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 15 11:25:57 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Nov 2013 11:25:57 -0000 Subject: [GHC] #4268: Warning for ANN pragmas when GHCi is not supported In-Reply-To: <047.ede29838e1cb563fb2d34f66fbf6c1b7@haskell.org> References: <047.ede29838e1cb563fb2d34f66fbf6c1b7@haskell.org> Message-ID: <062.c97c25508087d692e6f82fa19a538746@haskell.org> #4268: Warning for ANN pragmas when GHCi is not supported -------------------------------+------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.0.4 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: Other | Blocked By: Test Case: | Related Tickets: #8312, #5105 Blocking: | -------------------------------+------------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"434d78360154684a0d5086643a572c955de90c7d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="434d78360154684a0d5086643a572c955de90c7d" Improve error message Accommodating Simon M's suggestion (Trac #4268, comment 17) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 15 11:49:54 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Nov 2013 11:49:54 -0000 Subject: [GHC] #2301: Proper handling of SIGINT/SIGQUIT In-Reply-To: <045.f06a53427920f75d02000e2372e27573@haskell.org> References: <045.f06a53427920f75d02000e2372e27573@haskell.org> Message-ID: <060.930a309f0396cdc6461a37bbc64ae4c5@haskell.org> #2301: Proper handling of SIGINT/SIGQUIT -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: | Version: 6.12.3 libraries/process | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: POSIX | Difficulty: Unknown Type of failure: Incorrect result | Blocked By: at runtime | Related Tickets: Test Case: | #3994,#5766,#7229,#4274,#3318,#1619 Blocking: | -------------------------------------+------------------------------------- Comment (by simonmar): If `waitForProcess` is called by a forkIO'd thread, then `UserInterrupt` doesn't cause the process to die with `SIGINT`. Normally a `SIGINT` causes the main thread to receive `UserInterrupt`, and the top handler for the main thread turns this into a `SIGINT` again. What should happen? Maybe this: if a `UserInterrupt` in a child thread were to throw a `SIGINT` at the current process, then it would be caught by the handler, causing a `UserInterrupt` to be thrown to the main thread, which would eventually throw a `SIGINT` again to kill the process. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 15 12:29:14 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Nov 2013 12:29:14 -0000 Subject: [GHC] #6068: Panic in GHCi when using functional dependencies and promoted kinds In-Reply-To: <047.53daac14d65caa6ad1d72ce6ffc9d9ff@haskell.org> References: <047.53daac14d65caa6ad1d72ce6ffc9d9ff@haskell.org> Message-ID: <062.d0893b655b47082532b316975573d0af@haskell.org> #6068: Panic in GHCi when using functional dependencies and promoted kinds -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.5 Resolution: | Keywords: PolyKinds Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Unknown Test Case: polykinds/T6068 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"dff0e99d37f3529041bb2bb66ffda1ea22af14e0/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="dff0e99d37f3529041bb2bb66ffda1ea22af14e0" Fix a subtle bug in kind-mis-matched equalities (Trac #6068) When we have an equality constraint where the LHS and RHS have ill-matched kinds, it get turned into a CIrredEvCan because a CTyEqCan/CFunEqCan are guaranteed kind-compatible. But that in turn led to a bug because in the constraint c = (a:k1) ~ (b:k2) the kind variables k1 and k2 don't show up in tyVarsOfType c. Why not? Because it looks like (~) k1 (a:k1) (b:k2) Maybe (~) should have two kind arguments? That seemed like too big a change for not (we wait for NoKinds), so this patch fixes the bug for now. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 15 12:33:54 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Nov 2013 12:33:54 -0000 Subject: [GHC] #6068: Panic in GHCi when using functional dependencies and promoted kinds In-Reply-To: <047.53daac14d65caa6ad1d72ce6ffc9d9ff@haskell.org> References: <047.53daac14d65caa6ad1d72ce6ffc9d9ff@haskell.org> Message-ID: <062.35f246a89515dc0eacb8e52580f97466@haskell.org> #6068: Panic in GHCi when using functional dependencies and promoted kinds -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.5 Resolution: | Keywords: PolyKinds Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Unknown Test Case: polykinds/T6068 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonpj): * cc: goldfire (added) Comment: Tanks for pointing out this crash. As the comments show (`Note [Kicking out Irreds]` in `TcInteract`), it raises an interesting point. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 15 12:41:19 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Nov 2013 12:41:19 -0000 Subject: [GHC] #8535: :info (->) doesn't print all relevant instances In-Reply-To: <044.14f3aac2591ade4afa7f287a68e9af5d@haskell.org> References: <044.14f3aac2591ade4afa7f287a68e9af5d@haskell.org> Message-ID: <059.3c51a865da810262c6221411a9a45d25@haskell.org> #8535: :info (->) doesn't print all relevant instances -------------------------------------+------------------------------------ Reporter: parcs | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): Great point. I'll commit this. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 15 12:49:02 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Nov 2013 12:49:02 -0000 Subject: [GHC] #8532: Hyperbolic arc cosine fails on (-1) :: Complex r. In-Reply-To: <054.2188bb19676a701eab2890d90541afc2@haskell.org> References: <054.2188bb19676a701eab2890d90541afc2@haskell.org> Message-ID: <069.6397ff88931f16989008661e7b3e71f3@haskell.org> #8532: Hyperbolic arc cosine fails on (-1) :: Complex r. -------------------------------------+------------------------------------- Reporter: leftaroundabout | Owner: Type: bug | Status: new Priority: low | Milestone: Component: libraries/base | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Incorrect result | Difficulty: Easy (less than 1 at runtime | hour) Test Case: acosh(-1) :: | Blocked By: Complex Double | Related Tickets: Blocking: | -------------------------------------+------------------------------------- Comment (by leftaroundabout): Replying to [comment:1 carter]: > does this behave as expected in the a small radius around -1? (worth at least plotting it out) For real arguments, it sure enough works. {{{ GHCi, version 7.4.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> :m +Data.Complex Prelude Data.Complex> :m +Graphics.Rendering.Chart.Simple Prelude Data.Complex Graphics.Rendering.Chart.Simple> :set prompt "> " > let re f = realPart . f . realToFrac > let im f = imagPart . f . realToFrac > plotPNG "acosh-on-reals.png" [-2, -1.99 .. 2] (re acosh) (im acosh) }}} If you put in complex numbers, there's a problem anyway: the imaginary part jumps from {{{+?}}} to {{{-?}}} as {{{Im z}}} becomes negative. Still, ([http://www.wolframalpha.com/input/?i=acosh]) it's apparently convention that for {{{Im z = 0}}}, we always have {{{Im (acosh(z)) ? 0)}}}, including {{{z = -1}}}. At any rate, the real part is 0 there; but in the current implementation that is also {{{NaN}}}. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 15 14:18:54 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Nov 2013 14:18:54 -0000 Subject: [GHC] #2301: Proper handling of SIGINT/SIGQUIT In-Reply-To: <045.f06a53427920f75d02000e2372e27573@haskell.org> References: <045.f06a53427920f75d02000e2372e27573@haskell.org> Message-ID: <060.49c0eada588722e66a8f51953acb9496@haskell.org> #2301: Proper handling of SIGINT/SIGQUIT -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: | Version: 6.12.3 libraries/process | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: POSIX | Difficulty: Unknown Type of failure: Incorrect result | Blocked By: at runtime | Related Tickets: Test Case: | #3994,#5766,#7229,#4274,#3318,#1619 Blocking: | -------------------------------------+------------------------------------- Comment (by duncan): Yes, I did think about whether it should throw the `UserInterrupt` sync locally or async to the main thread. As you say, the concern is that people do not properly propagate their exceptions from forkIO threads (which I still maintain is a deficiency in our thread system). On the other hand it gives people an opportunity to catch the user interrupt locally if that's what they want to do. If it were not for the annoying problem of forkIO swallowing our exceptions, then I'd say that throwing it locally is really the right thing to do, because by delegating ^C handling to the child process, we really are turning an async exception (being interrupted by a signal) into a sync exception (waiting on process exit, which exits due to a signal). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 15 18:49:32 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Nov 2013 18:49:32 -0000 Subject: [GHC] #6068: Panic in GHCi when using functional dependencies and promoted kinds In-Reply-To: <047.53daac14d65caa6ad1d72ce6ffc9d9ff@haskell.org> References: <047.53daac14d65caa6ad1d72ce6ffc9d9ff@haskell.org> Message-ID: <062.91b3b8260e1b02b1f0649b975482551a@haskell.org> #6068: Panic in GHCi when using functional dependencies and promoted kinds -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.5 Resolution: | Keywords: PolyKinds Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Unknown Test Case: polykinds/T6068 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"1e0ef8265d67d05e5114310311804b6d51bec7dd/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="1e0ef8265d67d05e5114310311804b6d51bec7dd" Fix canIrredPred again This follows up the earlier patch to Trac #6068, which I obviously hadn't validated properly. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 15 18:49:32 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Nov 2013 18:49:32 -0000 Subject: [GHC] #8535: :info (->) doesn't print all relevant instances In-Reply-To: <044.14f3aac2591ade4afa7f287a68e9af5d@haskell.org> References: <044.14f3aac2591ade4afa7f287a68e9af5d@haskell.org> Message-ID: <059.4d7bf5501229e8c4ce9fd9d24b567633@haskell.org> #8535: :info (->) doesn't print all relevant instances -------------------------------------+------------------------------------ Reporter: parcs | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"26c9d5912c47a34fef197a6c917f673aeb2dc119/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="26c9d5912c47a34fef197a6c917f673aeb2dc119" Include funTyCon in oprhNamesOfType (fixes Trac #8535) Thanks to parcs for identifying both the bug and the right solution. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 15 21:02:15 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Nov 2013 21:02:15 -0000 Subject: [GHC] #2301: Proper handling of SIGINT/SIGQUIT In-Reply-To: <045.f06a53427920f75d02000e2372e27573@haskell.org> References: <045.f06a53427920f75d02000e2372e27573@haskell.org> Message-ID: <060.bc8b49709efd91fe84c33d9f31ae783e@haskell.org> #2301: Proper handling of SIGINT/SIGQUIT -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: | Version: 6.12.3 libraries/process | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: POSIX | Difficulty: Unknown Type of failure: Incorrect result | Blocked By: at runtime | Related Tickets: Test Case: | #3994,#5766,#7229,#4274,#3318,#1619 Blocking: | -------------------------------------+------------------------------------- Changes (by duncan): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 15 21:05:53 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Nov 2013 21:05:53 -0000 Subject: [GHC] #2233: Overhaul System.Process In-Reply-To: <047.24a366415ff9b59c03e5bf49850898a6@haskell.org> References: <047.24a366415ff9b59c03e5bf49850898a6@haskell.org> Message-ID: <062.6834d136c20aa5d21f993d7b647b4ea5@haskell.org> #2233: Overhaul System.Process --------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: task | Status: patch Priority: normal | Milestone: _|_ Component: libraries/process | Version: 6.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Changes (by duncan): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 15 21:17:40 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Nov 2013 21:17:40 -0000 Subject: [GHC] #2301: Proper handling of SIGINT/SIGQUIT In-Reply-To: <045.f06a53427920f75d02000e2372e27573@haskell.org> References: <045.f06a53427920f75d02000e2372e27573@haskell.org> Message-ID: <060.1e240cfe420f2355eaf0797a03119ff0@haskell.org> #2301: Proper handling of SIGINT/SIGQUIT -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: | Version: 6.12.3 libraries/process | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: POSIX | Difficulty: Unknown Type of failure: Incorrect result | Blocked By: at runtime | Related Tickets: Test Case: | #3994,#5766,#7229,#4274,#3318,#1619 Blocking: | -------------------------------------+------------------------------------- Comment (by duncan): Simon: BTW, I didn't mean I'm dead set against changing it, I think it's rather unclear which is better. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 15 21:17:47 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Nov 2013 21:17:47 -0000 Subject: [GHC] #2233: Overhaul System.Process In-Reply-To: <047.24a366415ff9b59c03e5bf49850898a6@haskell.org> References: <047.24a366415ff9b59c03e5bf49850898a6@haskell.org> Message-ID: <062.76b3637926e7423faca5e4b269208b39@haskell.org> #2233: Overhaul System.Process --------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: task | Status: patch Priority: normal | Milestone: _|_ Component: libraries/process | Version: 6.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by duncan): Note, these patches depend on the ones from #2301 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 15 21:28:41 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Nov 2013 21:28:41 -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.82c017850e8955fc6e355ca4ba14b7bb@haskell.org> #4426: Simplify the rules for implicit quantification -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: feature request | Status: patch Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 6.12.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #7880 -------------------------------------+------------------------------------ Changes (by monoidal): * status: new => patch Comment: Patch attached. It adds a new warning `-fwarn-context-quantification` that reports when a variable is quantified only because it under a "=>" arrow. Later, as the proposal says, this warning will be made an out-of-scope error. Normally, `HsForAll` is either `HsForAll Implicit` or `HsForAll Explicit`, and a context `T => R` inserts `HsForAll Implicit`. This patch adds a new value, `HsForAll Qualified`, which is completely equivalent to `HsForAll Implicit` save for the warning message. Later, its behavior will be changed and the renamer will not do implicit quantification for variables under `HsForAll Quantified`. I made `-Wall` not imply this flag, in (doubtful) case there is still time to merge this to GHC 7.8. In this case, there is full backwards compatibility: no change in behavior except if the flag is explicitly supplied. However, the API is slightly changed and I had to make a tiny change to Haddock. If it's too late, in GHC 7.10 I'd like `-Wall` to enable `-fwarn-context-quantification`, so I'll amend the patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 15 22:40:31 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Nov 2013 22:40:31 -0000 Subject: [GHC] #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough In-Reply-To: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> References: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> Message-ID: <062.04b3b5b85893de43b97d7fb6b22be633@haskell.org> #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Using just `TyCon.checkRecTc` is too permissive for `Coercible`. `checkRecTc` succeeds for `Fix (Either x)` (where `newtype Fix f = MkFix (f (Fix f))`) for all type `x`. But then we?d generate the instances {{{ instance Coercible (Either x (Fix (Either x))) b => Coercible (Fix (Either x)) b instance Coercible a (Either x (Fix (Either x))) => Coercible a (Fix (Either x)) }}} so trying to solve the constraint `Coercible (Fix (Either Age)) (Fix (Either Int))` will loop. (With the current implementation, which hooks into the general constraint resolving, I?d expect it to not loop at compile time, but create a diverging witness, and crash at run time. Neither of these are desired). Now what about your example, `newtype RecNT = MkRecNT (Either RecNT String)`. Assume that `Coercible` would work for it, and assume there is also `newtype RecNT2 = MkRecNT2 (Either RecNT2 String)`. Then, similarly, solving `Coercible RecNT RecNT2` will loop with the current implementation... So it is not a matter of relaxing the checks; if we want to support recursive newtypes in `Coercible`, the algorithm needs to be generally overhauled. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 16 02:13:18 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Nov 2013 02:13:18 -0000 Subject: [GHC] #8536: ghc panic on creating data type Message-ID: <046.64ad2d2f569a84575884f4032a1bee45@haskell.org> #8536: ghc panic on creating data type ----------------------------------+--------------------------------------- Reporter: xilexio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: data | Operating System: Unknown/Multiple Architecture: x86_64 (amd64) | Type of failure: Compile-time crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------------- ghc 7.6.3 (or ghci) from Haskell Platform for Windows panics when compiling the following line: data X = A Int { p :: Int } | B { p :: Int } ghc.exe: panic! (the 'impossible' happened) (GHC version 7.6.3 for i386-unknown-mingw32): tc_hs_type: record -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 16 12:17:38 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Nov 2013 12:17:38 -0000 Subject: [GHC] #8536: ghc panic on creating data type In-Reply-To: <046.64ad2d2f569a84575884f4032a1bee45@haskell.org> References: <046.64ad2d2f569a84575884f4032a1bee45@haskell.org> Message-ID: <061.67132617f5519b21c1b6d66385dd2d75@haskell.org> #8536: ghc panic on creating data type ---------------------------------------+---------------------------------- Reporter: xilexio | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: duplicate | Keywords: data Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Changes (by monoidal): * status: new => closed * resolution: => duplicate Comment: Thanks for the report. It's already fixed in HEAD: #7943. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 16 13:05:18 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Nov 2013 13:05:18 -0000 Subject: [GHC] #8339: Build fails with panic in vector In-Reply-To: <047.11ad03e22309907b83729c5dd2809e1b@haskell.org> References: <047.11ad03e22309907b83729c5dd2809e1b@haskell.org> Message-ID: <062.2985d4fdb95c503b9072b98408aff9ba@haskell.org> #8339: Build fails with panic in vector ----------------------------------------+---------------------------------- Reporter: trommler | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: libraries (other) | Version: 7.7 Resolution: | Keywords: vector Operating System: Unknown/Multiple | annotation Type of failure: Building GHC failed | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: #8203 #8212 ----------------------------------------+---------------------------------- Changes (by monoidal): * status: new => infoneeded Comment: Is the bug still present? It looks similar to #8344 which was fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 17 18:43:43 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Nov 2013 18:43:43 -0000 Subject: [GHC] #8520: ghc.exe: internal error: loadArchive: error whilst reading `C' In-Reply-To: <044.7423adcbc9658116359111a685ed6de6@haskell.org> References: <044.7423adcbc9658116359111a685ed6de6@haskell.org> Message-ID: <059.994e7be3570f1d2a368a6cfbbdcc3009@haskell.org> #8520: ghc.exe: internal error: loadArchive: error whilst reading `C' ----------------------------------+--------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+--------------------------- Comment (by awson): At last I've found the culprit: it's a lack of memory. When I set LARGEADDRESSAWARE flag for ghc.exe executable, the problem went away. AFAIUI, it is unknown whether enabling this flag is safe for GHC-generated binaries. Apparently, it works, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 17 18:53:42 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Nov 2013 18:53:42 -0000 Subject: [GHC] #8520: ghc.exe: internal error: loadArchive: error whilst reading `C' In-Reply-To: <044.7423adcbc9658116359111a685ed6de6@haskell.org> References: <044.7423adcbc9658116359111a685ed6de6@haskell.org> Message-ID: <059.b69d89dc3d5e64667494861d0cfc9c7d@haskell.org> #8520: ghc.exe: internal error: loadArchive: error whilst reading `C' ----------------------------------+--------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+--------------------------- Comment (by awson): To be more precise: this depends not only on GHC, but also (and, perhaps, primarily so) on foreign C-code involved. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 17 22:53:19 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Nov 2013 22:53:19 -0000 Subject: [GHC] #8537: confusing error message for specialize pragma Message-ID: <045.832f7ac508c2d7554c2e9563deea3e66@haskell.org> #8537: confusing error message for specialize pragma ------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I get the following confusing error/warning about SPECIALIZE {{{ SPECIALISE pragma for non-overloaded function `$cfmap' }}} with the following example module {{{ {-# LANGUAGE PolyKinds #-} {-# LANGUAGE BangPatterns #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE DeriveDataTypeable #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE StandaloneDeriving #-} {-# LANGUAGE CPP #-} {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE NoImplicitPrelude #-} module Numerical.Types.Shape where import Control.Applicative import Data.Foldable import Data.Monoid import Data.Functor import Prelude (seq, ($!),($),Show(..),Eq(),Int) data Nat = S !Nat | Z --deriving (Eq,Show,Read) {- not doing the HLIST style shape because I don't want to have any pattern matchings going on. Also would play hell with locality quality in the address translation hackery, because there'd be an extra load to get those ints! -} infixr 3 :* {- the concern basically boils down to "will it specialize / inline well" -} data Shape (rank :: Nat) a where Nil :: Shape Z a (:*) :: !(a) -> !(Shape r a ) -> Shape (S r) a --deriving instance (Show (Shape rank a)) -- deriving instance Eq (Shape rank a) -- #if defined( __GLASGOW_HASKELL__ ) && ( __GLASGOW_HASKELL__ >= 707) --deriving instance Typeable (Shape rank a) -- #endif instance Functor (Shape Z) where fmap = \ f Nil -> Nil {-# INLINABLE fmap #-} {-# SPECIALIZE fmap :: (Int ->Int )-> (Shape Z Int)-> (Shape Z Int) #-} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 17 23:42:31 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Nov 2013 23:42:31 -0000 Subject: [GHC] #8538: confusing specialization CORE warning, also can't mark type class instances INLINEABLE unless class defn is marked INLINEABLE Message-ID: <045.0346f50016bea4aa3ebc93806a21256a@haskell.org> #8538: confusing specialization CORE warning, also can't mark type class instances INLINEABLE unless class defn is marked INLINEABLE ------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- As part of writing an array library for numerical purposes, I have a static sized strict list type for representing the Indexing tuple. One implementation strategy makes it a tad generic, and then I'm writing a bunch of manipulation utilities using Functor, Applicative and Foldable. I wrote it with all the functions marked INLINABLE so i could ensure that I could have the index arith calculations SPECIALIZE in the common cases. Unfortunately, it seems like type class instances can only marked INLINABLE if the type class definition is itself marked INLINE or INLINABLE. Considering i'm writing a numerical array library, I want to make sure that address arithmetic. This could could be argued to be by design (and thus a wont fix). That aside, I also get the following Warning for my "map2" function, which i found surprising. (and it perhaps is worth some investigation / cleanup ) {{{ src/Numerical/Types/Shape.hs:165:1: Warning: RULE left-hand side too complicated to desugar let { $dFunctor :: Functor (Shape ('S N0)) [LclId] $dFunctor = Numerical.Types.Shape.$fFunctorShape @ 'Z $dFunctor } in map2 @ a @ b @ c @ N2 (Numerical.Types.Shape.$fApplicativeShape @ ('S N0) (Numerical.Types.Shape.$fFunctorShape @ ('S N0) $dFunctor) (Numerical.Types.Shape.$fApplicativeShape @ 'Z $dFunctor Numerical.Types.Shape.$fApplicativeShape0)) }}} {{{ {-# LANGUAGE PolyKinds #-} {-# LANGUAGE BangPatterns #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE DeriveDataTypeable #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE StandaloneDeriving #-} {-# LANGUAGE CPP #-} {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE NoImplicitPrelude #-} module Numerical.Types.Shape where import GHC.Magic import Data.Monoid import Data.Functor import Data.Foldable import Control.Applicative -- import Numerical.Types.Nat import Prelude (seq, ($!),($),Show(..),Eq(),Int) data Nat = S !Nat | Z type N0 = Z type N1= S N0 type N2 = S N1 type N3 = S N2 type N4 = S N3 {- not doing the HLIST style shape because I don't want to have any pattern matchings going on. Also would play hell with locality quality in the address translation hackery, because there'd be an extra load to get those ints! -} infixr 3 :* {- the concern basically boils down to "will it specialize / inline well" -} data Shape (rank :: Nat) a where Nil :: Shape Z a (:*) :: !(a) -> !(Shape r a ) -> Shape (S r) a --deriving instance (Show (Shape rank a)) -- deriving instance Eq (Shape rank a) -- #if defined( __GLASGOW_HASKELL__ ) && ( __GLASGOW_HASKELL__ >= 707) --deriving instance Typeable (Shape rank a) -- #endif instance Functor (Shape Z) where fmap = \ f Nil -> Nil {-# INLINABLE fmap #-} {-# SPECIALIZE fmap :: (a ->b )-> (Shape Z a)-> (Shape Z b) #-} instance (Functor (Shape r)) => Functor (Shape (S r)) where fmap = \ f (a :* rest) -> f a :* fmap f rest {-# INLINABLE fmap #-} {-# SPECIALIZE fmap :: (a ->b )-> (Shape N1 a)-> (Shape N1 b) #-} {-# SPECIALIZE fmap :: (a ->b )-> (Shape N2 a)-> (Shape N2 b) #-} instance Applicative (Shape Z) where pure = \ _ -> Nil {-# INLINE pure #-} (<*>) = \ _ _ -> Nil {-# INLINE (<*>) #-} {-# SPECIALIZE pure :: a -> Shape Z a #-} {-# SPECIALIZE (<*>) :: Shape Z (a -> b) -> Shape Z a -> Shape Z b #-} instance Applicative (Shape r)=> Applicative (Shape (S r)) where pure = \ a -> a :* (pure a) {-# INLINE pure #-} (<*>) = \ (f:* fs) (a :* as) -> f a :* (inline (<*>)) fs as {-# INLINE (<*>) #-} {-# SPECIALIZE pure :: a -> (Shape Z a) #-} {-# SPECIALIZE pure :: a -> (Shape N1 a) #-} {-# SPECIALIZE pure :: a -> (Shape N2 a )#-} instance Foldable (Shape Z) where foldMap = \ _ _ -> mempty {-# INLINE foldMap #-} foldl = \ _ init _ -> init {-# INLINE foldl #-} foldr = \ _ init _ -> init {-# INLINE foldr #-} foldr' = \_ !init _ -> init {-# INLINE foldr' #-} foldl' = \_ !init _ -> init {-# INLINE foldl' #-} -- {-# SPECIALIZE foldMap :: Monoid m => (a -> m)-> Shape Z a -> m #-} -- {-# SPECIALIZE foldl :: (a ->b -> a) -> a -> Shape Z b -> a #-} -- {-# SPECIALIZE foldr :: (b ->a -> a) -> a -> Shape Z b -> a #-} -- {-# SPECIALIZE foldl' :: (a ->b -> a) -> a -> Shape Z b -> a #-} -- {-# SPECIALIZE foldr' :: (b ->a -> a) -> a -> Shape Z b -> a #-} instance (Foldable (Shape r)) => Foldable (Shape (S r)) where foldMap = \f (a:* as) -> f a <> foldMap f as {-# INLINE foldMap #-} foldl' = \f !init (a :* as) -> let next = f init a in next `seq` (inline foldl) f next as {-# INLINE foldl' #-} foldr' = \f !init (a :* as ) -> f a $! (inline foldr) f init as {-# INLINABLE foldr' #-} foldl = \f init (a :* as) -> let next = f init a in (inline foldl) f next as {-# INLINE foldl #-} foldr = \f init (a :* as ) -> f a $ (inline foldr) f init as {-# INLINE foldr #-} {-# SPECIALIZE foldMap::Monoid m => (a -> m)-> Shape N1 a -> m #-} {-# SPECIALIZE foldl :: (a ->b -> a) ->a -> Shape N1 b -> a #-} {-# SPECIALIZE foldr :: (b ->a -> a) -> a -> Shape N1 b -> a #-} {-# SPECIALIZE foldl' :: (a ->b -> a) -> a -> Shape N1 b -> a #-} {-# SPECIALIZE foldr' :: (b ->a -> a) -> a -> Shape N1 b -> a #-} {-# SPECIALIZE foldMap :: Monoid m => (a -> m)-> Shape N2 a -> m #-} {-# SPECIALIZE foldl :: (a ->b-> a) ->a -> Shape N2 b -> a #-} {-# SPECIALIZE foldr :: (b ->a -> a) -> a -> Shape N2 b -> a #-} {-# SPECIALIZE foldl' :: (a ->b -> a) -> a -> Shape N2 b -> a #-} {-# SPECIALIZE foldr' :: (b ->a -> a) -> a -> Shape N2 b -> a #-} -- map2 :: (Applicative (Shape r))=> (a->b ->c) -> (Shape r a) -> (Shape r b) -> (Shape r c ) map2 = \f l r -> pure f <*> l <*> r {-# INLINABLE map2 #-} {-# SPECIALIZE map2 :: (a -> b -> c ) -> (Shape Z a) -> (Shape Z b) -> (Shape Z c )#-} {-# SPECIALIZE map2 :: (a -> b -> c ) -> (Shape N1 a) -> (Shape N1 b) -> (Shape N1 c )#-} {-# SPECIALIZE map2 :: (a -> b -> c ) -> (Shape N2 a) -> (Shape N2 b) -> (Shape N2 c )#-} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 18 00:11:46 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Nov 2013 00:11:46 -0000 Subject: [GHC] #5212: waitForProcess: does not exist (No child processes) In-Reply-To: <048.492d65f473d4ede4cc264a57dc1aa8a1@haskell.org> References: <048.492d65f473d4ede4cc264a57dc1aa8a1@haskell.org> Message-ID: <063.836f92fcbb17563f1f3ea243144d0ac3@haskell.org> #5212: waitForProcess: does not exist (No child processes) ------------------------------------------------+-------------------------- Reporter: chrisdone | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 7.4.2 Resolution: invalid | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result at runtime | (amd64) Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by chrisdone): * cc: simonmar (added) * status: new => closed * resolution: => invalid Comment: The reason is because XMonad (and presumably some other library I was using two years ago) installs signal handlers for SIGCHILD: {{{ import Data.Maybe import Control.Monad import System.Posix.Signals import Control.Monad.Fix import Control.Exception import Control.Monad.Extra import Control.Monad.Trans import Control.Concurrent import System.Process import System.Posix.Process.ByteString main = do installSignalHandlers readProcess "ghc" ["--version"] "" >>= putStrLn -- | Ignore SIGPIPE to avoid termination when a pipe is full, and SIGCHLD to -- avoid zombie processes, and clean up any extant zombie processes. installSignalHandlers :: MonadIO m => m () installSignalHandlers = io $ do installHandler openEndedPipe Ignore Nothing installHandler sigCHLD Ignore Nothing (try :: IO a -> IO (Either SomeException a)) $ fix $ \more -> do x <- getAnyProcessStatus False False when (isJust x) more return () }}} This is pretty annoying because it breaks other uses of readProcess. My solution was to use a patched version of readProcess which handles exceptions thrown on waitForProcess. I guess this ticket can be closed? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 18 03:47:09 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Nov 2013 03:47:09 -0000 Subject: [GHC] #8528: Preprocessor issues building GHC HEAD on Mavericks In-Reply-To: <044.9e43150f2d22b2782c0ffcb891a3cae9@haskell.org> References: <044.9e43150f2d22b2782c0ffcb891a3cae9@haskell.org> Message-ID: <059.34ab185cc097f7359ed63d27a2de5c44@haskell.org> #8528: Preprocessor issues building GHC HEAD on Mavericks ----------------------------------------+---------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: clang Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8480 ----------------------------------------+---------------------------------- Comment (by nkpart): I've sent a small PR against alex on github (https://github.com/simonmar/alex/pull/37), and a similar change for happy (https://github.com/simonmar/happy/pull/12). With those 2 patches, you can build/install alex and happy with clang and then use those tools with GHC-over-gcc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 18 07:53:57 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Nov 2013 07:53:57 -0000 Subject: [GHC] #6056: INLINABLE pragma prevents worker-wrapper to happen. In-Reply-To: <044.48485356203668916cbd990ce18921d0@haskell.org> References: <044.48485356203668916cbd990ce18921d0@haskell.org> Message-ID: <059.d288591e60618b1d91e7b109c69ead48@haskell.org> #6056: INLINABLE pragma prevents worker-wrapper to happen. --------------------------------------------+------------------------------ Reporter: milan | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by akio): * cc: tkn.akio@? (added) Comment: I was hit by this. Perhaps this behavior should at least be documented, because it is unexpected (at least to me) that adding an INLINABLE pragma generates a less efficient call. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 18 07:56:43 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Nov 2013 07:56:43 -0000 Subject: [GHC] #5928: INLINABLE fails to specialize in presence of simple wrapper In-Reply-To: <044.f94356cf74dc801e8fb7c76a9eaeb24d@haskell.org> References: <044.f94356cf74dc801e8fb7c76a9eaeb24d@haskell.org> Message-ID: <059.e19914df7471466e403fccd02d78510f@haskell.org> #5928: INLINABLE fails to specialize in presence of simple wrapper -------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by akio): * cc: tkn.akio@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 18 08:00:23 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Nov 2013 08:00:23 -0000 Subject: [GHC] #6056: INLINABLE pragma prevents worker-wrapper to happen. In-Reply-To: <044.48485356203668916cbd990ce18921d0@haskell.org> References: <044.48485356203668916cbd990ce18921d0@haskell.org> Message-ID: <059.a6c98bc813bdfe72b85be00e18f437a6@haskell.org> #6056: INLINABLE pragma prevents worker-wrapper to happen. --------------------------------------------+------------------------------ Reporter: milan | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by liyang): * cc: hackage.haskell.org@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 18 10:48:57 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Nov 2013 10:48:57 -0000 Subject: [GHC] #6068: Panic in GHCi when using functional dependencies and promoted kinds In-Reply-To: <047.53daac14d65caa6ad1d72ce6ffc9d9ff@haskell.org> References: <047.53daac14d65caa6ad1d72ce6ffc9d9ff@haskell.org> Message-ID: <062.d94026fdcab8eae99c55d81b69d4e4a5@haskell.org> #6068: Panic in GHCi when using functional dependencies and promoted kinds -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.5 Resolution: fixed | Keywords: PolyKinds Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Unknown Test Case: polykinds/T6068 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: The bug showed up because you ran the testsuite with a compiler built with `-DDEBUG`. This is a good thing to do. Although there was a real bug, I couldn't come up with a way to tickle it without the `-DDEBUG` to flush it out, so I'm just closing. Thanks for alerting me to htis. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 18 10:51:20 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Nov 2013 10:51:20 -0000 Subject: [GHC] #8535: :info (->) doesn't print all relevant instances In-Reply-To: <044.14f3aac2591ade4afa7f287a68e9af5d@haskell.org> References: <044.14f3aac2591ade4afa7f287a68e9af5d@haskell.org> Message-ID: <059.73862e3f6542cd07b3afc7054a3e4679@haskell.org> #8535: :info (->) doesn't print all relevant instances -------------------------------------+------------------------------------ Reporter: parcs | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"404851a06d6e9dc8075ef31b60fc8b20fda23c22/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="404851a06d6e9dc8075ef31b60fc8b20fda23c22" Test Trac #8535 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 18 10:53:50 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Nov 2013 10:53:50 -0000 Subject: [GHC] #8535: :info (->) doesn't print all relevant instances In-Reply-To: <044.14f3aac2591ade4afa7f287a68e9af5d@haskell.org> References: <044.14f3aac2591ade4afa7f287a68e9af5d@haskell.org> Message-ID: <059.aa3792f403c782224894c69f1d5352ee@haskell.org> #8535: :info (->) doesn't print all relevant instances ---------------------------------------+----------------------------------- Reporter: parcs | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: ghci/scripts/T8535 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Changes (by simonpj): * status: patch => closed * testcase: => ghci/scripts/T8535 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 18 14:53:12 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Nov 2013 14:53:12 -0000 Subject: [GHC] #8339: Build fails with panic in vector In-Reply-To: <047.11ad03e22309907b83729c5dd2809e1b@haskell.org> References: <047.11ad03e22309907b83729c5dd2809e1b@haskell.org> Message-ID: <062.c1c2de226959389a8f65d9dacddbf91a@haskell.org> #8339: Build fails with panic in vector ----------------------------------------+---------------------------------- Reporter: trommler | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: libraries (other) | Version: 7.7 Resolution: | Keywords: vector Operating System: Unknown/Multiple | annotation Type of failure: Building GHC failed | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: #8203 #8212 ----------------------------------------+---------------------------------- Comment (by trommler): Yes, it is fixed. Thanks! {{{ "inplace/bin/ghc-stage2" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -package-name vector-0.10.9.1 -hide-all-packages -i -ilibraries/vector/. -ilibraries/vector/dist-install/build -ilibraries/vector/dist- install/build/autogen -Ilibraries/vector/dist-install/build -Ilibraries/vector/dist-install/build/autogen -Ilibraries/vector/include -Ilibraries/vector/internal -optP-DVECTOR_BOUNDS_CHECKS -optP-include -optPlibraries/vector/dist-install/build/autogen/cabal_macros.h -package base-4.7.0.0 -package deepseq-1.3.0.2 -package ghc-prim-0.3.1.0 -package primitive-0.5.1.0 -O2 -XHaskell98 -XCPP -XDeriveDataTypeable -O2 -no- user-package-db -rtsopts -odir libraries/vector/dist-install/build -hidir libraries/vector/dist-install/build -stubdir libraries/vector/dist- install/build -c libraries/vector/./Data/Vector/Fusion/Stream/Monadic.hs -o libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Monadic.o libraries/vector/Data/Vector/Fusion/Stream/Monadic.hs:104:1: Warning: Ignoring ANN annotation, because this is a stage-1 compiler or doesn't support GHCi }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 18 14:55:30 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Nov 2013 14:55:30 -0000 Subject: [GHC] #8339: Build fails with panic in vector In-Reply-To: <047.11ad03e22309907b83729c5dd2809e1b@haskell.org> References: <047.11ad03e22309907b83729c5dd2809e1b@haskell.org> Message-ID: <062.2dac36b2f077c4115bb75228119bd4cb@haskell.org> #8339: Build fails with panic in vector ----------------------------------------+---------------------------------- Reporter: trommler | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries (other) | Version: 7.7 Resolution: fixed | Keywords: vector Operating System: Unknown/Multiple | annotation Type of failure: Building GHC failed | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: #8203 #8212 ----------------------------------------+---------------------------------- Changes (by trommler): * status: infoneeded => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 18 15:34:52 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Nov 2013 15:34:52 -0000 Subject: [GHC] #2289: Needless reboxing of values when returning from a tight loop In-Reply-To: <043.32b2235b0e9fe1aba0c28a0cd28686b3@haskell.org> References: <043.32b2235b0e9fe1aba0c28a0cd28686b3@haskell.org> Message-ID: <058.95d8d4b11a0248c4183a3ba715516aa0@haskell.org> #2289: Needless reboxing of values when returning from a tight loop -------------------------------------+------------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.8.2 Resolution: | Keywords: boxing, loops, Operating System: Unknown/Multiple | performance Type of failure: Runtime | Architecture: Unknown/Multiple performance bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #2387,#1600 -------------------------------------+------------------------------------- Changes (by nomeata): * cc: mail@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 18 15:35:29 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Nov 2013 15:35:29 -0000 Subject: [GHC] #2387: Optimizer misses unboxing opportunity In-Reply-To: <044.f6f12d90c4b64de9fb4d129e27bf4881@haskell.org> References: <044.f6f12d90c4b64de9fb4d129e27bf4881@haskell.org> Message-ID: <059.6caab30934536346a120113825d8f14e@haskell.org> #2387: Optimizer misses unboxing opportunity -------------------------------------+------------------------------------- Reporter: dolio | Owner: Type: bug | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.8.2 Resolution: | Keywords: optimizer unbox Operating System: Linux | box Type of failure: Runtime | Architecture: x86_64 (amd64) performance bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #2289 -------------------------------------+------------------------------------- Changes (by nomeata): * cc: mail@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 18 15:35:38 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Nov 2013 15:35:38 -0000 Subject: [GHC] #1600: Optimisation: CPR the results of IO In-Reply-To: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> References: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> Message-ID: <062.af676ba2d1b14dd359cae99372c4da3a@haskell.org> #1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Moderate (less performance bug | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by nomeata): * cc: mail@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 18 15:43:43 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Nov 2013 15:43:43 -0000 Subject: [GHC] #8203: Yesod platform fails to build on ARM In-Reply-To: <048.40a62c5f9e06e9e2a3ae1234b589fdec@haskell.org> References: <048.40a62c5f9e06e9e2a3ae1234b589fdec@haskell.org> Message-ID: <063.5e770d997b4cb3b192a3623638ff4390@haskell.org> #8203: Yesod platform fails to build on ARM ---------------------------------+--------------------------- Reporter: randomist | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: arm Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+--------------------------- Changes (by monoidal): * status: new => closed * resolution: => fixed Comment: This should be fixed in HEAD (#7824, #8339, #7504). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 18 15:44:27 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Nov 2013 15:44:27 -0000 Subject: [GHC] #8212: ghc panic building vector on architectures w/o GHCi In-Reply-To: <048.2ffdc47bd795c4bbd4ca13bd36bf16a8@haskell.org> References: <048.2ffdc47bd795c4bbd4ca13bd36bf16a8@haskell.org> Message-ID: <063.e3bffeca0ac50099313db1fff19e90a6@haskell.org> #8212: ghc panic building vector on architectures w/o GHCi ----------------------------------------+---------------------------------- Reporter: ill_logic | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries (other) | Version: 7.4.1 Resolution: fixed | Keywords: vector Operating System: Unknown/Multiple | annotation Type of failure: Building GHC failed | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: #8203 ----------------------------------------+---------------------------------- Changes (by monoidal): * status: new => closed * resolution: => fixed Comment: This should be fixed in HEAD (#7824, #8339, #7504). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 18 15:49:14 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Nov 2013 15:49:14 -0000 Subject: [GHC] #1600: Optimisation: CPR the results of IO In-Reply-To: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> References: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> Message-ID: <062.90c32828b4a90e0cfb6629f005ebcb52@haskell.org> #1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Moderate (less performance bug | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by nomeata): Looking at examples for code where nested CPR could, would and should work, I found this ticket. At first glance, this looks good. But isn?t it the case that a usage like {{{ main = do _ <- facIO 1000 }}} will not do any calculation (besides counting down from 1000, and allocating a lot of thunks)? This shows that the transformation wanted here cannot be obtained without either offering two variants of the function (would inflate code size), or requires an analysis that calculating the factorial ''even if not needed'' will still always be better than allocating the thunks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 18 15:55:29 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Nov 2013 15:55:29 -0000 Subject: [GHC] #1600: Optimisation: CPR the results of IO In-Reply-To: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> References: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> Message-ID: <062.c4a25bc0c230f911d517a317b72d3336@haskell.org> #1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Moderate (less performance bug | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by nomeata): Maybe this code is a slightly better example for something where we want to avoid the allocations: {{{ facIO :: Int -> IO Int facIO n = if n < 2 then return 1 else do n' <- facIO (n-1); return $! n*n' }}} The worker Core currently (7.6.3) looks as {{{ FactIO.$wa [Occ=LoopBreaker] :: GHC.Prim.Int# -> GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, GHC.Types.Int #) [GblId, Arity=2, Caf=NoCafRefs, Str=DmdType LL] FactIO.$wa = \ (ww_snv :: GHC.Prim.Int#) (w_snx :: GHC.Prim.State# GHC.Prim.RealWorld) -> case GHC.Prim.<# ww_snv 2 of _ { GHC.Types.False -> case FactIO.$wa (GHC.Prim.-# ww_snv 1) w_snx of _ { (# ipv_amL, ipv1_amM #) -> case ipv1_amM of _ { GHC.Types.I# y_amd -> (# ipv_amL, GHC.Types.I# (GHC.Prim.*# ww_snv y_amd) #) } }; GHC.Types.True -> (# w_snx, lvl_roe #) } }}} and there is a very obvious packing/unpacking going on. A nested CPR should probably first be able to fix this case; and then venture into detecting cheap-and-total-code (as required for the variant without `$!`) beyond constructors. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 18 16:29:49 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Nov 2013 16:29:49 -0000 Subject: [GHC] #8468: ghc panic in deriving Generic1 on Array# In-Reply-To: <044.ffb20432abcbdb672e4810bd2bb326da@haskell.org> References: <044.ffb20432abcbdb672e4810bd2bb326da@haskell.org> Message-ID: <059.3af2b5ecfa21cf4dec8fc6a00b12ff1d@haskell.org> #8468: ghc panic in deriving Generic1 on Array# ---------------------------------------+----------------------------------- Reporter: ghorn | Owner: dreixel Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Comment (by Jose Pedro Magalhaes ): In [changeset:"2c74f9899ed5a99a4f6e8ea726841450c3d1211d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="2c74f9899ed5a99a4f6e8ea726841450c3d1211d" fixing canDoGenerics1 (fixes #8468) (fixes #8479) Signed-off-by: Jose Pedro Magalhaes }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 18 16:29:50 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Nov 2013 16:29:50 -0000 Subject: [GHC] #8479: Generic1 crashes with tyConStupidTheta when using associated type families In-Reply-To: <044.0858e05d425e69eb3762e2b850b8a662@haskell.org> References: <044.0858e05d425e69eb3762e2b850b8a662@haskell.org> Message-ID: <059.712b49a1b4e6f099f3f19de843daf342@haskell.org> #8479: Generic1 crashes with tyConStupidTheta when using associated type families -------------------------------------+------------------------------------- Reporter: ghorn | Owner: dreixel Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Generics, Operating System: Unknown/Multiple | Generic1 Type of failure: Compile-time | Architecture: Unknown/Multiple crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by Jose Pedro Magalhaes ): In [changeset:"2c74f9899ed5a99a4f6e8ea726841450c3d1211d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="2c74f9899ed5a99a4f6e8ea726841450c3d1211d" fixing canDoGenerics1 (fixes #8468) (fixes #8479) Signed-off-by: Jose Pedro Magalhaes }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 18 16:32:11 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Nov 2013 16:32:11 -0000 Subject: [GHC] #8468: ghc panic in deriving Generic1 on Array# In-Reply-To: <044.ffb20432abcbdb672e4810bd2bb326da@haskell.org> References: <044.ffb20432abcbdb672e4810bd2bb326da@haskell.org> Message-ID: <059.ebcdcdf082b2b342296ba5da40de8a1c@haskell.org> #8468: ghc panic in deriving Generic1 on Array# ---------------------------------------+----------------------------------- Reporter: ghorn | Owner: dreixel Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: T8468 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Changes (by dreixel): * status: new => closed * testcase: => T8468 * resolution: => fixed Comment: Fixed in HEAD, thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 18 16:33:06 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Nov 2013 16:33:06 -0000 Subject: [GHC] #8479: Generic1 crashes with tyConStupidTheta when using associated type families In-Reply-To: <044.0858e05d425e69eb3762e2b850b8a662@haskell.org> References: <044.0858e05d425e69eb3762e2b850b8a662@haskell.org> Message-ID: <059.15bc55f9eec3a3fc56733feaea407ba9@haskell.org> #8479: Generic1 crashes with tyConStupidTheta when using associated type families -------------------------------------+------------------------------------- Reporter: ghorn | Owner: dreixel Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Generics, Operating System: Unknown/Multiple | Generic1 Type of failure: Compile-time | Architecture: Unknown/Multiple crash | Difficulty: Unknown Test Case: T8479 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by dreixel): * status: new => closed * testcase: => T8479 * resolution: => fixed Comment: Fixed in HEAD, thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 18 17:24:17 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Nov 2013 17:24:17 -0000 Subject: [GHC] #8212: ghc panic building vector on architectures w/o GHCi In-Reply-To: <048.2ffdc47bd795c4bbd4ca13bd36bf16a8@haskell.org> References: <048.2ffdc47bd795c4bbd4ca13bd36bf16a8@haskell.org> Message-ID: <063.9cfe5412d5354c0b19a3fdde1b816d80@haskell.org> #8212: ghc panic building vector on architectures w/o GHCi ----------------------------------------+---------------------------------- Reporter: ill_logic | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries (other) | Version: 7.4.1 Resolution: fixed | Keywords: vector Operating System: Unknown/Multiple | annotation Type of failure: Building GHC failed | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: #8203 ----------------------------------------+---------------------------------- Comment (by ill_logic): Thanks for the update. Is it fixed by giving ghci support to Arm, or by removing ghci dependency from vector? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 18 18:14:57 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Nov 2013 18:14:57 -0000 Subject: [GHC] #8468: ghc panic in deriving Generic1 on Array# In-Reply-To: <044.ffb20432abcbdb672e4810bd2bb326da@haskell.org> References: <044.ffb20432abcbdb672e4810bd2bb326da@haskell.org> Message-ID: <059.3e63ec4691012d30bdd592453a4c2f17@haskell.org> #8468: ghc panic in deriving Generic1 on Array# ---------------------------------------+----------------------------------- Reporter: ghorn | Owner: dreixel Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: generics/T8468 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Changes (by simonpj): * testcase: T8468 => generics/T8468 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 18 18:15:34 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Nov 2013 18:15:34 -0000 Subject: [GHC] #8479: Generic1 crashes with tyConStupidTheta when using associated type families In-Reply-To: <044.0858e05d425e69eb3762e2b850b8a662@haskell.org> References: <044.0858e05d425e69eb3762e2b850b8a662@haskell.org> Message-ID: <059.b61fb1669a3f63b2010857064824c5e3@haskell.org> #8479: Generic1 crashes with tyConStupidTheta when using associated type families -------------------------------------+------------------------------------- Reporter: ghorn | Owner: dreixel Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Generics, Operating System: Unknown/Multiple | Generic1 Type of failure: Compile-time | Architecture: Unknown/Multiple crash | Difficulty: Unknown Test Case: generics/T8479 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: T8479 => generics/T8479 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 18 21:53:52 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Nov 2013 21:53:52 -0000 Subject: [GHC] #8539: Data.Complex shouldn't use default implementation of (**) Message-ID: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> #8539: Data.Complex shouldn't use default implementation of (**) -------------------------------------+------------------------------------- Reporter: jjaredsimpson | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Prelude | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Incorrect result Difficulty: Easy (less than 1 | at runtime hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- {{{ Prelude Data.Complex> 0**2 0.0 Prelude Data.Complex> 0**2 :: Complex Double NaN :+ NaN Prelude Data.Complex> exp $ 2 * log 0 :: Complex Double NaN :+ NaN Prelude Data.Complex> log 0 :: Complex Double (-Infinity) :+ 0.0 Prelude Data.Complex> 2 * it :: Complex Double (-Infinity) :+ NaN Prelude Data.Complex> exp it :: Complex Double NaN :+ NaN }}} So Complex uses the default implementation of (!**). Then when 2*(-inf :+ 0) is evaluated. We do (2 * -inf - 0*0) :+ (2*0 + -inf*0). Which because of -inf*0 sets the imaginary part to NaN. Then exp (-inf :+ NaN) = exp x cos y :+ exp x sin y which becomes 0 * cos NaN :+ 0 * sin NaN. So we end up with NaN :+ NaN. Ross Paterson suggested: I would say the default implementation of (!**) is wrong: to match the Float/Double instances it should be x !** y = if x == 0 then 0 else exp (log x * y) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 18 22:43:14 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Nov 2013 22:43:14 -0000 Subject: [GHC] #8539: Data.Complex shouldn't use default implementation of (**) In-Reply-To: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> References: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> Message-ID: <067.184d424f545e2abacc1319cdb26de14f@haskell.org> #8539: Data.Complex shouldn't use default implementation of (**) -------------------------------------+------------------------------------- Reporter: jjaredsimpson | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Prelude | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Incorrect result | Difficulty: Easy (less than 1 at runtime | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by isaacdupree): That solves `0**nonzero`. `0**0` is controversial but often 1 ( https://en.wikipedia.org/wiki/0^0 ) and in Double is 1: {{{ > 0**0 :: Double 1.0 }}} We probably want `0**0` to be consistent between Double and Complex Double. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 19 00:45:38 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Nov 2013 00:45:38 -0000 Subject: [GHC] #1831: reify never provides the declaration of variables In-Reply-To: <044.a26292943bffdeb4bdb3ded03525ce1f@haskell.org> References: <044.a26292943bffdeb4bdb3ded03525ce1f@haskell.org> Message-ID: <059.a63c1769dc1e6c8380b822c3048e98ca@haskell.org> #1831: reify never provides the declaration of variables -------------------------------------+------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Template Haskell | Version: 6.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by polkovnikov.ph): I don't actually think there's a lack of interest in this functionality. It could finally let programmers to write TH-based translation libraries. For example, one could create `javascript` such that `print $ javascript sort` generates JS code for list sorting, effectively reusing Prelude. Also, some language extensions like Megacz's generalized arrows could become libraries. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 19 03:28:12 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Nov 2013 03:28:12 -0000 Subject: [GHC] #8539: Data.Complex shouldn't use default implementation of (**) In-Reply-To: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> References: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> Message-ID: <067.235a5381069b9b94a03e22b8a4bd5d8f@haskell.org> #8539: Data.Complex shouldn't use default implementation of (**) -------------------------------------+------------------------------------- Reporter: jjaredsimpson | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Prelude | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Incorrect result | Difficulty: Easy (less than 1 at runtime | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by Scott Turner): Agree with isaacdupree that 0{{{**}}}0 == 1.0 The above {{{ x ** y = if x == 0 then 0 else exp (log x * y) }}} is incorrect for negative y. Consider {{{ $ ghci GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help Prelude> 0.0**(-2.0) Infinity }}} There are other interesting cases. If the real part of y is positive, then the result should be 0. If the real part is negative, then the result should be Infinity. If y is imaginary, the result should be NaN. For the most part, {{{ Infinity ** y = 0 ** (negate y) }}} I won't address -0 and 0:+(-0) because they deserve more controversy than I can handle. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 19 04:31:43 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Nov 2013 04:31:43 -0000 Subject: [GHC] #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough In-Reply-To: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> References: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> Message-ID: <062.0d5faed81e4402be3cb94f342219b9b5@haskell.org> #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): Yes, I agree, sadly. Simon PJ and I (in a phone call) thought that we could solve all our problems with `topNormaliseType_maybe`, which "evaluates" out any newtypes and type functions that appear ''at the top'' of a type. If there is no way to reduce a type at the top level, the function fails. Because the `Coercible` code really only examines the top level, we thought this was sufficient. However, it's not, because of the example you (nomeata) give, with `RecNT` and `RecNT2`. My only thought now for how to do this is to record in the wanted constraint which newtypes have been expanded, perhaps using the `checkRecTc` technology. This would mean either creating a new constructor for `Ct` or a new field somewhere. Perhaps creating a new constructor isn't so bad -- that's how nominal equality is handled. Canonicalisation can then convert a normal class-based constraint into the new `CCoercible` or something. I still think there is hope here, and I do think we should strive to include recursive newtypes in this approach. In my attempt to fix this all, I've done some refactoring in `getCoercibleInst`. You can see my work at [http://github.com/goldfirere/ghc my github repo], branch `coerce`. That branch also introduces a `GenCoercion` class containing `Coercion` and `TcCoercion`. That may or may not be a good idea, but it worked nicely with `topNormaliseType_maybe`, which has to sometimes produce a `Coercion` and sometimes a `TcCoercion`. I've also discovered that `Coercible` really ought to be poly-kinded. If we have `newtype List a = MkList [a]`, then we might want `Coercible (StateT Int [] a) (StateT Int List a)`, which would lead to `Coercible [] List`, but that's ill-kinded! I think the first coercion is quite legitimate, and so we should find some way of allowing it. Generalizing `Coercible` seems to be the obvious way forward, but other possibilities are out there, I suppose. This problem (with `Coercible` being mono-kinded) came up in practice as a core-lint failure when compiling the libraries in my branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 19 05:04:50 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Nov 2013 05:04:50 -0000 Subject: [GHC] #8520: ghc.exe: internal error: loadArchive: error whilst reading `C' In-Reply-To: <044.7423adcbc9658116359111a685ed6de6@haskell.org> References: <044.7423adcbc9658116359111a685ed6de6@haskell.org> Message-ID: <059.38726577f22d120e3bbf590776cecf9f@haskell.org> #8520: ghc.exe: internal error: loadArchive: error whilst reading `C' ----------------------------------+--------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+--------------------------- Changes (by awson): * priority: highest => low -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 19 05:05:38 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Nov 2013 05:05:38 -0000 Subject: [GHC] #8540: Template Haskell handling bug in ghc-7.7.20131115 under windows Message-ID: <044.a2405e435a0516e234d799c5d8afd594@haskell.org> #8540: Template Haskell handling bug in ghc-7.7.20131115 under windows ----------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+---------------------------------- Compiling this: {{{ {-# LANGUAGE TemplateHaskell #-} module Foo where import Data.Aeson import Data.Aeson.TH data Test = Test $(deriveFromJSON defaultOptions ''Test) }}} ghc-7.7.20131115 crashes with {{{ Foo.hs:10:3: Can't find interface-file declaration for variable Data.Aeson.TH.parseTypeMismatch' Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error In the expression: Data.Aeson.TH.parseTypeMismatch' "Test" "Foo.Test" "an empty Array" ("Array of length " ++ ((show . Data.Vector.length) arr_a3BM)) In a case alternative: Array arr_a3BM | Data.Vector.null arr_a3BM -> Control.Applicative.pure Test | otherwise -> Data.Aeson.TH.parseTypeMismatch' "Test" "Foo.Test" "an empty Array" ("Array of length " ++ ((show . Data.Vector.length) arr_a3BM)) In the expression: case value_a3BL of { Array arr_a3BM | Data.Vector.null arr_a3BM -> Control.Applicative.pure Test | otherwise -> Data.Aeson.TH.parseTypeMismatch' "Test" "Foo.Test" "an empty Array" ("Array of length " ++ ((show . Data.Vector.length) arr_a3BM)) other_a3BN -> Data.Aeson.TH.parseTypeMismatch' "Test" "Foo.Test" "Array" (Data.Aeson.TH.valueConName other_a3BN) } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 19 06:19:37 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Nov 2013 06:19:37 -0000 Subject: [GHC] #8540: Template Haskell handling bug in ghc-7.7.20131115 (was: Template Haskell handling bug in ghc-7.7.20131115 under windows) In-Reply-To: <044.a2405e435a0516e234d799c5d8afd594@haskell.org> References: <044.a2405e435a0516e234d799c5d8afd594@haskell.org> Message-ID: <059.6704861aba1ef6f314a43ee429879578@haskell.org> #8540: Template Haskell handling bug in ghc-7.7.20131115 -------------------------------------+------------------------------------ Reporter: awson | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by awson): * priority: high => highest * os: Windows => Unknown/Multiple * architecture: x86 => Unknown/Multiple Comment: Both windows x86 and linux x86_64 GHCs have this bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 19 07:52:53 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Nov 2013 07:52:53 -0000 Subject: [GHC] #8534: DeriveFunctor and PolyKinds In-Reply-To: <047.c19c17e271106ecdf2c2cb0268320d27@haskell.org> References: <047.c19c17e271106ecdf2c2cb0268320d27@haskell.org> Message-ID: <062.1bf67c628daaaa35ddd72333579023e7@haskell.org> #8534: DeriveFunctor and PolyKinds ----------------------------------------------+---------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler (Type checker) | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by Simon Peyton Jones ): In [changeset:"851548d8d14e1dcf79867855b49519421734ede6/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="851548d8d14e1dcf79867855b49519421734ede6" Improve the 'deriving' code for polykinded data types Fixes Trac #8534. See Note [Match kinds in deriving] in TcDeriv. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 19 07:56:21 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Nov 2013 07:56:21 -0000 Subject: [GHC] #8534: DeriveFunctor and PolyKinds In-Reply-To: <047.c19c17e271106ecdf2c2cb0268320d27@haskell.org> References: <047.c19c17e271106ecdf2c2cb0268320d27@haskell.org> Message-ID: <062.c99d8b5bfbd69828ae71c394328abb08@haskell.org> #8534: DeriveFunctor and PolyKinds ----------------------------------------------+---------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler (Type checker) | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by Simon Peyton Jones ): In [changeset:"7c10d0324008584b5455ec76550286c7c70dd049/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="7c10d0324008584b5455ec76550286c7c70dd049" Test Trac #8534 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 19 07:56:59 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Nov 2013 07:56:59 -0000 Subject: [GHC] #8534: DeriveFunctor and PolyKinds In-Reply-To: <047.c19c17e271106ecdf2c2cb0268320d27@haskell.org> References: <047.c19c17e271106ecdf2c2cb0268320d27@haskell.org> Message-ID: <062.02936cdf1adaa6f1afe25648a9b94888@haskell.org> #8534: DeriveFunctor and PolyKinds ----------------------------------------------+---------------------------- Reporter: monoidal | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: Compiler (Type checker) | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: polykinds/T8534 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Changes (by simonpj): * status: new => closed * testcase: => polykinds/T8534 * resolution: => fixed Comment: Thanks for identifying this. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 19 08:23:02 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Nov 2013 08:23:02 -0000 Subject: [GHC] #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough In-Reply-To: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> References: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> Message-ID: <062.c6f2065024d9559c2b6e793235f9932a@haskell.org> #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonpj): * cc: diatchki (added) Comment: Let's note that even with `Fix` there is a legitimate and useful coercion `Coercible (Fix (Either x)) (Either x (Fix (Either x)))`. We can write it by hand, and you might want to get from the `Fix` form to the `Either` form. So the same instance declaration may terminate when solving some constraints, but not for others. The constraint solver already stores a "depth" in each constraint. The depth is incremented by 1 each time you use an instance declaration. For example, when you use `instance Eq a => Eq [a]` to solve `d1:Eq [Int]`, by reducing it to `d2:Eq Int`, then `d2` has a depth one greater than `d1`. Since such instance declarations remove a type constructor, a deep recursion implies a deeply nested type, like `[[[[[[Int]]]]]`. So (proposal) maybe we can simply depth-bound the solver. In fact it already is; this is the `-fcontext-stack` flag. (Actually, in fact I fear that we may instead construct a recursive dictionary instead, which we probably do not want for newtypes, though we do for data types, because we'll see a constraint we have already solved. See [http://research.microsoft.com/en- us/um/people/simonpj/papers/hmap/index.htm Scrap your boilerplate with class] for why we want recursive dictionaries.) Here is one other idea. Suppose we have the wanted constraint `Coercible [alpha] [Int]`. Should we use the `Coercible a b => Coercible [a] [b]` instance to solve it? Well, if it turns out that `alpha` (a unification variable) ultimately is `Int`, then doing so would not be wrong, but it would be a waste because the identity coercion will do the job. So maybe this is a bit like the `Equal` type family in the [http://research.microsoft.com/~simonpj/papers/ext-f Closed type families] paper: we should not do the list/list reduction unless the argument types are "apart" (in the terminology of the paper). But that would be too strong. Consider {{{ f :: Coercible a b => [a] -> [b] f x = coerce x }}} This should work, but it requires use of that list/list instance, and we don't know that `a` and `b` are un-equal. It's just that in this context we can treat `a` and `b` as skolems and hence "apart" for this purpose. Except, even then it's not quite right: we could have {{{ f :: (a~b, Coercible a b) => [a] -> [b] }}} and now `a` and `b` are provably equal. (Or some GADT version thereof.) So I think we probably need the depth-bound thing too. Do any of these ideas make sense to you guys? I'll add Iavor to the cc list. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 19 08:28:34 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Nov 2013 08:28:34 -0000 Subject: [GHC] #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough In-Reply-To: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> References: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> Message-ID: <062.754edf0b550de94adc085d15c6bd1097@haskell.org> #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): > (Actually, in fact I fear that we may instead construct a recursive dictionary instead, which we probably do not want for newtypes, though we do for data types, because we'll see a constraint we have already solved. See ?Scrap your boilerplate with class for why we want recursive dictionaries.) JFTR: Last time I checked, we did, leading to a non-terminating Coercion value. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 19 09:11:41 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Nov 2013 09:11:41 -0000 Subject: [GHC] #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough In-Reply-To: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> References: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> Message-ID: <062.b15c5811e0c21d97db32891a69847160@haskell.org> #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): I discussed with Joachim. The "apartness" idea definitely doesn't work. Consider {{{ newtype Fix1 x = F1 (x (Fix1 x)) newtype Fix2 x = F2 (x (Fix2 x)) }}} and try solving `Coercible (Fix1 (Either Age)) (Fix2 (Either Int))`. Everything is fully known, and always apart, yet we get a loop. Moreover, analysing the definitions to find loop breakers (as GHC does now) fails in the presence of type functions {{{ newtype Bad a = B (F a) type instance F Int = Bad Int }}} Conclusion: the depth-bound idea is the only real option. We also need to prevent the construction of recursive dictionaries, but we can use the depth of a constraint to stop that too; do not solve a constraint of depth n by using a constraint of lower depth. This is rather conservative, but it's enough to prevent recursive dictionary construction. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 19 10:02:22 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Nov 2013 10:02:22 -0000 Subject: [GHC] #8540: Template Haskell handling bug in ghc-7.7.20131115 ? (was: Template Haskell handling bug in ghc-7.7.20131115) In-Reply-To: <044.a2405e435a0516e234d799c5d8afd594@haskell.org> References: <044.a2405e435a0516e234d799c5d8afd594@haskell.org> Message-ID: <059.42cbe09e5b7c727331708166287b1968@haskell.org> #8540: Template Haskell handling bug in ghc-7.7.20131115 ? -------------------------------------+------------------------------------ Reporter: awson | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by awson): * priority: highest => normal Comment: Ok, it seems adding a bunch of explicit exports to Data.Aeson.TH makes the problem go. It looks like previously TH implicitly exposed all variables referenced in exported functions and this is no longer the case. Which behaviour is erroneous then? Probably, current behaviour is not a bug at all but quite contrary - the fix of looong-standing bug? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 19 10:06:59 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Nov 2013 10:06:59 -0000 Subject: [GHC] #8540: Template Haskell handling bug in ghc-7.7.20131115 ? In-Reply-To: <044.a2405e435a0516e234d799c5d8afd594@haskell.org> References: <044.a2405e435a0516e234d799c5d8afd594@haskell.org> Message-ID: <059.bfa4fd5395cdfdcdf542cd2b20cf77be@haskell.org> #8540: Template Haskell handling bug in ghc-7.7.20131115 ? -------------------------------------+------------------------------------ Reporter: awson | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): Might it be possible to make a small test case? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 19 10:16:05 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Nov 2013 10:16:05 -0000 Subject: [GHC] #8540: Template Haskell handling bug in ghc-7.7.20131115 ? In-Reply-To: <044.a2405e435a0516e234d799c5d8afd594@haskell.org> References: <044.a2405e435a0516e234d799c5d8afd594@haskell.org> Message-ID: <059.c4c04982c9469ab4f7854c67f8c854b5@haskell.org> #8540: Template Haskell handling bug in ghc-7.7.20131115 ? -------------------------------------+------------------------------------ Reporter: awson | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): I did install aeson, but go this when compiling your program {{{ simonpj at cam-05-unx:~/tmp$ /home/simonpj/5builds/validate-HEAD/inplace/bin /ghc-stage2 -c T8540.hs Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package array-0.5.0.0 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package primitive-0.5.1.0 ... linking ... done. Loading package vector-0.10.9.1 ... linking ... done. Loading package pretty-1.1.1.1 ... linking ... done. Loading package old-locale-1.0.0.6 ... linking ... done. Loading package time-1.4.1 ... linking ... done. Loading package containers-0.5.3.1 ... linking ... done. Loading package bytestring-0.10.4.0 ... linking ... done. Loading package text-0.11.3.1 ... : can't load .so/.DLL for: libHStext-0.11.3.1.so (libHStext-0.11.3.1.so: cannot open shared object file: No such file or directory) simonpj at cam-05-unx:~/tmp$ }}} Something to do with dynamic linking, I suppose, but I don't know how to fix it. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 19 10:21:11 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Nov 2013 10:21:11 -0000 Subject: [GHC] #8541: Coercible should be higher-kinded Message-ID: <046.fae54951872f95e2ddf78ecfc5d15947@haskell.org> #8541: Coercible should be higher-kinded ------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Just discussed with SJP: The Coercible should be higher kinded, and it seems to be straight forward. Given {{{ data T f = T (f Int) newtype List a = [a] }}} we want to be able to derive {{{ Coercible (T (Either Int)) (T (Either Age)) Coercible (T List) (T []) }}} We now allow `Coercible` at a kind `* -> k`, with the following intuition: {{{ Coercible A B ?? (forall a. Coercible (A a) (B a)) }}} Note that this is ok independent of the role of `A`?s parameter, as we are not modifying that parameter here. Allowing such constraints, we therefore, we need these constraints exist in theory (but are in fact generated on demand, so only those of the rind kindnessare visible to the constraint solver) for `Either` and `List`: {{{ instance (Coercible a b, Coercible c d) => Coercible (Either a c) (Either b d) -- old instance Coercible a b => Coercible (Either a) (Either b) -- new instance Coercible [a] b => Coercible (List a) b -- old instance Coercible b [a] => Coercible b (List a) -- old instance Coercible a b => Coercible (List a) (List b) -- old instance Coercible [] b => Coercible List b -- new instance Coercible b [] => Coercible b List -- new }}} This solves the cases above. It does not solve all cases, though. Consider {{{ newtype NT1 a = NT1 (a -> Int) newtype NT2 a = NT2 (a -> Int) }}} and we want to solve `Coercible (T NT1) (T NT2)`. Although, by the definition above, `Coercible NT1 NT2` should hold, such a coercion cannot be created (as far as I can see). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 19 10:22:35 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Nov 2013 10:22:35 -0000 Subject: [GHC] #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough In-Reply-To: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> References: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> Message-ID: <062.405ac03fa207aedb3e4cf00ff28c15d9@haskell.org> #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8541 -------------------------------------+------------------------------------ Changes (by nomeata): * related: => #8541 Comment: See #8541 for a ticket discussing poly-kind `Coercible`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 19 11:45:06 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Nov 2013 11:45:06 -0000 Subject: [GHC] #8540: Template Haskell handling bug in ghc-7.7.20131115 ? In-Reply-To: <044.a2405e435a0516e234d799c5d8afd594@haskell.org> References: <044.a2405e435a0516e234d799c5d8afd594@haskell.org> Message-ID: <059.d217092064c0ba0eb4bc7ab92b979122@haskell.org> #8540: Template Haskell handling bug in ghc-7.7.20131115 ? -------------------------------------+------------------------------------ Reporter: awson | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by awson): Here is the simplest test case: Foo.hs {{{ {-# LANGUAGE TemplateHaskell #-} module Foo (foo) where import Language.Haskell.TH foo :: Q Exp foo = [| bar |] bar :: Int bar = 5 }}} Baz.hs {{{ {-# LANGUAGE TemplateHaskell #-} module Baz where import Foo baz :: Int baz = $foo }}} Current GHC gives {{{ Baz.hs:8:7: Can't find interface-file declaration for variable Foo.bar Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error In the expression: Foo.bar In an equation for `baz': baz = Foo.bar }}} when compiling Baz.hs. But if I explicitly export bar from Foo.hs: {{{ {-# LANGUAGE TemplateHaskell #-} module Foo (foo, bar) where import Language.Haskell.TH foo :: Q Exp foo = [| bar |] bar :: Int bar = 5 }}} current GHC gets happy. Older GHCs were able to live without this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 19 11:51:50 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Nov 2013 11:51:50 -0000 Subject: [GHC] #8541: Coercible should be higher-kinded In-Reply-To: <046.fae54951872f95e2ddf78ecfc5d15947@haskell.org> References: <046.fae54951872f95e2ddf78ecfc5d15947@haskell.org> Message-ID: <061.252b154cf42469ee2f6e975492dad182@haskell.org> #8541: Coercible should be higher-kinded -------------------------------------+------------------------------------ Reporter: nomeata | Owner: nomeata Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Indeed straight forward, see 8959c69104eb032b75ec94dcf9cda3edd2b46423 (ghc) and bbfaff2fa89b21bee058af7e6e6ddd66524524d0 (testsuite); currently on the branch wip/T8541 (I wonder why they were not auto-linked ? is that only working for master?). The code did not check saturation of type constructors, so it worked out of the box for the positive examples from here. So let?s see what happens with the negative ones... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 19 12:19:58 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Nov 2013 12:19:58 -0000 Subject: [GHC] #8541: Coercible should be higher-kinded In-Reply-To: <046.fae54951872f95e2ddf78ecfc5d15947@haskell.org> References: <046.fae54951872f95e2ddf78ecfc5d15947@haskell.org> Message-ID: <061.0d90479766ea5e0917a465ab0b384dd7@haskell.org> #8541: Coercible should be higher-kinded -------------------------------------------------+------------------------- Reporter: nomeata | Owner: Type: task | nomeata Priority: normal | Status: patch Component: Compiler | Milestone: Resolution: | Version: 7.6.3 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: TcCoercible, | Unknown/Multiple TcCoercibleFail3 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by nomeata): * status: new => patch * testcase: => TcCoercible, TcCoercibleFail3 Comment: Added a few testcases and avoiding panics for `Coercible (T NT1) (T NT2)`. Please break (or review) my code! Fancy side-by-side-diffs: http://git.haskell.org/ghc.git/commitdiff/refs/heads/wip/T8541?hp=851548d8d14e1dcf79867855b49519421734ede6;ds=sidebyside http://git.haskell.org/testsuite.git/commitdiff/refs/heads/wip/T8541?hp=18624e7ac6e391d90963500e1fecf0affc551dbf -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 19 14:32:01 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Nov 2013 14:32:01 -0000 Subject: [GHC] #8212: ghc panic building vector on architectures w/o GHCi In-Reply-To: <048.2ffdc47bd795c4bbd4ca13bd36bf16a8@haskell.org> References: <048.2ffdc47bd795c4bbd4ca13bd36bf16a8@haskell.org> Message-ID: <063.2f4c2fa0dcbac34dbf402044bd2e01a2@haskell.org> #8212: ghc panic building vector on architectures w/o GHCi ----------------------------------------+---------------------------------- Reporter: ill_logic | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries (other) | Version: 7.4.1 Resolution: fixed | Keywords: vector Operating System: Unknown/Multiple | annotation Type of failure: Building GHC failed | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: #8203 ----------------------------------------+---------------------------------- Comment (by monoidal): vector should now build. I don't know what's the precise status of ghci on arm; we still have #7794 and #8380. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 19 14:51:11 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Nov 2013 14:51:11 -0000 Subject: [GHC] #8542: Suggest NegativeLiterals Message-ID: <047.bf5090fe22a22eb99898221a0c557cee@haskell.org> #8542: Suggest NegativeLiterals ------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- If we write -128 :: Int8, we get a useful warning (#7895), but it would be even better to suggest NegativeLiterals. Patch incoming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 19 15:00:36 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Nov 2013 15:00:36 -0000 Subject: [GHC] #8540: Template Haskell handling bug in ghc-7.7.20131115 ? In-Reply-To: <044.a2405e435a0516e234d799c5d8afd594@haskell.org> References: <044.a2405e435a0516e234d799c5d8afd594@haskell.org> Message-ID: <059.e7177d9bf7d0a0d224f6714974ef6a0c@haskell.org> #8540: Template Haskell handling bug in ghc-7.7.20131115 ? -------------------------------------+------------------------------------ Reporter: awson | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): Thanks. I understand now. I'm on it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 19 15:11:27 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Nov 2013 15:11:27 -0000 Subject: [GHC] #8542: Suggest NegativeLiterals In-Reply-To: <047.bf5090fe22a22eb99898221a0c557cee@haskell.org> References: <047.bf5090fe22a22eb99898221a0c557cee@haskell.org> Message-ID: <062.7403b3ba4adb8c69a536cf6cdad70245@haskell.org> #8542: Suggest NegativeLiterals -------------------------------------+------------------------------------ Reporter: monoidal | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by monoidal): * status: new => patch Comment: Patch attached. It also gives an (incorrect) suggestion for 128 :: Int8, but this shouldn't matter. While we are at it: to determine whether an `Int` literal is correct we test with `minBound :: Int` and `maxBound :: Int`. This can vary between machines. Should this be changed to testing against `2^30` or something similar? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 19 16:48:15 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Nov 2013 16:48:15 -0000 Subject: [GHC] #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough In-Reply-To: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> References: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> Message-ID: <062.db4b6b8e315b76cebf11985767691060@haskell.org> #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8541 -------------------------------------+------------------------------------ Comment (by goldfire): Yes, the depth-bound seems sensible and is probably the only real solution to this problem. We should be aware of a particularly nasty case, like this: {{{ Coercible (Maybe (Fix Maybe)) (Fix Maybe) }}} This should be solvable (and I posit that more sensible cases might come up in practice). The current algorithm simplifies the left-hand type (LHT) as far as it can, then simplifies the right-hand type (RHT) as far as it can. I would worry that the depth would hit its maximum when reducing the LHT and then refuse to simplify the RHT. Even if we tracked depths separately for the two sides, the right side would hit the maximum depth right before the two sides unify, leading to failure, no matter what the depth is! Note that if we just switch the order of the arguments to `Coercible`, this goal is easy to solve, after one reduction on the LHT. Having the solubility of a symmetric constraint depend on the order of arguments is undesirable. I have no good ideas of how to fix this, at the moment. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 19 16:50:52 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Nov 2013 16:50:52 -0000 Subject: [GHC] #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough In-Reply-To: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> References: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> Message-ID: <062.68f1be186a9fab7d53d569e58ab219f0@haskell.org> #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8541 -------------------------------------+------------------------------------ Comment (by nomeata): Have you checked that it fails? I believe it would work: {{{ Coercible (Maybe (Fix Maybe)) (Fix Maybe) }}} is only matched by {{{ instance Coercible a (Maybe (Fix Maybe) => Coercible a (Fix Maybe) }}} so we are left with {{{ Coercible (Maybe (Fix Maybe)) (Maybe (Fix Maybe)) }}} which is solved by the reflexive instance {{{ Coercible a a }}} (I?m not claiming that all cases work as smoothly, but they need to be a bit more constructed :-)) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 19 22:17:53 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Nov 2013 22:17:53 -0000 Subject: [GHC] #6084: Add stg_ap_pnnv and related call patterns In-Reply-To: <049.725af368c945c55559bda8b9bf6a9e31@haskell.org> References: <049.725af368c945c55559bda8b9bf6a9e31@haskell.org> Message-ID: <064.5841b4aece0c1374cfa13ae2a5feaf9c@haskell.org> #6084: Add stg_ap_pnnv and related call patterns -------------------------------------+------------------------------------ Reporter: SimonMeier | Owner: simonmar Type: feature request | Status: new Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: 8313 | Related Tickets: -------------------------------------+------------------------------------ Changes (by akio): * cc: tkn.akio@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 19 22:45:58 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Nov 2013 22:45:58 -0000 Subject: [GHC] #4: -fext-core -fno-core behaves funny In-Reply-To: <045.ae3f8b0e845fade77535d5ec02817b6a@haskell.org> References: <045.ae3f8b0e845fade77535d5ec02817b6a@haskell.org> Message-ID: <060.0f696ad5212a27303b06264a46c9599b@haskell.org> #4: -fext-core -fno-core behaves funny ---------------------+-------------------- Reporter: josefs | Owner: nobody Type: bug | Status: closed Priority: normal | Milestone: Component: Driver | Version: None Resolution: Fixed | Keywords: ---------------------+-------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"0346dee9231db0b3e7662a1f738ec688669b4c04/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="0346dee9231db0b3e7662a1f738ec688669b4c04" Update `primitive` to upstream's current HEAD This includes a fix to silence a GCC warning which causes validate failures on OSX (see haskell/primitive#4 for more details) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 19 23:00:32 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Nov 2013 23:00:32 -0000 Subject: [GHC] #8541: Coercible should be higher-kinded In-Reply-To: <046.fae54951872f95e2ddf78ecfc5d15947@haskell.org> References: <046.fae54951872f95e2ddf78ecfc5d15947@haskell.org> Message-ID: <061.0abcd95d0ff830d09d0a0e6804675493@haskell.org> #8541: Coercible should be higher-kinded -------------------------------------------------+------------------------- Reporter: nomeata | Owner: Type: task | nomeata Priority: normal | Status: patch Component: Compiler | Milestone: Resolution: | Version: 7.6.3 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: TcCoercible, | Unknown/Multiple TcCoercibleFail3 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by hvr): Replying to [comment:1 nomeata]: > currently on the branch wip/T8541 (I wonder why they were not auto- linked ? is that only working for master?). yes, it's to avoid having multiple redundant commits attached to the same ticket; so the commit will be linked to this ticket as soon as the commit becomes reachable from master for the first time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 19 23:02:34 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Nov 2013 23:02:34 -0000 Subject: [GHC] #8541: Coercible should be higher-kinded In-Reply-To: <046.fae54951872f95e2ddf78ecfc5d15947@haskell.org> References: <046.fae54951872f95e2ddf78ecfc5d15947@haskell.org> Message-ID: <061.881c8f1abd757b38a3e175a0bc7d237c@haskell.org> #8541: Coercible should be higher-kinded -------------------------------------------------+------------------------- Reporter: nomeata | Owner: Type: task | nomeata Priority: normal | Status: patch Component: Compiler | Milestone: Resolution: | Version: 7.6.3 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: TcCoercible, | Unknown/Multiple TcCoercibleFail3 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by nomeata): Makes sense, given that `wip/`-branches can be rebased. Thanks for the clarification. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 20 04:37:01 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Nov 2013 04:37:01 -0000 Subject: [GHC] #8541: Coercible should be higher-kinded In-Reply-To: <046.fae54951872f95e2ddf78ecfc5d15947@haskell.org> References: <046.fae54951872f95e2ddf78ecfc5d15947@haskell.org> Message-ID: <061.27e658c4e87d77b66e9405b28ab6e3a2@haskell.org> #8541: Coercible should be higher-kinded -------------------------------------------------+------------------------- Reporter: nomeata | Owner: Type: task | nomeata Priority: normal | Status: patch Component: Compiler | Milestone: Resolution: | Version: 7.6.3 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: TcCoercible, | Unknown/Multiple TcCoercibleFail3 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by goldfire): The changes certainly look sensible to me... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 20 08:07:19 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Nov 2013 08:07:19 -0000 Subject: [GHC] #5757: zero unexpected failures on all tier 1 platforms In-Reply-To: <047.3b6881d640a4e0fd41999b488e43799d@haskell.org> References: <047.3b6881d640a4e0fd41999b488e43799d@haskell.org> Message-ID: <062.fc4b122e4bd9f94bcdbe3b1573e4ea1e@haskell.org> #5757: zero unexpected failures on all tier 1 platforms -------------------------------------+------------------------------------ Reporter: simonmar | Owner: Type: task | Status: new Priority: highest | Milestone: 7.8.1 Component: Test Suite | Version: 7.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #5785 -------------------------------------+------------------------------------ Changes (by carter): * milestone: 7.6.2 => 7.8.1 Comment: BUMP. Once 7.8 hits RC, lets try to AIM for clean validates going forward by default on Master.... anything else creates too many barriers to more folks getting involved in GHC dev, and thats a problem. Also makes is harder to test out GHC features in HEAD. basically: we need to make it more painful to have dirty validates. I think Austin has some testing infrastructure plans that would be in alignment with this goal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 20 08:30:28 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Nov 2013 08:30:28 -0000 Subject: [GHC] #8477: Allow inferring ambiguous types In-Reply-To: <045.eba11f97886c50dcee3d55a438abd62f@haskell.org> References: <045.eba11f97886c50dcee3d55a438abd62f@haskell.org> Message-ID: <060.be44e43b5a2e14ce06dd763631c9496a@haskell.org> #8477: Allow inferring ambiguous types -------------------------------------+------------------------------------ Reporter: aavogt | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 8390 -------------------------------------+------------------------------------ Changes (by simonpj): * cc: goldfire, diatchki (added) Comment: Richard Eisenberg (goldfire) writes: I'm here at MSR Redmond talking with Nik and Daan about type inference, among other things. We're wondering about ambiguity checks. When we type check {{{ > showRead = show . read }}} (with `-XAllowAmbiguousTypes`) we are told that term is ill-typed because of a failed constraint due to an ambiguous type variable. But, there is a perfectly good type for this: `(Show a, Read a) => String -> String`. This type is, of course, ambiguous, but I thought we wanted to ''allow'' ambiguous types. Our only theory is that GHC has to check the RHS ''twice'' -- once to infer a type and then once to check that it has the inferred type. It is during this second pass that we discover that the inferred type is no good. What has intrigued us is that {{{ > showRead :: forall a. (Show a, Read a) => String -> String > showRead = show . (read :: String -> a) }}} works just fine (with `-XAllowAmbiguousTypes` and `-XScopedTypeVariables`). So, the analysis is ''not'' just looking at the types; it has to be examining the RHS also. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 20 08:39:12 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Nov 2013 08:39:12 -0000 Subject: [GHC] #8543: `Coercible` ought to work for recursive newtypes Message-ID: <046.0ae427f4369a924f07f9fbb9d8d97990@haskell.org> #8543: `Coercible` ought to work for recursive newtypes -------------------------------------------+------------------------------- Reporter: nomeata | Owner: nomeata Type: task | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: #8503 | Test Case: | Blocking: -------------------------------------------+------------------------------- At least on a best-effort basis. The approach (developed by SPJ and me) is to A) Add a feature to the constraint solver to prevent recursive dictionaries for specially marked instances (for now only used for `Coercible`). Rationale: Such dictionaries (which are fine for most classes like `Show`) would make `coerce` diverge. Implementation: Use the depth counter and do not use lower depths to solver constraints with a higher depth. This is of course a very conservative approximation, but should be sufficient. B) Use the regular constraint depth bound to prevent looping at compile time. In order for that to be more useful, count constraint solving and type function resolving separately. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 20 08:39:35 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Nov 2013 08:39:35 -0000 Subject: [GHC] #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough In-Reply-To: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> References: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> Message-ID: <062.2c2c47e68a69ef34da9fbd4c1d04c63a@haskell.org> #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8541 -------------------------------------+------------------------------------ Comment (by nomeata): Breaking out the individual problems into separate tickets: #8543 for recursive newtypes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 20 08:40:23 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Nov 2013 08:40:23 -0000 Subject: [GHC] #8477: Allow inferring ambiguous types In-Reply-To: <045.eba11f97886c50dcee3d55a438abd62f@haskell.org> References: <045.eba11f97886c50dcee3d55a438abd62f@haskell.org> Message-ID: <060.588d8c6dc647260e84473f5411ea0771@haskell.org> #8477: Allow inferring ambiguous types -------------------------------------+------------------------------------ Reporter: aavogt | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 8390 -------------------------------------+------------------------------------ Comment (by simonpj): Like I say, I'm doubtful about allowing functions to get ambiguous ''inferred'' types, because that plants hidden land mines for those who call the function. If you give a signature, you are explicitly asking for this particular land mine. If you want it to have an ambiguous type, say so! It's like a per-declaration pragma, if you like. It would not be impossible to make `-XAllowAmbiguousTypes` work for inferred types, but actually it would not be entirely straightforward; see `Note [Impedence matching]` in `TcBinds`. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 20 08:51:12 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Nov 2013 08:51:12 -0000 Subject: [GHC] #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough In-Reply-To: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> References: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> Message-ID: <062.113e4e50fa8223c4a1f43961fe40b712@haskell.org> #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8541 -------------------------------------+------------------------------------ Comment (by simonpj): For the recurisve-newtype problem (ie the main topic of this ticket, now that we have moved polykinded `Coercible` to #8541), the approach (developed by Joachim and me) is to A) Add a feature to the constraint solver to prevent recursive dictionaries for specially marked instances (for now only used for Coercible). Rationale: Such dictionaries (which are fine for most classes like Show) would make coerce diverge. Implementation: Use the depth counter and do not use lower depths to solver constraints with a higher depth. This is of course a very conservative approximation, but should be sufficient. B) Use the regular constraint depth bound to prevent looping at compile time. In order for that to be more useful, count constraint solving and type function resolving separately. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 20 08:52:21 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Nov 2013 08:52:21 -0000 Subject: [GHC] #8543: `Coercible` ought to work for recursive newtypes In-Reply-To: <046.0ae427f4369a924f07f9fbb9d8d97990@haskell.org> References: <046.0ae427f4369a924f07f9fbb9d8d97990@haskell.org> Message-ID: <061.22c67a95c64941032076a171c87e69f8@haskell.org> #8543: `Coercible` ought to work for recursive newtypes --------------------------------------------+------------------------------ Reporter: nomeata | Owner: nomeata Type: task | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.6.3 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8503 --------------------------------------------+------------------------------ Changes (by simonpj): * cc: dimitris@?, sweirich@?, diatchki (added) * status: new => closed * resolution: => duplicate Old description: > At least on a best-effort basis. > > The approach (developed by SPJ and me) is to > > A) Add a feature to the constraint solver to prevent recursive > dictionaries for specially marked instances (for now only used for > `Coercible`). Rationale: Such dictionaries (which are fine for most > classes like `Show`) would make `coerce` diverge. Implementation: Use the > depth counter and do not use lower depths to solver constraints with a > higher depth. This is of course a very conservative approximation, but > should be sufficient. > > B) Use the regular constraint depth bound to prevent looping at compile > time. In order for that to be more useful, count constraint solving and > type function resolving separately. New description: The approach (developed by SPJ and me) is to A) Add a feature to the constraint solver to prevent recursive dictionaries for specially marked instances (for now only used for `Coercible`). Rationale: Such dictionaries (which are fine for most classes like `Show`) would make `coerce` diverge. Implementation: Use the depth counter and do not use lower depths to solver constraints with a higher depth. This is of course a very conservative approximation, but should be sufficient. B) Use the regular constraint depth bound to prevent looping at compile time. In order for that to be more useful, count constraint solving and type function resolving separately. -- Comment: I think it's better to keep this ticket with #8503, which has all the context. I've moved the comment there. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 20 08:52:52 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Nov 2013 08:52:52 -0000 Subject: [GHC] #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough In-Reply-To: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> References: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> Message-ID: <062.bb92506dc37e4abbc3f88c977f0cca1c@haskell.org> #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8541 -------------------------------------+------------------------------------ Comment (by nomeata): Hehe, we got a race condition (see #8543), but thanks to purity, the result is equivalent :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 20 08:57:09 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Nov 2013 08:57:09 -0000 Subject: [GHC] Batch modify: #8070, #8065, #8121, #8251 Message-ID: <20131120085709.4844524069@ghc.haskell.org> Batch modification to #8070, #8065, #8121, #8251 by hvr: component to Trac & Git -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 20 09:01:54 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Nov 2013 09:01:54 -0000 Subject: [GHC] #8065: Set trac up for multiple git repos In-Reply-To: <044.b22f127dd0360c181d10170e3613feda@haskell.org> References: <044.b22f127dd0360c181d10170e3613feda@haskell.org> Message-ID: <059.b15600a9d90973d43c9800fe1b02fe1e@haskell.org> #8065: Set trac up for multiple git repos -------------------------------------+------------------------------------ Reporter: igloo | Owner: hvr Type: task | Status: closed Priority: normal | Milestone: Component: Trac & Git | Version: 7.6.3 Resolution: fixed | Keywords: trac git admin Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by hvr): * status: new => closed * resolution: => fixed Comment: this has been long resolved -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 20 09:04:34 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Nov 2013 09:04:34 -0000 Subject: [GHC] #8544: Auto-Reference ticket-related branches in tickets Message-ID: <046.985a94d43cb4fdc4ae80a7a56866d975@haskell.org> #8544: Auto-Reference ticket-related branches in tickets ------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- This has two possible implementations (and both are useful and can complement each other): * Add a new field to the description ?Related branch?. If for ticket #1234 there is a branch matching `T1234` (usually something like `wip/T1234`), link it from there. * When such a branch is created or deleted, post a message to the ticket. This way subscribers know about a possible ongoing implementation, and can review it. These should link somewhere I believe `https://ghc.haskell.org/trac/ghc/log/ghc?rev=` is the most useful link. If the link is part of the ?branch created? message, it will become dangling after the branch is closed (presumably because the feature was merged; then the actually commits, if they reference the bug, will be auto-linked). I don?t think this is a problem. But if that is a problem, only put the link in the ?Related branches? field, and clear it when the branch is deleted. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 20 09:07:06 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Nov 2013 09:07:06 -0000 Subject: [GHC] #8545: Reorganize Git repositories Message-ID: <042.ff58f710763777250f3a6776932361cb@haskell.org> #8545: Reorganize Git repositories ------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Trac & Git | Version: Keywords: git | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8251 | ------------------------------------+------------------------------------- This is to track the progress for the GitRepoReorganization which is to be tackled post-7.8 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 20 09:38:40 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Nov 2013 09:38:40 -0000 Subject: [GHC] #8541: Coercible should be higher-kinded In-Reply-To: <046.fae54951872f95e2ddf78ecfc5d15947@haskell.org> References: <046.fae54951872f95e2ddf78ecfc5d15947@haskell.org> Message-ID: <061.b8028665dc4cf080723e360f7b44f07f@haskell.org> #8541: Coercible should be higher-kinded -------------------------------------------------+------------------------- Reporter: nomeata | Owner: Type: task | nomeata Priority: normal | Status: patch Component: Compiler | Milestone: Resolution: | Version: 7.6.3 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: TcCoercible, | Unknown/Multiple TcCoercibleFail3 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by Joachim Breitner ): In [changeset:"bbfaff2fa89b21bee058af7e6e6ddd66524524d0/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="bbfaff2fa89b21bee058af7e6e6ddd66524524d0" Add examples from #8541 to testsuite }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 20 09:38:41 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Nov 2013 09:38:41 -0000 Subject: [GHC] #8541: Coercible should be higher-kinded In-Reply-To: <046.fae54951872f95e2ddf78ecfc5d15947@haskell.org> References: <046.fae54951872f95e2ddf78ecfc5d15947@haskell.org> Message-ID: <061.1cbc8a52a5f17530ac0fbaa41277f346@haskell.org> #8541: Coercible should be higher-kinded -------------------------------------------------+------------------------- Reporter: nomeata | Owner: Type: task | nomeata Priority: normal | Status: patch Component: Compiler | Milestone: Resolution: | Version: 7.6.3 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: TcCoercible, | Unknown/Multiple TcCoercibleFail3 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by Joachim Breitner ): In [changeset:"90554a88bee5b492b4d4625ef30b23b9a7915347/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="90554a88bee5b492b4d4625ef30b23b9a7915347" Test case for undersaturated newtype in Coercions This is related to #8541. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 20 09:38:50 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Nov 2013 09:38:50 -0000 Subject: [GHC] #8541: Coercible should be higher-kinded In-Reply-To: <046.fae54951872f95e2ddf78ecfc5d15947@haskell.org> References: <046.fae54951872f95e2ddf78ecfc5d15947@haskell.org> Message-ID: <061.1653a0c093001724e478799f85780034@haskell.org> #8541: Coercible should be higher-kinded -------------------------------------------------+------------------------- Reporter: nomeata | Owner: Type: task | nomeata Priority: normal | Status: patch Component: Compiler | Milestone: Resolution: | Version: 7.6.3 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: TcCoercible, | Unknown/Multiple TcCoercibleFail3 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by Joachim Breitner ): In [changeset:"976a1087ae75accb4ad9d869d14641b2581c1606/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="976a1087ae75accb4ad9d869d14641b2581c1606" Make Coercible higher-kinded This implements #8541. The changes are fully straight forward and work nicely for the examples from the ticket; this is mostly due to the existing code not checking for saturation and kindness. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 20 09:39:42 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Nov 2013 09:39:42 -0000 Subject: [GHC] #8541: Coercible should be higher-kinded In-Reply-To: <046.fae54951872f95e2ddf78ecfc5d15947@haskell.org> References: <046.fae54951872f95e2ddf78ecfc5d15947@haskell.org> Message-ID: <061.26a5390cca8d17d3b86c1df09ba58dc2@haskell.org> #8541: Coercible should be higher-kinded -------------------------------------------------+------------------------- Reporter: nomeata | Owner: Type: task | nomeata Priority: normal | Status: Component: Compiler | closed Resolution: fixed | Milestone: Operating System: Unknown/Multiple | Version: 7.6.3 Type of failure: None/Unknown | Keywords: Test Case: TcCoercible, | Architecture: TcCoercibleFail3 | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by nomeata): * status: patch => closed * resolution: => fixed Comment: This has hit master now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 20 10:08:39 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Nov 2013 10:08:39 -0000 Subject: [GHC] #5395: Context reduction stack overflow without undecidable instances In-Reply-To: <044.cc587d7f60fab1552eaf50eae3520e7a@haskell.org> References: <044.cc587d7f60fab1552eaf50eae3520e7a@haskell.org> Message-ID: <059.7349ffa6964b173a7078ab3f5a7c5f71@haskell.org> #5395: Context reduction stack overflow without undecidable instances -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.0.4 Resolution: | Keywords: type family, Operating System: Unknown/Multiple | termination Type of failure: GHC rejects | Architecture: Unknown/Multiple valid program | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by nomeata): * status: closed => new * difficulty: => Unknown * resolution: fixed => Comment: I am just implementing separate counters for type family applications and constraints solving. Should I change the constraint limit back to `20` then, and leave the type family application limit at `200`? Or even higher? (Reopening as some discussion is required.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 20 10:12:13 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Nov 2013 10:12:13 -0000 Subject: [GHC] #5395: Context reduction stack overflow without undecidable instances In-Reply-To: <044.cc587d7f60fab1552eaf50eae3520e7a@haskell.org> References: <044.cc587d7f60fab1552eaf50eae3520e7a@haskell.org> Message-ID: <059.8969593cee05c2c518750bb968df93ec@haskell.org> #5395: Context reduction stack overflow without undecidable instances -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.0.4 Resolution: | Keywords: type family, Operating System: Unknown/Multiple | termination Type of failure: GHC rejects | Architecture: Unknown/Multiple valid program | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by nomeata): BTW, the user guide still says the default is 20: http://www.haskell.org/ghc/docs/7.6.3/html/users_guide/flag- reference.html#idp39856880 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 20 10:29:57 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Nov 2013 10:29:57 -0000 Subject: [GHC] #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough In-Reply-To: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> References: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> Message-ID: <062.a892921eddbb62d07baaafa47ee97717@haskell.org> #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8541 -------------------------------------+------------------------------------ Comment (by nomeata): As a first step, I implemented separate depth counters for regular constraints and type function application. User-visible changes: Flag `-ftype-function-stack`, in addition to `-fcontext-stack`. Feel free to bikeshed you think the name is inappropriate. The defaults for these values are discussed in #5395 (current 200 resp. 20). See http://git.haskell.org/ghc.git/shortlog/refs/heads/wip/T8503 for my work in progress, and http://git.haskell.org/testsuite.git/shortlog/refs/heads/wip/T8503 for the corresponding test suite updates. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 20 13:21:20 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Nov 2013 13:21:20 -0000 Subject: [GHC] #8497: clang/wrapper cannot build GHC head with integer-gmp on Mavericks In-Reply-To: <052.a945a4fdb4d0e9bf62bd4d9ed8afe8eb@haskell.org> References: <052.a945a4fdb4d0e9bf62bd4d9ed8afe8eb@haskell.org> Message-ID: <067.d54ac0cde293b929bcbe7f62282d2ff8@haskell.org> #8497: clang/wrapper cannot build GHC head with integer-gmp on Mavericks ----------------------------------------+---------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: clang Operating System: MacOS X | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by kazu-yamamoto): OK. I understand the source of this problem. On Mavericks, "/usr/bin/gcc" is a wrapper for clang: {{{ % /usr/bin/gcc --version Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) Target: x86_64-apple-darwin13.0.0 Thread model: posix }}} With this gcc, "libraries/integer-gmp/gmp/gmpbuild/configure" fails. If we can pass CC=clang to this configure, it works. To prove this, I modified "libraries/integer-gmp/gmp/ghc.mk" to hard-code "CC=clang". With this hack, I can build GHC head with integer-gmp on Mavericks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 20 13:24:09 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Nov 2013 13:24:09 -0000 Subject: [GHC] #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough In-Reply-To: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> References: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> Message-ID: <062.2059eb84b337ba4cb775a68a67d008ad@haskell.org> #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8541 -------------------------------------+------------------------------------ Comment (by nomeata): I have something that is roughly working, enough to notice problems. While it successfully prevents `Coercible Fix (Either Int)` from looping or generating recursive dictionaries, it does not help a lot against {{{ newtype Void a = Void (Void (a,a)) foo5 = coerce :: Void () -> () }}} Even with a depth of 20, this filly up my memory quickly, especially trying to print the final constraint. Do we have to live with the fact that there will likely always be ways to make the compiler use too many resources? Or should coercing recursive newtypes require `UndecidableInstances` to be enabled? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 20 14:06:47 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Nov 2013 14:06:47 -0000 Subject: [GHC] #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough In-Reply-To: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> References: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> Message-ID: <062.a138978dd3bb2833a3ba0a640ad0d82d@haskell.org> #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8541 -------------------------------------+------------------------------------ Comment (by simonpj): There are plenty of other ways to construct exponentially-sized types (even in H-M),so I don't think we should worry here. Remember too that type functions mean that the entire notion of a "recursive newtype" is suspect. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 20 14:12:26 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Nov 2013 14:12:26 -0000 Subject: [GHC] #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough In-Reply-To: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> References: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> Message-ID: <062.e5c31a7abd9a308d4fb7e5f435763b8a@haskell.org> #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8541 -------------------------------------+------------------------------------ Comment (by nomeata): Got that code in a working form. I don?t claim to know the solver well enough to be completely certain that there is not a way left to create a recursive dictionary, but at least the examples that I tried worked. Commits 6f5c183cb798a5d5e1011417f1f211834e4e9215 (GHC) and ec83ce7530af5474a3ad49d7120913c7f22266f0 (testsuite); for convenience, here is the note describing the design: {{{ Note [Preventing recursive dictionaries] We have some classes where it is not very useful to build recursive dictionaries (Coercible, at the moment). So we need the constraint solver to prevent that. We conservativey ensure this property using the subgoal depth of the constraints: When solving a Coercible constraint at depth d, we do not consider evicence from a depth <= d as suitable. Therefore we need to record the minimum depth allowed to solve a CtWanted. This is done in the SubGoalDepth field of CtWanted. Most code now uses mkCtWanted, which initializes it to initialSubGoalDepth (i.e. 0); but when requesting a Coercible instance (requestCoercible in TcInteract), we bump the current depth by one and use that. There are two spots where wanted contraints attempted to be solved using existing constraints; doTopReactDict in TcInteract (in the general solver) and newWantedEvVarNonrec (only used by requestCoercible) in TcSMonad. Both use ctEvCheckDepth to make the check. That function ensures that a Given constraint can always be used to solve a goal (i.e. they are at depth infinity, for our purposes) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 20 15:47:36 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Nov 2013 15:47:36 -0000 Subject: [GHC] #6056: INLINABLE pragma prevents worker-wrapper to happen. In-Reply-To: <044.48485356203668916cbd990ce18921d0@haskell.org> References: <044.48485356203668916cbd990ce18921d0@haskell.org> Message-ID: <059.8f8ef1325ad2755be631681acb4cd29a@haskell.org> #6056: INLINABLE pragma prevents worker-wrapper to happen. --------------------------------------------+------------------------------ Reporter: milan | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonpj): I agree that it's surprising and undesirable. The reason it happens is this. GHC keeps an "`Unfolding` inside each `Id`: * For INLINEABLE things it is the original user-written RHS * For w/w'd things it is the wrapper function But there's only ''one'' `Unfolding` for each `Id`, so we have to choose. As you point out, that is a pity. Solution is probably to keep two unfoldings, in effect. Thanks for pointing this out so clearly. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 20 17:42:11 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Nov 2013 17:42:11 -0000 Subject: [GHC] #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough In-Reply-To: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> References: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> Message-ID: <062.fe7b2f46c1559a44c603a40611107f8f@haskell.org> #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8541 -------------------------------------+------------------------------------ Comment (by nomeata): I cherry-picked Richard?s implementation of GND via coerce ([https://github.com/goldfirere/ghc/commit/c76fed9a9c6bffc5b0858d39589dabfe93970c3e c76fed]) onto wip/T8503 and GHC compiles (after `make clean`) just fine ? which is great. There are test suite failures, though A lot are performance degrations (some, if they are about the performance of GHC, are to be expected, the Coercible machinery with subsequent simplification is not the fastest code). The others are: {{{ Unexpected failures: codeGen/should_run cgrun068 [exit code non-0] (normal) deriving/should_compile T2856 [exit code non-0] (normal) deriving/should_compile drv015 [exit code non-0] (normal) deriving/should_fail T1496 [stderr mismatch] (normal) deriving/should_fail T2721 [stderr mismatch] (normal) deriving/should_fail T4846 [stderr mismatch] (normal) deriving/should_fail T7148 [stderr mismatch] (normal) deriving/should_fail T7148a [stderr mismatch] (normal) deriving/should_run drvrun019 [exit code non-0] (normal) gadt CasePrune [stderr mismatch] (normal) gadt gadt6 [exit code non-0] (normal) ghci.debugger/scripts print018 [bad stdout] (ghci) indexed-types/should_compile DerivingNewType [exit code non-0] (normal) indexed-types/should_compile IndTypesPerf [bad exit code] (normal) indexed-types/should_compile T2850 [exit code non-0] (normal) indexed-types/should_compile T3423 [exit code non-0] (normal) indexed-types/should_compile T4185 [exit code non-0] (normal) indexed-types/should_compile T5955 [bad exit code] (normal) indexed-types/should_compile T7474 [exit code non-0] (normal) lib/integer integerConstantFolding [bad stderr] (normal) polykinds T7332 [exit code non-0] (normal) roles/should_fail Roles10 [stderr mismatch] (normal) simplCore/should_compile T4203 [exit code non-0] (normal) typecheck/should_compile T3955 [exit code non-0] (normal) typecheck/should_fail T5246 [stderr mismatch] (normal) }}} Of these, there are a few where we get unresolved Coercible instances due to roles (and many of them might be genuine and can probably be marked as expected to fail), but there is also a number of panic and failed assertions. wip/T8503 itself validates, so these were either introduced or triggered by implementing GND via coerce. Probably triggered, given that the GND code now generates mostly straight-forward code. I?ll start looking into some of them tomorrow, but Richard, if you feel like helping debugging them, that would be appreciated. Some of them appear in code that I do know know much about, such as module interfaces. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 20 21:08:54 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Nov 2013 21:08:54 -0000 Subject: [GHC] #2301: Proper handling of SIGINT/SIGQUIT In-Reply-To: <045.f06a53427920f75d02000e2372e27573@haskell.org> References: <045.f06a53427920f75d02000e2372e27573@haskell.org> Message-ID: <060.6f6a9ae0dc8f0755dd48bb02a6243f8a@haskell.org> #2301: Proper handling of SIGINT/SIGQUIT -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: | Version: 6.12.3 libraries/process | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: POSIX | Difficulty: Unknown Type of failure: Incorrect result | Blocked By: at runtime | Related Tickets: Test Case: | #3994,#5766,#7229,#4274,#3318,#1619 Blocking: | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"a0467f3ee892f5843c1ba98bcb9630e1e5b4863b/process"]: {{{ #!CommitTicketReference repository="process" revision="a0467f3ee892f5843c1ba98bcb9630e1e5b4863b" Implement delegated control-C handling on Unix (#2301) This is a generalisation of the SIGINT-ignoring that system and rawSystem do, to allow it to be used via the general createProcess. For the gory details of SIGINT handling, see http://www.cons.org/cracauer/sigint.html We implement the 'WCE' method described there. That important feature was only available to system and rawSystem (mirroring the C system() behaviour). These functions are very limited and indeed deprecated, so we need this feature in general. In particular projects like Cabal are suffering because they cannot do this properly (or need horrible workarounds copy and pasting much of System.Process and using System.Process.Internals). The feature is available now via a new delegate_ctlc flag in the CreateProcess options record. The use of signal handlers is still a little hairy, but probably better than before (for situations where there were multiple concurrent calls to system/rawSystem). One thing to note is that waitForProcess and getProcessExitCode can now throw the UserInterrupt exception. This is all documented in the haddock docs (both a short description and also the excruciating details). Authored-by: Duncan Coutts Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 20 21:08:55 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Nov 2013 21:08:55 -0000 Subject: [GHC] #2301: Proper handling of SIGINT/SIGQUIT In-Reply-To: <045.f06a53427920f75d02000e2372e27573@haskell.org> References: <045.f06a53427920f75d02000e2372e27573@haskell.org> Message-ID: <060.1f99228c0629a78be0499726fa924844@haskell.org> #2301: Proper handling of SIGINT/SIGQUIT -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: | Version: 6.12.3 libraries/process | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: POSIX | Difficulty: Unknown Type of failure: Incorrect result | Blocked By: at runtime | Related Tickets: Test Case: | #3994,#5766,#7229,#4274,#3318,#1619 Blocking: | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"1b1f18b89d23094f4411be534c493a0da8aeadb9/process"]: {{{ #!CommitTicketReference repository="process" revision="1b1f18b89d23094f4411be534c493a0da8aeadb9" Add tests for the delegated control-C handling (#2301) Authored-by: Duncan Coutts Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 20 21:08:55 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Nov 2013 21:08:55 -0000 Subject: [GHC] #2301: Proper handling of SIGINT/SIGQUIT In-Reply-To: <045.f06a53427920f75d02000e2372e27573@haskell.org> References: <045.f06a53427920f75d02000e2372e27573@haskell.org> Message-ID: <060.3023e9c5284890cb031f48f4904dda6e@haskell.org> #2301: Proper handling of SIGINT/SIGQUIT -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: | Version: 6.12.3 libraries/process | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: POSIX | Difficulty: Unknown Type of failure: Incorrect result | Blocked By: at runtime | Related Tickets: Test Case: | #3994,#5766,#7229,#4274,#3318,#1619 Blocking: | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"3d8f9bb7f84c1fbb5efa62dd46daae44110ddb18/process"]: {{{ #!CommitTicketReference repository="process" revision="3d8f9bb7f84c1fbb5efa62dd46daae44110ddb18" Rename runGenProcess_ and leave a deprecated stub At least Cabal was using runGenProcess_, and the previous patches addressing #2301 changed its type already. So this adds a deprecated stub with the original type and the real function gets to have a less odd name. Authored-by: Duncan Coutts Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 20 21:08:56 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Nov 2013 21:08:56 -0000 Subject: [GHC] #2233: Overhaul System.Process In-Reply-To: <047.24a366415ff9b59c03e5bf49850898a6@haskell.org> References: <047.24a366415ff9b59c03e5bf49850898a6@haskell.org> Message-ID: <062.1b5dc41f06026c5f1a2b5b9608af9014@haskell.org> #2233: Overhaul System.Process --------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: task | Status: patch Priority: normal | Milestone: _|_ Component: libraries/process | Version: 6.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by Herbert Valerio Riedel ): In [changeset:"d53196e313023ce92a5181074b7bb2ab7d35b5f3/process"]: {{{ #!CommitTicketReference repository="process" revision="d53196e313023ce92a5181074b7bb2ab7d35b5f3" API cleanup with new functions and old "soft" deprecated Add callProcess, callCommand, spawnProcess, spawnCommand as per the design in #2233 (but not relying on any of the SIGCHLD stuff). Move the various pre-createProcess functions to a section at the bottom in the Haddock docs. Don't yet mark anything as deprecated. That can come later. Authored-by: Duncan Coutts Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 20 21:08:56 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Nov 2013 21:08:56 -0000 Subject: [GHC] #2233: Overhaul System.Process In-Reply-To: <047.24a366415ff9b59c03e5bf49850898a6@haskell.org> References: <047.24a366415ff9b59c03e5bf49850898a6@haskell.org> Message-ID: <062.d522c3d22656c4bd68e37ffb8e670594@haskell.org> #2233: Overhaul System.Process --------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: task | Status: patch Priority: normal | Milestone: _|_ Component: libraries/process | Version: 6.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by Herbert Valerio Riedel ): In [changeset:"a2c3294223bf1f5a1887b4f1bb6e1534699f4eba/process"]: {{{ #!CommitTicketReference repository="process" revision="a2c3294223bf1f5a1887b4f1bb6e1534699f4eba" Reorder code sections to be rather clearer And move the deprecated things (as per #2233) to the end, out of the way. Authored-by: Duncan Coutts Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 20 21:08:57 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Nov 2013 21:08:57 -0000 Subject: [GHC] #2233: Overhaul System.Process In-Reply-To: <047.24a366415ff9b59c03e5bf49850898a6@haskell.org> References: <047.24a366415ff9b59c03e5bf49850898a6@haskell.org> Message-ID: <062.14bcbec5461a3530cef3fbe57515d08d@haskell.org> #2233: Overhaul System.Process --------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: task | Status: patch Priority: normal | Milestone: _|_ Component: libraries/process | Version: 6.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by Herbert Valerio Riedel ): In [changeset:"0faf513f7e3667246d40767d25d0871b49d95851/process"]: {{{ #!CommitTicketReference repository="process" revision="0faf513f7e3667246d40767d25d0871b49d95851" Document spawnProcess and spawnCommand (#2233) Authored-by: Duncan Coutts Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 21 04:34:45 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Nov 2013 04:34:45 -0000 Subject: [GHC] #8497: clang/wrapper cannot build GHC head with integer-gmp on Mavericks In-Reply-To: <052.a945a4fdb4d0e9bf62bd4d9ed8afe8eb@haskell.org> References: <052.a945a4fdb4d0e9bf62bd4d9ed8afe8eb@haskell.org> Message-ID: <067.e4e7af56b8dff9f2fe78023c36991c7d@haskell.org> #8497: clang/wrapper cannot build GHC head with integer-gmp on Mavericks ----------------------------------------+---------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: clang Operating System: MacOS X | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by kazu-yamamoto): "ghc-mk-for-clang.patch" solves this problem. This patch checks if "gcc" is real "gcc" or "clang". If "gcc" is "clang", CC=clang is specified to configure. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 21 07:14:20 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Nov 2013 07:14:20 -0000 Subject: [GHC] #8546: Panic during cabal build with profiling enabled. Message-ID: <046.19ad90151657537b62338ee47b7c0085@haskell.org> #8546: Panic during cabal build with profiling enabled. ---------------------------------+--------------------------------------- Reporter: Mokosha | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: cabal sandbox | Operating System: Windows Architecture: x86 | Type of failure: Compile-time crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ---------------------------------+--------------------------------------- I had been recently using cabal-dev for my development work. Someone suggested I switch over to the new cabal 1.18 on #haskell. After doing so, some projects do not seem to build anymore. I'm not an experienced Haskell developer, so I'm not sure how to go about debugging such a problem. I've included the output of the install command. {{{ Pavel at ZOMBIE-POWER ~/Projects/Lambency/src $ cabal install -p Resolving dependencies... Configuring bindings-GLFW-3.0.3.1... Building bindings-GLFW-3.0.3.1... Preprocessing library bindings-GLFW-3.0.3.1... [1 of 1] Compiling Bindings.GLFW ( dist\dist-sandbox- 2b66993e\build\Bindings\GLFW.hs, dist\dist-sandbox- 2b66993e\build\Bindings\GLFW.o ) [1 of 1] Compiling Bindings.GLFW ( dist\dist-sandbox- 2b66993e\build\Bindings\GLFW.hs, dist\dist-sandbox- 2b66993e\build\Bindings\GLFW.p_o ) In-place registering bindings-GLFW-3.0.3.1... Installing library in D:\MinGW\msys\1.0\home\Pavel\Projects\Lambency\build\i386-windows- ghc-7.6.3\bindings-GLFW-3.0.3.1 Registering bindings-GLFW-3.0.3.1... Installed bindings-GLFW-3.0.3.1 Configuring GLFW-b-1.4.1... Building GLFW-b-1.4.1... Preprocessing library GLFW-b-1.4.1... [1 of 3] Compiling Graphics.UI.GLFW.Types ( Graphics\UI\GLFW\Types.hs, dist\dist-sandbox-2b66993e\build\Graphics\UI\GLFW\Types.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package bindings-DSL-1.0.20 ... linking ... done. Loading package bindings-GLFW-3.0.3.1 ... ghc.exe: Unknown PEi386 section name `.drectve' (while processing: D:\MinGW\msys\1.0\home\Pavel\Projects\Lambency\build\i386-windows- ghc-7.6.3\bindings-GLFW-3 .0.3.1\libHSbindings-GLFW-3.0.3.1.a) ghc.exe: panic! (the 'impossible' happened) (GHC version 7.6.3 for i386-unknown-mingw32): loadArchive "D:\\MinGW\\msys\\1.0\\home\\Pavel\\Projects\\Lambency\\build\\i386 -windows-ghc-7.6.3\\bindings-GLFW-3.0.3.1\\libHSbindings-GLFW-3.0.3.1.a": failed Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Failed to install GLFW-b-1.4.1 cabal.exe: Error: some packages failed to install: GLFW-b-1.4.1 failed during the building phase. The exception was: ExitFailure 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 21 07:39:42 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Nov 2013 07:39:42 -0000 Subject: [GHC] #8546: Panic during cabal build with profiling enabled. In-Reply-To: <046.19ad90151657537b62338ee47b7c0085@haskell.org> References: <046.19ad90151657537b62338ee47b7c0085@haskell.org> Message-ID: <061.c00c6bdd71469ca5c4c79a2b98c294f1@haskell.org> #8546: Panic during cabal build with profiling enabled. ---------------------------------------+--------------------------------- Reporter: Mokosha | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: duplicate | Keywords: cabal sandbox Operating System: Windows | Architecture: x86 Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 7056 ---------------------------------------+--------------------------------- Changes (by Mokosha): * status: new => closed * resolution: => duplicate * related: => 7056 Comment: Seems to be a duplicate of bug 7056 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 21 09:05:37 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Nov 2013 09:05:37 -0000 Subject: [GHC] #8547: Data.Vector.foldl' hangs GHC indefinitely with -O2 Message-ID: <048.f5ac83ba4b392e779ba6c84f76281ee2@haskell.org> #8547: Data.Vector.foldl' hangs GHC indefinitely with -O2 -----------------------------------+--------------------------------------- Reporter: blitzcode | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.6.3 Keywords: hang vector | Operating System: Unknown/Multiple fold' | Type of failure: Compile-time crash Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- Running 'ghc -O2 -fforce-recomp -c Bug.hs' on the following {{{#!haskell module Bug where import qualified Data.Vector as V data Tree = Empty | Node !(V.Vector Tree) f :: k -> Tree -> Tree f k' (Node ch) = head $ V.foldl' (\u t' -> case t' of Empty -> u; _ -> t' : u) [] ch }}} will hang forever (or at least >5m). Builds fine with -O1 / V.foldl. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 21 09:20:50 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Nov 2013 09:20:50 -0000 Subject: [GHC] #2301: Proper handling of SIGINT/SIGQUIT In-Reply-To: <045.f06a53427920f75d02000e2372e27573@haskell.org> References: <045.f06a53427920f75d02000e2372e27573@haskell.org> Message-ID: <060.03d6ed696f845e016fa5bdba25ce26c4@haskell.org> #2301: Proper handling of SIGINT/SIGQUIT -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: | Version: 6.12.3 libraries/process | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: POSIX | Difficulty: Unknown Type of failure: Incorrect result | Blocked By: at runtime | Related Tickets: Test Case: | #3994,#5766,#7229,#4274,#3318,#1619 Blocking: | -------------------------------------+------------------------------------- Comment (by simonmar): I think you're absolutely right to throw `UserInterrupt` locally. The only question is what to do if it propagates to the top of a `forkIO` thread. I think it would be good to note in the docs that `UserInterrupt` only causes the process to die if it propagates to the top of the main thread, so if this is a child thread you need to arrange to propagate it to the parent, say by using `async` instead of raw `forkIO`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 21 09:25:57 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Nov 2013 09:25:57 -0000 Subject: [GHC] #2233: Overhaul System.Process In-Reply-To: <047.24a366415ff9b59c03e5bf49850898a6@haskell.org> References: <047.24a366415ff9b59c03e5bf49850898a6@haskell.org> Message-ID: <062.b5c9817a18fdbc95d1c28ddbb98f7f42@haskell.org> #2233: Overhaul System.Process --------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: task | Status: patch Priority: normal | Milestone: _|_ Component: libraries/process | Version: 6.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by simonmar): Looks great, thanks for doing this! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 21 09:27:07 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Nov 2013 09:27:07 -0000 Subject: [GHC] #8548: Coercible does not resolve type family application Message-ID: <046.8a91ee19cb9fa713b4f1e9492cfc9689@haskell.org> #8548: Coercible does not resolve type family application -------------------------------------------+------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: #8503 | Test Case: | Blocking: -------------------------------------------+------------------------------- With GND implemented using `Coercible` (See #8503) the test for #4185 fails. A minimal example is: {{{ {-# LANGUAGE TypeFamilies #-} module CoerceNewtypeFamily where import GHC.Exts data family Foo k newtype instance Foo Int = FooInt Int x :: Foo Int -> Int x = coerce }}} yielding {{{ [1 of 1] Compiling CoerceNewtypeFamily ( CoerceNewtypeFamily.hs, CoerceNewtypeFamily.o ) CoerceNewtypeFamily.hs:11:5: No instance for (Coercible (Foo Int) Int) because ?Foo Int? and ?Int? are different types. arising from a use of ?coerce? In the expression: coerce In an equation for ?x?: x = coerce }}} I guess the `Coercible` finding code needs to simply type family equations if possible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 21 09:27:40 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Nov 2013 09:27:40 -0000 Subject: [GHC] #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough In-Reply-To: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> References: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> Message-ID: <062.9d0bfc5ad30228cd4b11f6c5e1589fa4@haskell.org> #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 8548 Blocking: | Related Tickets: #8541 -------------------------------------+------------------------------------ Changes (by nomeata): * blockedby: => 8548 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 21 09:36:45 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Nov 2013 09:36:45 -0000 Subject: [GHC] #2850: GeneralizedNewtypeDeriving + TypeFamilies doesn't work In-Reply-To: <042.bfabde61c4aa31a17887ff9436d679ab@haskell.org> References: <042.bfabde61c4aa31a17887ff9436d679ab@haskell.org> Message-ID: <057.20d7aae86e399278470d406246eaa13e@haskell.org> #2850: GeneralizedNewtypeDeriving + TypeFamilies doesn't work -------------------------------------------------+------------------------- Reporter: ajd | Owner: Type: feature request | Status: Priority: normal | closed Component: Compiler | Milestone: 6.12 Resolution: fixed | branch Operating System: Unknown/Multiple | Version: Type of failure: None/Unknown | 6.10.1 Test Case: | Keywords: indexed_types/should_compile/T2850 | Architecture: Blocking: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by nomeata): * failure: => None/Unknown Comment: If we implement GND via `Coercible`, this will no longer work: Coercing `bar :: B Bool -> B Bool` to the instance for `Int` will print {{{ No instance for (GHC.Types.Coercible (B Bool) (B Int)) because the first type argument of ?B? has role Nominal, but the arguments ?Bool? and ?Int? differ arising from a use of ?GHC.Prim.coerce? }}} Richard, as the expert on roles, is that avoidable? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 21 09:42:31 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Nov 2013 09:42:31 -0000 Subject: [GHC] #8548: Coercible does not resolve type family application In-Reply-To: <046.8a91ee19cb9fa713b4f1e9492cfc9689@haskell.org> References: <046.8a91ee19cb9fa713b4f1e9492cfc9689@haskell.org> Message-ID: <061.055c45788d2599e179fe48b7d3e51cc3@haskell.org> #8548: Coercible does not resolve type family application --------------------------------------------+------------------------------ Reporter: nomeata | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: 8503 | Blocked By: | Related Tickets: #8503 --------------------------------------------+------------------------------ Comment (by nomeata): (Also breaks the test case for #5955, #2856 and test case `DerivingNewType`) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 21 09:46:21 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Nov 2013 09:46:21 -0000 Subject: [GHC] #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough In-Reply-To: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> References: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> Message-ID: <062.652d9574c51f403f6e7f16c98f78aae1@haskell.org> #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 8548 Blocking: | Related Tickets: #8541 -------------------------------------+------------------------------------ Comment (by nomeata): Is it hijacking this ticket to discuss the impact of GND-via-coerce here? Anyways, feature request #2850 will be broken if we do GND-via-coerce. Four tickets are broken because of #8548 (Coercible not working for `newtype instance` yet), these will be fixable. The remaining ones (`TEST="print018 cgrun068 T4203 drvrun019 T3955 T7474 T3423 IndTypesPerf T5246 integerConstantFolding gadt6 T7332 drv015"`) cause panics, looking into them now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 21 10:49:30 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Nov 2013 10:49:30 -0000 Subject: [GHC] #8549: GHCI incorrectly link symbols defined with foreign import ccall Message-ID: <045.5f1cfb88fc2e3dd9c933ec8683824602@haskell.org> #8549: GHCI incorrectly link symbols defined with foreign import ccall -------------------------+------------------------------------------------- Reporter: | Owner: qnikst | Status: new Type: bug | Milestone: Priority: | Version: 7.6.3 normal | Operating System: Unknown/Multiple Component: GHCi | Type of failure: GHCi crash Keywords: | Test Case: Architecture: | https://gist.github.com/qnikst/324a66914b3aba878be5 Unknown/Multiple | Blocking: Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- I have a problem that ghci when loads modules that uses external symbols incorrectly links them, the problem is not reproducible if I'm compiling executable or load modules with :load command. As a result every Pointer value is equivalent to constant 0x0000fffffff225ff. A minimal example is in attached link, it contains a small package and description how to reproduce a bug. Problem is also reproduces on the ghc-HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 21 11:03:12 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Nov 2013 11:03:12 -0000 Subject: [GHC] #8547: Data.Vector.foldl' hangs GHC indefinitely with -O2 In-Reply-To: <048.f5ac83ba4b392e779ba6c84f76281ee2@haskell.org> References: <048.f5ac83ba4b392e779ba6c84f76281ee2@haskell.org> Message-ID: <063.48978c19c95d86cd1634e0b738023add@haskell.org> #8547: Data.Vector.foldl' hangs GHC indefinitely with -O2 ---------------------------------------+----------------------------------- Reporter: blitzcode | Owner: Type: bug | Status: closed Priority: high | Milestone: Component: Compiler | Version: 7.6.3 Resolution: duplicate | Keywords: hang vector Operating System: Unknown/Multiple | fold' Type of failure: Compile-time crash | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Changes (by monoidal): * status: new => closed * resolution: => duplicate Comment: This is fixed in HEAD (#5550). Thanks for the report. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 21 11:29:10 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Nov 2013 11:29:10 -0000 Subject: [GHC] #8549: GHCI incorrectly link symbols defined with foreign import ccall In-Reply-To: <045.5f1cfb88fc2e3dd9c933ec8683824602@haskell.org> References: <045.5f1cfb88fc2e3dd9c933ec8683824602@haskell.org> Message-ID: <060.8708060cb023adf29c6068b2d1e0f16b@haskell.org> #8549: GHCI incorrectly link symbols defined with foreign import ccall -------------------------------------------------+------------------------- Reporter: qnikst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHCi crash | Unknown/Multiple Test Case: | Difficulty: https://gist.github.com/qnikst/324a66914b3aba878be5| Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by hvr): I assume this is on Linux/x86_64? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 21 12:08:55 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Nov 2013 12:08:55 -0000 Subject: [GHC] #8549: GHCI incorrectly link symbols defined with foreign import ccall In-Reply-To: <045.5f1cfb88fc2e3dd9c933ec8683824602@haskell.org> References: <045.5f1cfb88fc2e3dd9c933ec8683824602@haskell.org> Message-ID: <060.041cd9586d6352fe2b8080950ca42fc4@haskell.org> #8549: GHCI incorrectly link symbols defined with foreign import ccall -------------------------------------------------+------------------------- Reporter: qnikst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHCi crash | Unknown/Multiple Test Case: | Difficulty: https://gist.github.com/qnikst/324a66914b3aba878be5| Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by qnikst): Replying to [comment:1 hvr]: > I assume this is on Linux/x86_64? Yes. I've tested it on Linux/x86 before and it also failed, I'll update information as soon as I'll be able to run it on that box again. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 21 12:21:46 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Nov 2013 12:21:46 -0000 Subject: [GHC] #8550: GHC builds recursive coerctions when using recursive type families Message-ID: <046.8d217bb04ee5a5aa0080a8650276d1a6@haskell.org> #8550: GHC builds recursive coerctions when using recursive type families -------------------------------------------+------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- Consider {{{ {-# LANGUAGE TypeFamilies, GADTs, UndecidableInstances #-} type family F a type instance F () = F () data A where A :: F () ~ () => A x :: A x = A }}} On GHC 7.6.3 it yields a context reduction stack overflow (despite F () ~ () being put into the ?solved funeqs? list). In HEAD, a recursive dictionary is built, but then detected: {{{ [1 of 1] Compiling Foo ( Foo.hs, Foo.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20131108 for x86_64-unknown-linux): Cycle in coercion bindings [[cobox_ayX{v} [lid] = CO main:Foo.TFCo:R:F(){tc rob}[0] ; cobox_ayZ{v} [lid], cobox_ayZ{v} [lid] = CO cobox_ayX{v} [lid] ; cobox_az0{v} [lid]]] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Either this panic needs to be turned into an error, or we need to prevent recursive dictionaries for when solving funeqs (similar to how we do it for `Coercible`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 21 12:22:03 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Nov 2013 12:22:03 -0000 Subject: [GHC] #8550: GHC builds recursive coerctions when using recursive type families In-Reply-To: <046.8d217bb04ee5a5aa0080a8650276d1a6@haskell.org> References: <046.8d217bb04ee5a5aa0080a8650276d1a6@haskell.org> Message-ID: <061.a44504f7efaac7171d32bf6cbcf2c965@haskell.org> #8550: GHC builds recursive coerctions when using recursive type families --------------------------------------------+------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by nomeata): * version: 7.6.3 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 21 12:54:32 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Nov 2013 12:54:32 -0000 Subject: [GHC] #8551: Fix formatting in docs at one place Message-ID: <047.a48642087a85ff970468230bf8e092a2@haskell.org> #8551: Fix formatting in docs at one place ------------------------------------+------------------------------------- Reporter: Tarrasch | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- See to-be-attached patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 21 12:57:06 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Nov 2013 12:57:06 -0000 Subject: [GHC] #8551: Fix formatting in docs at one place In-Reply-To: <047.a48642087a85ff970468230bf8e092a2@haskell.org> References: <047.a48642087a85ff970468230bf8e092a2@haskell.org> Message-ID: <062.90983e9d30017f2a9ac0f152885b2f2b@haskell.org> #8551: Fix formatting in docs at one place -------------------------------------+------------------------------------ Reporter: Tarrasch | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Tarrasch): If there's anything else I can do to make it easier for you to apply patches, please let me know. :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 21 13:14:10 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Nov 2013 13:14:10 -0000 Subject: [GHC] #8551: Fix formatting in docs at one place In-Reply-To: <047.a48642087a85ff970468230bf8e092a2@haskell.org> References: <047.a48642087a85ff970468230bf8e092a2@haskell.org> Message-ID: <062.8579c6574351cfe28fd48d35a9893158@haskell.org> #8551: Fix formatting in docs at one place -------------------------------------+------------------------------------ Reporter: Tarrasch | Owner: Type: task | Status: patch Priority: lowest | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonpj): * status: new => patch Comment: Last step: change to "Please review status"! I've done this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 21 13:15:14 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Nov 2013 13:15:14 -0000 Subject: [GHC] #8552: Rename StgArrWords to StgArrBytes Message-ID: <047.162074162cf551ca6b1ad3c66a412848@haskell.org> #8552: Rename StgArrWords to StgArrBytes ------------------------------------+------------------------------------- Reporter: Tarrasch | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Since #3800, `StgArrWords` contains a certain number of words and not bytes. One can easily forget this and make programming mistakes. For example if you try to store the number of words in the `bytes` field, the garbage collector won't honor your decision. (I learned the hard way :)) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 21 13:21:14 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Nov 2013 13:21:14 -0000 Subject: [GHC] #8552: Rename StgArrWords to StgArrBytes In-Reply-To: <047.162074162cf551ca6b1ad3c66a412848@haskell.org> References: <047.162074162cf551ca6b1ad3c66a412848@haskell.org> Message-ID: <062.526ce6dc8eb89a70ec777633516be9bc@haskell.org> #8552: Rename StgArrWords to StgArrBytes -------------------------------------+------------------------------------ Reporter: Tarrasch | Owner: Type: task | Status: patch Priority: lowest | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by Tarrasch): * status: new => patch Comment: My attachment just adds a comment about the confusion that can happen. (And have happened :)) I bet somebody have good arguments to not rename this struct, so please comment on this suggestion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 21 14:09:51 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Nov 2013 14:09:51 -0000 Subject: [GHC] #2850: GeneralizedNewtypeDeriving + TypeFamilies doesn't work In-Reply-To: <042.bfabde61c4aa31a17887ff9436d679ab@haskell.org> References: <042.bfabde61c4aa31a17887ff9436d679ab@haskell.org> Message-ID: <057.9c159e1960541c191e2e50e12614242d@haskell.org> #2850: GeneralizedNewtypeDeriving + TypeFamilies doesn't work -------------------------------------------------+------------------------- Reporter: ajd | Owner: Type: feature request | Status: Priority: normal | closed Component: Compiler | Milestone: 6.12 Resolution: fixed | branch Operating System: Unknown/Multiple | Version: Type of failure: None/Unknown | 6.10.1 Test Case: | Keywords: indexed_types/should_compile/T2850 | Architecture: Blocking: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by goldfire): Interesting corner case. Answer: perhaps, but it would take a little more engineering. The problem is that `B`'s role is very rightly nominal. It's perfectly conceivable for `B Age` and `B Int` to be unrelated. But, we still want `B Bool ~R B Int`. The way this might be possible is by using the ''representation'' tycons for data families before doing the `Coercible` stuff. And, it means that these representation tycons would also need to be given appropriate roles. Currently, they're all nominal (see [http://git.haskell.org/ghc.git/blob/HEAD:/compiler/typecheck/TcInstDcls.lhs#l700 the source code]). This all seems quite possible, but as I said, somewhat more engineering to make work. I can take a look at inferring roles for data/newtype instances. (I suppose these means also making role signatures for these forms. Grrrr.....) Do you think it's possible for the `Coercible` stuff to work over representation tycons for data/newtype instances? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 21 14:11:40 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Nov 2013 14:11:40 -0000 Subject: [GHC] #2850: GeneralizedNewtypeDeriving + TypeFamilies doesn't work In-Reply-To: <042.bfabde61c4aa31a17887ff9436d679ab@haskell.org> References: <042.bfabde61c4aa31a17887ff9436d679ab@haskell.org> Message-ID: <057.e8d2a6b4c682da0b65b7d675e6e13f90@haskell.org> #2850: GeneralizedNewtypeDeriving + TypeFamilies doesn't work -------------------------------------------------+------------------------- Reporter: ajd | Owner: Type: feature request | Status: Priority: normal | closed Component: Compiler | Milestone: 6.12 Resolution: fixed | branch Operating System: Unknown/Multiple | Version: Type of failure: None/Unknown | 6.10.1 Test Case: | Keywords: indexed_types/should_compile/T2850 | Architecture: Blocking: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by nomeata): Ok, on second glance this seems to be just another instance of #8548, right? In that case, sorry for the noise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 21 14:12:13 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Nov 2013 14:12:13 -0000 Subject: [GHC] #8548: Coercible does not resolve type family application In-Reply-To: <046.8a91ee19cb9fa713b4f1e9492cfc9689@haskell.org> References: <046.8a91ee19cb9fa713b4f1e9492cfc9689@haskell.org> Message-ID: <061.942d2818b375b87e5c48023399b15ad9@haskell.org> #8548: Coercible does not resolve type family application --------------------------------------------+------------------------------ Reporter: nomeata | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: 8503 | Blocked By: | Related Tickets: #8503 --------------------------------------------+------------------------------ Comment (by nomeata): (You can add #2850 to that list, it seems) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 21 14:12:31 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Nov 2013 14:12:31 -0000 Subject: [GHC] #2850: GeneralizedNewtypeDeriving + TypeFamilies doesn't work In-Reply-To: <042.bfabde61c4aa31a17887ff9436d679ab@haskell.org> References: <042.bfabde61c4aa31a17887ff9436d679ab@haskell.org> Message-ID: <057.c31111fa4a7ae1a1790bec720b5165c4@haskell.org> #2850: GeneralizedNewtypeDeriving + TypeFamilies doesn't work -------------------------------------------------+------------------------- Reporter: ajd | Owner: Type: feature request | Status: Priority: normal | closed Component: Compiler | Milestone: 6.12 Resolution: fixed | branch Operating System: Unknown/Multiple | Version: Type of failure: None/Unknown | 6.10.1 Test Case: | Keywords: indexed_types/should_compile/T2850 | Architecture: Blocking: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by simonpj): Correct!! Solve #8548 and you are done. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 21 14:12:34 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Nov 2013 14:12:34 -0000 Subject: [GHC] #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough In-Reply-To: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> References: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> Message-ID: <062.a85f034a9ecddcfc40a62a8e35a512e0@haskell.org> #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 8548 Blocking: | Related Tickets: #8541 -------------------------------------+------------------------------------ Comment (by goldfire): I think the issue with #2850 is fixable. See that ticket. I actually think these knock-on effects of the GND-via-coerce decision are good. They're forcing us to get `Coercible` right! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 21 14:13:24 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Nov 2013 14:13:24 -0000 Subject: [GHC] #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough In-Reply-To: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> References: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> Message-ID: <062.56439efdd39e159885a90a3b393cac1f@haskell.org> #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 8548 Blocking: | Related Tickets: #8541 -------------------------------------+------------------------------------ Comment (by nomeata): Yes, it is a horribly effective testsuite ;-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 21 14:28:42 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Nov 2013 14:28:42 -0000 Subject: [GHC] #2850: GeneralizedNewtypeDeriving + TypeFamilies doesn't work In-Reply-To: <042.bfabde61c4aa31a17887ff9436d679ab@haskell.org> References: <042.bfabde61c4aa31a17887ff9436d679ab@haskell.org> Message-ID: <057.1502a21ff77e1421e9633b44ed9b0a01@haskell.org> #2850: GeneralizedNewtypeDeriving + TypeFamilies doesn't work -------------------------------------------------+------------------------- Reporter: ajd | Owner: Type: feature request | Status: Priority: normal | closed Component: Compiler | Milestone: 6.12 Resolution: fixed | branch Operating System: Unknown/Multiple | Version: Type of failure: None/Unknown | 6.10.1 Test Case: | Keywords: indexed_types/should_compile/T2850 | Architecture: Blocking: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by goldfire): Almost, but not quite, due to the lack of informative roles on data/newtype instance representation tycons. I do think the fix for #8548 would fix the example in this ticket, but not something like {{{ data family D a data instance D (Maybe a) = MkDMaybe a class C (D (Maybe Int)) where ... newtype instance D [a] = MkDList (D (Maybe a)) deriving instance C (D [Age]) }}} That's all rather confusing, but I ''think'' it should work. And it would require informative roles on data/newtype instance representation tycons. These roles are currently all nominal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 21 14:49:14 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Nov 2013 14:49:14 -0000 Subject: [GHC] #2850: GeneralizedNewtypeDeriving + TypeFamilies doesn't work In-Reply-To: <042.bfabde61c4aa31a17887ff9436d679ab@haskell.org> References: <042.bfabde61c4aa31a17887ff9436d679ab@haskell.org> Message-ID: <057.aa71047f25197308a7ef35cbedbc3228@haskell.org> #2850: GeneralizedNewtypeDeriving + TypeFamilies doesn't work -------------------------------------------------+------------------------- Reporter: ajd | Owner: Type: feature request | Status: Priority: normal | closed Component: Compiler | Milestone: 6.12 Resolution: fixed | branch Operating System: Unknown/Multiple | Version: Type of failure: None/Unknown | 6.10.1 Test Case: | Keywords: indexed_types/should_compile/T2850 | Architecture: Blocking: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by simonpj): Richard can you explain in more detail what "doesn't work2 in your example? Without the signatures of the class methods in C it's hard to makes sense of it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 21 16:39:36 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Nov 2013 16:39:36 -0000 Subject: [GHC] #8553: ASSERT failed compiler/typecheck/TcMType.lhs line 809 Message-ID: <046.c98e70d0ceeae727c974fb11a22a1bd7@haskell.org> #8553: ASSERT failed compiler/typecheck/TcMType.lhs line 809 -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.6.3 checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: Compile-time Architecture: Unknown/Multiple | crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- With current master (9c2dade94fae5f4fe19cd972ca1f1049c633e4ed) I get {{{ [1 of 1] Compiling ShouldCompile ( ../ghc/gadt6.hs, ../ghc/gadt6.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20131121 for x86_64-unknown-linux): ASSERT failed! file compiler/typecheck/TcMType.lhs line 809 [W] cobox_aBx{v} [lid] :: t_aBv{tv} [tau[0]] ghc-prim:GHC.Types.~{(w) tc 31Q} t_aBu{tv} [tau[0]] (CIrredEvCan) }}} (And it took me a while to figure out that it was not my code that was introducing the bug.) According to `git log -L 809,809:compiler/typecheck/TcMType.lhs` (a useful feature) the history of the ASSERT is: * SPJ, ?Accommodate Derived constraints in two places?, Sep 17, 8cfbdccb7f8716c2b6b13b3c7884f52b1087d782 * SPJ, ?Fix an ASSERT?, Oct 1 2012, adb6bcb7b85410dd42828a4824962ce9c6e9d667 * SPJ, ?Tidy up and simplify TcMType.zonkFlats?, Sep 17, 2012, bd6b183e092fc7667fc55b3aa15d857f257ec73f -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 21 16:41:59 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Nov 2013 16:41:59 -0000 Subject: [GHC] #8553: ASSERT failed compiler/typecheck/TcMType.lhs line 809 In-Reply-To: <046.c98e70d0ceeae727c974fb11a22a1bd7@haskell.org> References: <046.c98e70d0ceeae727c974fb11a22a1bd7@haskell.org> Message-ID: <061.bc2254bfa8a57feec7eebbda9195452c@haskell.org> #8553: ASSERT failed compiler/typecheck/TcMType.lhs line 809 --------------------------------------------+------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: gadt6 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by nomeata): * testcase: => gadt6 * version: 7.6.3 => 7.7 Comment: Forgot to mention; This occurs when compiling source:testsuite/tests/gadt/gadt6.hs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 21 17:02:58 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Nov 2013 17:02:58 -0000 Subject: [GHC] #8553: ASSERT failed compiler/typecheck/TcMType.lhs line 809 In-Reply-To: <046.c98e70d0ceeae727c974fb11a22a1bd7@haskell.org> References: <046.c98e70d0ceeae727c974fb11a22a1bd7@haskell.org> Message-ID: <061.8d9f946ba43476271358c681d46b4929@haskell.org> #8553: ASSERT failed compiler/typecheck/TcMType.lhs line 809 --------------------------------------------+------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: gadt6 T7474 T5246 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by nomeata): * testcase: gadt6 => gadt6 T7474 T5246 Comment: (This also affects `TEST="gadt6 T7474 T5246"`) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 21 17:29:12 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Nov 2013 17:29:12 -0000 Subject: [GHC] #8554: kindFunResult panic when type checking wrongly-kinded function Message-ID: <054.782fc7d923547f2fd93839409f60d15e@haskell.org> #8554: kindFunResult panic when type checking wrongly-kinded function -------------------------------------+------------------------------------- Reporter: patrick_thomson | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.6.3 checker) | Operating System: MacOS X Keywords: | Type of failure: Compile-time Architecture: x86_64 (amd64) | crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- While working on some writing about recursion schemes and morphisms, I wrote the following well-known catamorphism: {{{ import Control.Arrow newtype Fix f = Fix { unFix :: f (Fix f) } bottomUp f = unFix >>> fmap (bottomUp f) >>> Fix >>> f }}} On a lark, I decided to reverse the direction of the arrows in the above statement and see what the typechecker had to say about it: {{{ nonsense f = unFix <<< fmap (nonsense f) <<< Fix <<< f }}} This function is (I think) not well-kinded, but during type checking (both from ghci and ghc) I get the following error: {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for i386-apple-darwin): kindFunResult <
> Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I am running 32-bit GHC 7.6.3 (from the Haskell Platform) on an x86_64 machine running OS X 10.9. I have attached the output of ghc -v. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 21 18:37:49 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Nov 2013 18:37:49 -0000 Subject: [GHC] #8554: kindFunResult panic when type checking wrongly-kinded function In-Reply-To: <054.782fc7d923547f2fd93839409f60d15e@haskell.org> References: <054.782fc7d923547f2fd93839409f60d15e@haskell.org> Message-ID: <069.06a1b6f5d915c025ca4397683aa68163@haskell.org> #8554: kindFunResult panic when type checking wrongly-kinded function --------------------------------------------+------------------------------ Reporter: patrick_thomson | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.6.3 Resolution: duplicate | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Compile-time crash | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by monoidal): * status: new => closed * resolution: => duplicate Comment: Thanks for the report. This is already fixed in HEAD (#7368 and search Trac for kindFunResult). {{{ B.hs:3:24: Kind incompatibility when matching types: f :: * -> * f (Fix f) :: * Expected type: f0 a -> Fix f Actual type: f0 a -> f0 (f (Fix f)) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 21 22:44:49 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Nov 2013 22:44:49 -0000 Subject: [GHC] #8526: -fforce-recomp does not re-summarise modules In-Reply-To: <044.a874b1b60feee8d3abbe2c98f3ab0e0a@haskell.org> References: <044.a874b1b60feee8d3abbe2c98f3ab0e0a@haskell.org> Message-ID: <059.07419bb7aaace98df5f42f8d8bf84818@haskell.org> #8526: -fforce-recomp does not re-summarise modules -------------------------------------+------------------------------------ Reporter: parcs | Owner: parcs Type: bug | Status: patch Priority: normal | Milestone: Component: Driver | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by thoughtpolice): LGTM Patrick - please commit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 21 23:47:24 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Nov 2013 23:47:24 -0000 Subject: [GHC] #1460: Problem with Monoid instance of Data.Map In-Reply-To: <051.14fc774a6009986dddf4bde26633711e@haskell.org> References: <051.14fc774a6009986dddf4bde26633711e@haskell.org> Message-ID: <066.5e6598a8b5a628b6ed3b95bfda017d04@haskell.org> #1460: Problem with Monoid instance of Data.Map -------------------------------+------------------------------------------- Reporter: ahey@? | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: | Version: 6.6.1 libraries/base | Keywords: Data.Map Monoid Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by nomeata): * failure: => None/Unknown Comment: This comes up regularly, e.g. April 2012 as well (http://www.haskell.org/pipermail/libraries/2012-April/017743.html) and right now again (here, locally). Just saying. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 22 04:42:19 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Nov 2013 04:42:19 -0000 Subject: [GHC] #8549: GHCI incorrectly link symbols defined with foreign import ccall In-Reply-To: <045.5f1cfb88fc2e3dd9c933ec8683824602@haskell.org> References: <045.5f1cfb88fc2e3dd9c933ec8683824602@haskell.org> Message-ID: <060.a6ad4ab870a6d6611b96858a7cd8ea28@haskell.org> #8549: GHCI incorrectly link symbols defined with foreign import ccall -------------------------------------------------+------------------------- Reporter: qnikst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHCi crash | Unknown/Multiple Test Case: | Difficulty: https://gist.github.com/qnikst/324a66914b3aba878be5| Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by carter): theres no attachement on this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 22 05:45:16 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Nov 2013 05:45:16 -0000 Subject: [GHC] #8549: GHCI incorrectly link symbols defined with foreign import ccall In-Reply-To: <045.5f1cfb88fc2e3dd9c933ec8683824602@haskell.org> References: <045.5f1cfb88fc2e3dd9c933ec8683824602@haskell.org> Message-ID: <060.624d600aad2617bc3a395d398166e547@haskell.org> #8549: GHCI incorrectly link symbols defined with foreign import ccall -------------------------------------------------+------------------------- Reporter: qnikst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: GHCi crash | Unknown/Multiple Test Case: | Difficulty: https://gist.github.com/qnikst/324a66914b3aba878be5| Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by qnikst): * os: Unknown/Multiple => Linux -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 22 09:41:11 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Nov 2013 09:41:11 -0000 Subject: [GHC] #8553: ASSERT failed compiler/typecheck/TcMType.lhs line 809 In-Reply-To: <046.c98e70d0ceeae727c974fb11a22a1bd7@haskell.org> References: <046.c98e70d0ceeae727c974fb11a22a1bd7@haskell.org> Message-ID: <061.2c1dfe6fd713c111371915f3db3a4aab@haskell.org> #8553: ASSERT failed compiler/typecheck/TcMType.lhs line 809 --------------------------------------------+------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: gadt6 T7474 T5246 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by Joachim Breitner ): In [changeset:"9f10d5ba0fae4357f962032dda1be5316c16db1b/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="9f10d5ba0fae4357f962032dda1be5316c16db1b" Mark tests as expect_broken when borken with -DDEBUG The related bugs are #8553 and #8525. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 22 09:41:11 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Nov 2013 09:41:11 -0000 Subject: [GHC] #8525: lib/integer/integerConstantFolding fails with -DDEBUG In-Reply-To: <046.5d4a4a7e5e2261c32eff470cf125498f@haskell.org> References: <046.5d4a4a7e5e2261c32eff470cf125498f@haskell.org> Message-ID: <061.14fb8a62de3363b6f4d03b7366b39ecf@haskell.org> #8525: lib/integer/integerConstantFolding fails with -DDEBUG -------------------------------------------+------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: integerConstantFolding | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------------+------------------------------- Comment (by Joachim Breitner ): In [changeset:"9f10d5ba0fae4357f962032dda1be5316c16db1b/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="9f10d5ba0fae4357f962032dda1be5316c16db1b" Mark tests as expect_broken when borken with -DDEBUG The related bugs are #8553 and #8525. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 22 11:33:23 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Nov 2013 11:33:23 -0000 Subject: [GHC] #8548: Coercible does not resolve type family application In-Reply-To: <046.8a91ee19cb9fa713b4f1e9492cfc9689@haskell.org> References: <046.8a91ee19cb9fa713b4f1e9492cfc9689@haskell.org> Message-ID: <061.00e29d360a653c6108058d91899a67dd@haskell.org> #8548: Coercible does not resolve type family application --------------------------------------------+------------------------------ Reporter: nomeata | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: 8503 | Blocked By: | Related Tickets: #8503 --------------------------------------------+------------------------------ Comment (by nomeata): Fixed (not yet pushed), solves all listed tickets. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 22 12:16:50 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Nov 2013 12:16:50 -0000 Subject: [GHC] #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough In-Reply-To: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> References: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> Message-ID: <062.502a275e038a90b2ac8afc3d66957c77@haskell.org> #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 8548 Blocking: | Related Tickets: #8541 -------------------------------------+------------------------------------ Comment (by nomeata): Replying to [comment:9 goldfire]: > Hold the phone! There is an easier solution to the original problem! > > \[..\] > > Thoughts? Is this a good plan? We could always, as a first pass, implement GND in terms of `Coercible` and fail if there are any unsolved constraints, working for `C Age` above but not `C (List a)`. I?ve been trying to get your attempt to work. It works for a lot of easy cases, and it works in theory, but there is an implementational difficulty with extra type variables in the instance. Consider: {{{ import GHC.Exts class Cls a where meth :: a newtype Id m = Id m deriving Cls }}} The instance we want to generate is {{{ instance forall m. Cls m => Cls (Id m) where meth = coerce (meth :: m) :: Id m }}} But that will require `ScopedTypeVariables`. Question one: Can I generate code at `TcGenDeriv` stage that uses scoped type variables, without requiring that extension to be enabled in the whole module? Next problem: Currently the code produces {{{ ==================== Derived instances ==================== Derived instances: instance T3423.Cls m_ayI => T3423.Cls (T3423.Id m_ayI) where T3423.meth = GHC.Prim.coerce (T3423.meth :: m_ayI) :: T3423.Id m_ayI }}} so there is no `forall` in the instance head. For `newtype ... deriving Cls` it might be possible to add that (although I did not yet find where), but the user should be able to specify {{{ deriving instance Cls m => Cls (Id m) }}} without having to add `forall m.`. I?m not sure what to do here. It would be best if we could generate code that works without having to specify types in the method definition at all, maybe using something like `$ClsId = case $superClassDict of D:Cls meth => D:Cls (coerce meth)`, but I do not see how `$superClassDict` should look like. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 22 13:27:43 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Nov 2013 13:27:43 -0000 Subject: [GHC] #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough In-Reply-To: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> References: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> Message-ID: <062.97dfb6291866682e8794ffc53651585b@haskell.org> #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 8548 Blocking: | Related Tickets: #8541 -------------------------------------+------------------------------------ Comment (by nomeata): My analysis in the previous comment was wrong; SPJ found out that the problem seems to lie in the calculation of defined and used variables for derived instances. Debugging... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 22 13:53:48 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Nov 2013 13:53:48 -0000 Subject: [GHC] #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough In-Reply-To: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> References: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> Message-ID: <062.0964e39379715f255a6ee31b6b7d64ad@haskell.org> #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 8548 Blocking: | Related Tickets: #8541 -------------------------------------+------------------------------------ Comment (by nomeata): Ok, the problem were two missing characters: {{{ @@ -432,7 +432,7 @@ renameDeriv is_boot inst_infos bagBinds = -- Bring the right type variables into -- scope (yuk), and rename the method binds ASSERT( null sigs ) - bindLocalNames (map Var.varName tyvars) $ + bindLocalNamesFV (map Var.varName tyvars) $ do { (rn_binds, fvs) <- rnMethodBinds (is_cls_nm inst) (\_ -> []) binds ; let binds' = InstBindings { ib_binds = rn_binds , ib_pragmas = [] }}} but now everything seems to work. I?m running validate right now. If it goes through, any objections to pushing wip/T8503 to master and closing this bug? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 22 14:00:56 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Nov 2013 14:00:56 -0000 Subject: [GHC] #8555: Simplify given `Coercible` constraints Message-ID: <046.a1497cad7416e0b2528d2d39ab4215f8@haskell.org> #8555: Simplify given `Coercible` constraints -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.7 checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: Unknown/Multiple | valid program Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8503 | -------------------------------------+------------------------------------- It would be feasible and possibly useful if {{{ foo :: Coercible [a] [b] => a -> b foo = coerce }}} would work. This involve simplifying `CtGiven`s similar to how given (nominal) equalities are simplified. I?ll defer working on this, as it is not strictly required, it seems. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 22 14:02:42 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Nov 2013 14:02:42 -0000 Subject: [GHC] #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough In-Reply-To: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> References: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> Message-ID: <062.c3d7ef9bfd7f10fe44df455cda68faff@haskell.org> #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 8548 Blocking: | Related Tickets: #8541 -------------------------------------+------------------------------------ Comment (by goldfire): Please push when ready. And, re `ScopedTypeVariables`, you're right -- we do need that extension. But, see [http://git.haskell.org/ghc.git/blob/refs/heads/wip/T8503:/compiler/typecheck/TcDeriv.lhs#l410 here] -- the extension is enabled just over the code that needs it. Thanks for taking the last leg on this one! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 22 14:22:32 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Nov 2013 14:22:32 -0000 Subject: [GHC] #8380: Numerous testsuite failures on ARM due to missing mkJumpToAddr In-Reply-To: <046.6822dd2c7a2b1392cbd1b6deb902b274@haskell.org> References: <046.6822dd2c7a2b1392cbd1b6deb902b274@haskell.org> Message-ID: <061.cb99841674bcc4bb5f21956ce21a550d@haskell.org> #8380: Numerous testsuite failures on ARM due to missing mkJumpToAddr -------------------------------------+--------------------------------- Reporter: bgamari | Owner: thoughtpolice Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: patch Operating System: Unknown/Multiple | Architecture: arm Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+--------------------------------- Comment (by Austin Seipp ): In [changeset:"5bab1a57f572e29dfdffd6d1ce8e53a2772b18fd/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5bab1a57f572e29dfdffd6d1ce8e53a2772b18fd" GHCi: Properly generate jump code for ARM (#8380) This adds code for jumping to given addresses for ARM, written by Ben Gamari. However, when allocating new infotables for bytecode (which is where this jump code occurs), we need to be sure to flush the cache on the execute pointer returned from allocateExec() - on systems like ARM, the processor won't reliably read back code or automatically cache flush, where x86 will. So we add a new flushExec primitive to call out to GCC's __builtin___clear_cache primitive, which will properly generate the correct code (nothing on x86, and a call to libgcc's __clear_cache on ARM) and make sure we use it after writing the code out. Authored-by: Ben Gamari Authored-by: Austin Seipp Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 22 14:22:33 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Nov 2013 14:22:33 -0000 Subject: [GHC] #8122: make binary-dist broken on OS X in HEAD In-Reply-To: <047.e3f39dff89338f1ef14e78b10c690e19@haskell.org> References: <047.e3f39dff89338f1ef14e78b10c690e19@haskell.org> Message-ID: <062.0e6d4ba5dc54046bf15b467af3b9ccda@haskell.org> #8122: make binary-dist broken on OS X in HEAD ------------------------------------------+-------------------------------- Reporter: danharaj | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Installing GHC failed | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ------------------------------------------+-------------------------------- Comment (by Austin Seipp ): In [changeset:"50055afe0dea0bcea8eea8d53353dfd0f1f204ca/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="50055afe0dea0bcea8eea8d53353dfd0f1f204ca" Fix make binary-dist on OS X (#8122) Authored-by: Christiaan Baaj Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 22 14:22:33 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Nov 2013 14:22:33 -0000 Subject: [GHC] #8551: Fix formatting in docs at one place In-Reply-To: <047.a48642087a85ff970468230bf8e092a2@haskell.org> References: <047.a48642087a85ff970468230bf8e092a2@haskell.org> Message-ID: <062.f8d5d6e26e8ed02bdbf4e9ab1c2d74bd@haskell.org> #8551: Fix formatting in docs at one place -------------------------------------+------------------------------------ Reporter: Tarrasch | Owner: Type: task | Status: patch Priority: lowest | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Austin Seipp ): In [changeset:"1bffa2b2e7b7d1a829dff44256a5d1da3f2aef88/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="1bffa2b2e7b7d1a829dff44256a5d1da3f2aef88" Fix formatting (fixes #8551) Signed-off-by: Arash Rouhani Reviewed-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 22 14:22:33 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Nov 2013 14:22:33 -0000 Subject: [GHC] #8552: Rename StgArrWords to StgArrBytes In-Reply-To: <047.162074162cf551ca6b1ad3c66a412848@haskell.org> References: <047.162074162cf551ca6b1ad3c66a412848@haskell.org> Message-ID: <062.0e3ea99a5b659f64ac6deeafc5c0b013@haskell.org> #8552: Rename StgArrWords to StgArrBytes -------------------------------------+------------------------------------ Reporter: Tarrasch | Owner: Type: task | Status: patch Priority: lowest | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Austin Seipp ): In [changeset:"ac5ff6422fb9e143c38e6cdcf16280de200cb880/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="ac5ff6422fb9e143c38e6cdcf16280de200cb880" Comment on StgArrWords vs StgArrBytes See #8552 Signed-off-by: Arash Rouhani Reviewed-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 22 14:22:34 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Nov 2013 14:22:34 -0000 Subject: [GHC] #5987: Too many symbols in ghc package DLL In-Reply-To: <044.2d87ca11391c23e0fa5f3c5418ae791f@haskell.org> References: <044.2d87ca11391c23e0fa5f3c5418ae791f@haskell.org> Message-ID: <059.582b19ea68f9aff8e530bae214ad4e82@haskell.org> #5987: Too many symbols in ghc package DLL -------------------------------------+------------------------------------ Reporter: igloo | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: 3658 | Related Tickets: -------------------------------------+------------------------------------ Comment (by Austin Seipp ): In [changeset:"9bb909bbcf280f137c7a379d05acf5bc21268e5b/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="9bb909bbcf280f137c7a379d05acf5bc21268e5b" Temporarily lower unfolding threshold on Windows This is a very temporary, very unsatisfactory hack to fix #5987 (for now.) The included comments essentially say it all: we lower the unfolding threshold to minimize some amount of exported symbols from the GHC stage2 DLL. I unfortunately had to lower it quite substantially for the dynamic stage2 build to pass. As of this writing, the DLL split between ghc.dll and ghc-0.dll is something like 26,000 vs 63,000 exported symbols, respectively. So we're still quite in danger of tripping it, but I think we will be OK at this exact moment. Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 22 14:22:35 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Nov 2013 14:22:35 -0000 Subject: [GHC] #8533: Extend new getPhysicalMemorySize ifdef to ios_HOST_OS In-Reply-To: <045.661111d53a8a05cd8e37eab898a245cc@haskell.org> References: <045.661111d53a8a05cd8e37eab898a245cc@haskell.org> Message-ID: <060.edb27a8b80994db599990ddb3ee9a864@haskell.org> #8533: Extend new getPhysicalMemorySize ifdef to ios_HOST_OS -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Other | Architecture: arm Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"bb73d1d4a4e5195cbecc5a009a0e798af02aa37b/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="bb73d1d4a4e5195cbecc5a009a0e798af02aa37b" Extend getPhysicalMemorySize to iOS (#8533) Authored-by: Authored-by: Luke Iannini Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 22 14:25:21 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Nov 2013 14:25:21 -0000 Subject: [GHC] #8533: Extend new getPhysicalMemorySize ifdef to ios_HOST_OS In-Reply-To: <045.661111d53a8a05cd8e37eab898a245cc@haskell.org> References: <045.661111d53a8a05cd8e37eab898a245cc@haskell.org> Message-ID: <060.c6874d2d6d9b2388ca867f9b6441337a@haskell.org> #8533: Extend new getPhysicalMemorySize ifdef to ios_HOST_OS -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Other | Architecture: arm Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 22 14:27:27 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Nov 2013 14:27:27 -0000 Subject: [GHC] #5013: sporadic failures during compilation under solaris In-Reply-To: <045.60b676bf3753dc6058e807ea654417dd@haskell.org> References: <045.60b676bf3753dc6058e807ea654417dd@haskell.org> Message-ID: <060.9df5b71ebc2254eadd5a50b6df5d6551@haskell.org> #5013: sporadic failures during compilation under solaris ----------------------------------+--------------------------- Reporter: maeder | Owner: Type: bug | Status: closed Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 7.0.4 Resolution: worksforme | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+--------------------------- Changes (by maeder): * status: new => closed * resolution: => worksforme Comment: This change improved the situation for me. I did not observe the failure again for a patched ghc-6.8.3, but also only twice for the original ghc-6.8.2 (running 400 test compilations each). I don't know if the change makes a difference for other architectures. At least others may find a solution if they observe a similar behavior. Therefore I close this ticket now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 22 14:28:48 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Nov 2013 14:28:48 -0000 Subject: [GHC] #8122: make binary-dist broken on OS X in HEAD In-Reply-To: <047.e3f39dff89338f1ef14e78b10c690e19@haskell.org> References: <047.e3f39dff89338f1ef14e78b10c690e19@haskell.org> Message-ID: <062.10ea6b98da1e78d166986fd7c3cf5930@haskell.org> #8122: make binary-dist broken on OS X in HEAD ------------------------------------------+-------------------------------- Reporter: danharaj | Owner: Type: bug | Status: closed Priority: highest | Milestone: Component: Build System | Version: 7.7 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Installing GHC failed | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ------------------------------------------+-------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 22 14:28:58 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Nov 2013 14:28:58 -0000 Subject: [GHC] #8122: make binary-dist broken on OS X in HEAD In-Reply-To: <047.e3f39dff89338f1ef14e78b10c690e19@haskell.org> References: <047.e3f39dff89338f1ef14e78b10c690e19@haskell.org> Message-ID: <062.2e566e035fa7ee979a71cc178b7538bf@haskell.org> #8122: make binary-dist broken on OS X in HEAD ------------------------------------------+-------------------------------- Reporter: danharaj | Owner: Type: bug | Status: closed Priority: highest | Milestone: Component: Build System | Version: 7.7 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Installing GHC failed | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ------------------------------------------+-------------------------------- Comment (by thoughtpolice): Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 22 14:29:38 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Nov 2013 14:29:38 -0000 Subject: [GHC] #8380: Numerous testsuite failures on ARM due to missing mkJumpToAddr In-Reply-To: <046.6822dd2c7a2b1392cbd1b6deb902b274@haskell.org> References: <046.6822dd2c7a2b1392cbd1b6deb902b274@haskell.org> Message-ID: <061.6abfd70d397c056ab9dd5d8319bd7bac@haskell.org> #8380: Numerous testsuite failures on ARM due to missing mkJumpToAddr -------------------------------------+--------------------------------- Reporter: bgamari | Owner: thoughtpolice Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: patch Operating System: Unknown/Multiple | Architecture: arm Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+--------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 22 14:30:13 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Nov 2013 14:30:13 -0000 Subject: [GHC] #8551: Fix formatting in docs at one place In-Reply-To: <047.a48642087a85ff970468230bf8e092a2@haskell.org> References: <047.a48642087a85ff970468230bf8e092a2@haskell.org> Message-ID: <062.05ce2b15d84d5a011a89b5e4264bf002@haskell.org> #8551: Fix formatting in docs at one place -------------------------------------+------------------------------------ Reporter: Tarrasch | Owner: Type: task | Status: closed Priority: lowest | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 22 14:50:18 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Nov 2013 14:50:18 -0000 Subject: [GHC] #8537: confusing error message for specialize pragma In-Reply-To: <045.832f7ac508c2d7554c2e9563deea3e66@haskell.org> References: <045.832f7ac508c2d7554c2e9563deea3e66@haskell.org> Message-ID: <060.f02e2146285717899974d0dd2fa1eb03@haskell.org> #8537: confusing error message for specialize pragma -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Old description: > I get the following confusing error/warning about SPECIALIZE > {{{ > > SPECIALISE pragma for non-overloaded function `$cfmap' > > }}} > > with the following example module > > {{{ > > {-# LANGUAGE PolyKinds #-} > {-# LANGUAGE BangPatterns #-} > {-# LANGUAGE DataKinds #-} > {-# LANGUAGE TypeFamilies #-} > {-# LANGUAGE GADTs #-} > {-# LANGUAGE DeriveDataTypeable #-} > {-# LANGUAGE TypeOperators #-} > {-# LANGUAGE FlexibleInstances #-} > {-# LANGUAGE FlexibleContexts #-} > {-# LANGUAGE FunctionalDependencies #-} > {-# LANGUAGE UndecidableInstances #-} > {-# LANGUAGE ScopedTypeVariables #-} > {-# LANGUAGE StandaloneDeriving #-} > {-# LANGUAGE CPP #-} > {-# LANGUAGE TemplateHaskell #-} > {-# LANGUAGE NoImplicitPrelude #-} > > module Numerical.Types.Shape where > > import Control.Applicative > import Data.Foldable > import Data.Monoid > import Data.Functor > import Prelude (seq, ($!),($),Show(..),Eq(),Int) > > data Nat = S !Nat | Z > --deriving (Eq,Show,Read) > > {- > not doing the HLIST style shape because I don't want to have > any pattern matchings going on. > > Also would play hell with locality quality in the address translation > hackery, > because there'd be an extra load to get those ints! > -} > infixr 3 :* > > {- > the concern basically boils down to "will it specialize / inline well" > > -} > data Shape (rank :: Nat) a where > Nil :: Shape Z a > (:*) :: !(a) -> !(Shape r a ) -> Shape (S r) a > > --deriving instance (Show (Shape rank a)) > > -- deriving instance Eq (Shape rank a) > > -- #if defined( __GLASGOW_HASKELL__ ) && ( __GLASGOW_HASKELL__ >= > 707) > --deriving instance Typeable (Shape rank a) > -- #endif > > > instance Functor (Shape Z) where > > fmap = \ f Nil -> Nil > {-# INLINABLE fmap #-} > > {-# SPECIALIZE fmap :: (Int ->Int )-> (Shape Z Int)-> (Shape Z Int) > #-} > > }}} New description: I get the following confusing error/warning about SPECIALIZE {{{ SPECIALISE pragma for non-overloaded function `$cfmap' }}} with the following example module {{{ {-# LANGUAGE PolyKinds #-} {-# LANGUAGE BangPatterns #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE DeriveDataTypeable #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE StandaloneDeriving #-} {-# LANGUAGE CPP #-} {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE NoImplicitPrelude #-} module Numerical.Types.Shape where import Control.Applicative import Data.Foldable import Data.Monoid import Data.Functor import Prelude (seq, ($!),($),Show(..),Eq(),Int) data Nat = S !Nat | Z infixr 3 :* data Shape (rank :: Nat) a where Nil :: Shape Z a (:*) :: !(a) -> !(Shape r a ) -> Shape (S r) a instance Functor (Shape Z) where fmap = \ f Nil -> Nil {-# INLINABLE fmap #-} {-# SPECIALIZE fmap :: (Int ->Int )-> (Shape Z Int)-> (Shape Z Int) #-} }}} -- Comment (by simonpj): The `$cfmap` part is not very clever, but the actual message is fine isn't it? There isn't any useful specialisation we can do on `fmap` at type `(Shape Z)` is there? I suppose you might say that the pattern match is exhaustive so we could omit the test for `Nil` vs `(:*)`, but that's all. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 22 14:53:40 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Nov 2013 14:53:40 -0000 Subject: [GHC] #5987: Too many symbols in ghc package DLL In-Reply-To: <044.2d87ca11391c23e0fa5f3c5418ae791f@haskell.org> References: <044.2d87ca11391c23e0fa5f3c5418ae791f@haskell.org> Message-ID: <059.d69ffef4ab7cc9151b4611d622ca825a@haskell.org> #5987: Too many symbols in ghc package DLL -------------------------------------+------------------------------------ Reporter: igloo | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: 3658 | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * milestone: 7.8.1 => 7.10.1 Comment: I've temporarily fixed this in HEAD by lowering the unfolding threshold for the stage2 build on windows. We're still extremely close to the symbol limit, but it should stay OK for 7.8. I'm leaving this highest priority and bumping to 7.10.1 - we must find a better fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 22 14:54:14 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Nov 2013 14:54:14 -0000 Subject: [GHC] #8552: Rename StgArrWords to StgArrBytes In-Reply-To: <047.162074162cf551ca6b1ad3c66a412848@haskell.org> References: <047.162074162cf551ca6b1ad3c66a412848@haskell.org> Message-ID: <062.fe61529a19451bf8f0d3be72ddd37f2a@haskell.org> #8552: Rename StgArrWords to StgArrBytes -------------------------------------+------------------------------------ Reporter: Tarrasch | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: patch => new Comment: Seems sensible to me. Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 22 14:57:06 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Nov 2013 14:57:06 -0000 Subject: [GHC] #8542: Suggest NegativeLiterals In-Reply-To: <047.bf5090fe22a22eb99898221a0c557cee@haskell.org> References: <047.bf5090fe22a22eb99898221a0c557cee@haskell.org> Message-ID: <062.3a69fd7dc717242dbfb8511aba739eb8@haskell.org> #8542: Suggest NegativeLiterals -------------------------------------+------------------------------------ Reporter: monoidal | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by thoughtpolice): I'm very much in favor of frontend-warnings that don't depend on peculiarities of the machine, if possible. The Report specifies an Int at minimum has the range `[-2^29 .. 2^29-1]`, so I think your suggestion is reasonable. Does anyone else have opinions? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 22 15:32:16 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Nov 2013 15:32:16 -0000 Subject: [GHC] #8526: -fforce-recomp does not re-summarise modules In-Reply-To: <044.a874b1b60feee8d3abbe2c98f3ab0e0a@haskell.org> References: <044.a874b1b60feee8d3abbe2c98f3ab0e0a@haskell.org> Message-ID: <059.d73eac7f9ad8e10dbbb3c422d73a4bc3@haskell.org> #8526: -fforce-recomp does not re-summarise modules -------------------------------------+------------------------------------ Reporter: parcs | Owner: parcs Type: bug | Status: patch Priority: normal | Milestone: Component: Driver | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Patrick Palka ): In [changeset:"08580616db410325dec7c5ebf36fef64b46a8f10/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="08580616db410325dec7c5ebf36fef64b46a8f10" Always re-summarise modules when -fforce-recomp is set Fixes #8526 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 22 15:32:28 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Nov 2013 15:32:28 -0000 Subject: [GHC] #8526: -fforce-recomp does not re-summarise modules In-Reply-To: <044.a874b1b60feee8d3abbe2c98f3ab0e0a@haskell.org> References: <044.a874b1b60feee8d3abbe2c98f3ab0e0a@haskell.org> Message-ID: <059.9c8d0d927b3215f444a8fd5577be3bb6@haskell.org> #8526: -fforce-recomp does not re-summarise modules -------------------------------------+------------------------------------ Reporter: parcs | Owner: parcs Type: bug | Status: patch Priority: normal | Milestone: Component: Driver | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Patrick Palka ): In [changeset:"b8c8a218dcd31b3a2e91d5094fd92003f659c107/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="b8c8a218dcd31b3a2e91d5094fd92003f659c107" Test Trac #8526 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 22 15:33:35 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Nov 2013 15:33:35 -0000 Subject: [GHC] #8526: -fforce-recomp does not re-summarise modules In-Reply-To: <044.a874b1b60feee8d3abbe2c98f3ab0e0a@haskell.org> References: <044.a874b1b60feee8d3abbe2c98f3ab0e0a@haskell.org> Message-ID: <059.e0e7df3edfbdab8b2c57ed587478d4c4@haskell.org> #8526: -fforce-recomp does not re-summarise modules -------------------------------------+------------------------------------ Reporter: parcs | Owner: parcs Type: bug | Status: closed Priority: normal | Milestone: Component: Driver | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: T8526 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by parcs): * status: patch => closed * testcase: => T8526 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 22 15:50:21 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Nov 2013 15:50:21 -0000 Subject: [GHC] #8542: Suggest NegativeLiterals In-Reply-To: <047.bf5090fe22a22eb99898221a0c557cee@haskell.org> References: <047.bf5090fe22a22eb99898221a0c557cee@haskell.org> Message-ID: <062.155a29ae609090c7f99dfe3dab82e506@haskell.org> #8542: Suggest NegativeLiterals -------------------------------------+------------------------------------ Reporter: monoidal | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"2081bdcb60ba4950d280fff542f10dd9f8231fb6/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="2081bdcb60ba4950d280fff542f10dd9f8231fb6" Add suggestion of -XNegativeLiterals Based on a draft from Krzysztof Gogolewski. Fixes Trac #8542 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 22 15:50:22 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Nov 2013 15:50:22 -0000 Subject: [GHC] #8537: confusing error message for specialize pragma In-Reply-To: <045.832f7ac508c2d7554c2e9563deea3e66@haskell.org> References: <045.832f7ac508c2d7554c2e9563deea3e66@haskell.org> Message-ID: <060.1a5b09cfce9fc5a02c40e2e227bf1c44@haskell.org> #8537: confusing error message for specialize pragma -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"7db23406e4162f9925474fc76b7dffd5d302c312/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="7db23406e4162f9925474fc76b7dffd5d302c312" Print the correct name when complaining about SPECIALISE pragmas Fixes Trac #8537 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 22 15:50:22 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Nov 2013 15:50:22 -0000 Subject: [GHC] #8553: ASSERT failed compiler/typecheck/TcMType.lhs line 809 In-Reply-To: <046.c98e70d0ceeae727c974fb11a22a1bd7@haskell.org> References: <046.c98e70d0ceeae727c974fb11a22a1bd7@haskell.org> Message-ID: <061.afcd9ac069af0352760146fa66eae943@haskell.org> #8553: ASSERT failed compiler/typecheck/TcMType.lhs line 809 --------------------------------------------+------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: gadt6 T7474 T5246 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"985663ea47487a9e567814ba000e81d65358bf02/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="985663ea47487a9e567814ba000e81d65358bf02" Fix type-equality in the type checker (fixes Trac #8553) For horrible reasons (Note [Comparison with OpenTypeKind] in Type), the function Type.eqType currently equates OOpenKind with *. This may or may not be a good idea (it's certainly a revolting one) but it DOES NOT WORK in the type checker, which *does* need to distinguish OpenKind and *. Rather than solve the underlying problem (I have some ideas) I just introduced a new, and very short, simple, straightforward function TcType.tcEqType to do the job. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 22 15:50:59 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Nov 2013 15:50:59 -0000 Subject: [GHC] #8542: Suggest NegativeLiterals In-Reply-To: <047.bf5090fe22a22eb99898221a0c557cee@haskell.org> References: <047.bf5090fe22a22eb99898221a0c557cee@haskell.org> Message-ID: <062.068e7faa3240f012dfd82f370b9b296b@haskell.org> #8542: Suggest NegativeLiterals -------------------------------------+------------------------------------ Reporter: monoidal | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"813ba429e21e6cefd47ed950c21319a8314da13d/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="813ba429e21e6cefd47ed950c21319a8314da13d" Test #8542 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 22 15:51:00 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Nov 2013 15:51:00 -0000 Subject: [GHC] #8537: confusing error message for specialize pragma In-Reply-To: <045.832f7ac508c2d7554c2e9563deea3e66@haskell.org> References: <045.832f7ac508c2d7554c2e9563deea3e66@haskell.org> Message-ID: <060.1afb586c9c06fd328f7b953ef50d5e67@haskell.org> #8537: confusing error message for specialize pragma -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"2a88f8fbe24f3a9e832f3bc76ac3b877e79cf978/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="2a88f8fbe24f3a9e832f3bc76ac3b877e79cf978" Test Trac #8537 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 22 15:55:06 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Nov 2013 15:55:06 -0000 Subject: [GHC] #8542: Suggest NegativeLiterals In-Reply-To: <047.bf5090fe22a22eb99898221a0c557cee@haskell.org> References: <047.bf5090fe22a22eb99898221a0c557cee@haskell.org> Message-ID: <062.d8fb1b8878b5b6d477e100f775c4b7b7@haskell.org> #8542: Suggest NegativeLiterals ----------------------------------------------+---------------------------- Reporter: monoidal | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: numeric/should_fail/T8542 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Changes (by simonpj): * status: patch => closed * testcase: => numeric/should_fail/T8542 * resolution: => fixed Comment: I pushed this, modified a bit to give errors like {{{ T7895.hs:13:6: Warning: Literal -129 is out of the Int8 range -128..127 }}} That is, we now give the expected range explicitly. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 22 15:58:45 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Nov 2013 15:58:45 -0000 Subject: [GHC] #8537: confusing error message for specialize pragma In-Reply-To: <045.832f7ac508c2d7554c2e9563deea3e66@haskell.org> References: <045.832f7ac508c2d7554c2e9563deea3e66@haskell.org> Message-ID: <060.36f64a111875845ceb5e00dfaded43a6@haskell.org> #8537: confusing error message for specialize pragma -------------------------------------------------+------------------------- Reporter: carter | Owner: Type: bug | Status: Priority: normal | closed Component: Compiler | Milestone: Resolution: fixed | Version: 7.6.3 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: | Unknown/Multiple simplCore/should_compile/T8537 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by simonpj): * status: new => closed * testcase: => simplCore/should_compile/T8537 * resolution: => fixed Comment: Error message improved! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 22 16:09:14 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Nov 2013 16:09:14 -0000 Subject: [GHC] #8525: lib/integer/integerConstantFolding fails with -DDEBUG In-Reply-To: <046.5d4a4a7e5e2261c32eff470cf125498f@haskell.org> References: <046.5d4a4a7e5e2261c32eff470cf125498f@haskell.org> Message-ID: <061.fc038846d476766a436cb72ef01586a5@haskell.org> #8525: lib/integer/integerConstantFolding fails with -DDEBUG -------------------------------------------+------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: integerConstantFolding | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------------+------------------------------- Comment (by simonpj): I don't think this has anything to do with #8553 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 22 16:10:51 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Nov 2013 16:10:51 -0000 Subject: [GHC] #8553: ASSERT failed compiler/typecheck/TcMType.lhs line 809 In-Reply-To: <046.c98e70d0ceeae727c974fb11a22a1bd7@haskell.org> References: <046.c98e70d0ceeae727c974fb11a22a1bd7@haskell.org> Message-ID: <061.d28060a9a01676acc6ab111282cb82c8@haskell.org> #8553: ASSERT failed compiler/typecheck/TcMType.lhs line 809 --------------------------------------------+------------------------------ Reporter: nomeata | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: gadt6 T7474 T5246 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: This really was a bug, now fixed. (The particular manifestation was that `TcCanonical.reOrient` didn't fire when it should have done so.) I don't know how to test this; it requires the DEBUG compiler. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 22 16:39:21 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Nov 2013 16:39:21 -0000 Subject: [GHC] #8450: can't match type Bool with (), but shouldn't have to In-Reply-To: <044.6258cc11fd2886a6eb3daddcf10a5505@haskell.org> References: <044.6258cc11fd2886a6eb3daddcf10a5505@haskell.org> Message-ID: <059.4da922c9cefc745765763910e960f5fc@haskell.org> #8450: can't match type Bool with (), but shouldn't have to ------------------------------------------------+-------------------------- Reporter: dmwit | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: typecheck/should_fail/T8450 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by Simon Peyton Jones ): In [changeset:"7881488201629aa1ab36e3e0fbeb4d7b4b85bd91/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="7881488201629aa1ab36e3e0fbeb4d7b4b85bd91" A raft of changes driven by Trac #8540 The root cause of #8450 is that the new Template Haskell story, with the renamer doing more of the work of Template Haskell, wasn't dealing correctly with the keepAlive problem. Consider g = ..blah... f = [| g |] Then f's RHS refers to g's name but not to g, so g was being discarded as dead code. Fixing this sucked me into a deep swamp of understanding how all the moving parts of hte new Template Haskell fit together, leading to a large collection of related changes and better documentation. Specifically: * Instead of putting the TH level of a binder in the LocalRdrEnv, there is now a separate field tcl_th_bndrs :: NameEnv (TopLevelFlag, ThLevel) in the TcLclEnv, which records for each binder a) whether it is syntactically a top-level binder or not b) its TH level This deals uniformly with top-level and non-top-level binders, which was previously dealt with via greviously-delicate meddling with Internal and External Names. Much better. * As a result I could remove the tct_level field of ATcId. * There are consequential changes in TcEnv too, which must also extend the level bindings. Again, more clarity. I renamed TcEnv.tcExtendTcTyThingEnv to tcExtendKindEnv2, since it's only used during kind inference, for (AThing kind) and APromotionErr; and that is relevant to whether we want to extend the tcl_th_bndrs field (no). * I de-crufted the code in RnEnv.extendGlobalRdrEnv, by getting rid of the qual_gre code which said "Seems like 5 times as much work as it deserves!". Instead, RdrName.pickGREs makes the Internal names shadow External ones. * I moved the checkThLocalName cross-stage test to finishHsVar; previously we weren't doing the test at all in the OpApp case! * Quite a few changes (shortening the code) in the cross-stage checking code in TcExpr and RnSplice, notably to move the keepAlive call to the renamer One leftover piece: * In TcEnv I removed tcExtendGhciEnv and refactored tcExtendGlobalTyVars; this is really related to the next commit, but it was too hard to disentangle. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 22 16:39:22 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Nov 2013 16:39:22 -0000 Subject: [GHC] #8540: Template Haskell handling bug in ghc-7.7.20131115 ? In-Reply-To: <044.a2405e435a0516e234d799c5d8afd594@haskell.org> References: <044.a2405e435a0516e234d799c5d8afd594@haskell.org> Message-ID: <059.646c6b4ea708862eff9819d09bd29fe9@haskell.org> #8540: Template Haskell handling bug in ghc-7.7.20131115 ? -------------------------------------+------------------------------------ Reporter: awson | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"7881488201629aa1ab36e3e0fbeb4d7b4b85bd91/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="7881488201629aa1ab36e3e0fbeb4d7b4b85bd91" A raft of changes driven by Trac #8540 The root cause of #8450 is that the new Template Haskell story, with the renamer doing more of the work of Template Haskell, wasn't dealing correctly with the keepAlive problem. Consider g = ..blah... f = [| g |] Then f's RHS refers to g's name but not to g, so g was being discarded as dead code. Fixing this sucked me into a deep swamp of understanding how all the moving parts of hte new Template Haskell fit together, leading to a large collection of related changes and better documentation. Specifically: * Instead of putting the TH level of a binder in the LocalRdrEnv, there is now a separate field tcl_th_bndrs :: NameEnv (TopLevelFlag, ThLevel) in the TcLclEnv, which records for each binder a) whether it is syntactically a top-level binder or not b) its TH level This deals uniformly with top-level and non-top-level binders, which was previously dealt with via greviously-delicate meddling with Internal and External Names. Much better. * As a result I could remove the tct_level field of ATcId. * There are consequential changes in TcEnv too, which must also extend the level bindings. Again, more clarity. I renamed TcEnv.tcExtendTcTyThingEnv to tcExtendKindEnv2, since it's only used during kind inference, for (AThing kind) and APromotionErr; and that is relevant to whether we want to extend the tcl_th_bndrs field (no). * I de-crufted the code in RnEnv.extendGlobalRdrEnv, by getting rid of the qual_gre code which said "Seems like 5 times as much work as it deserves!". Instead, RdrName.pickGREs makes the Internal names shadow External ones. * I moved the checkThLocalName cross-stage test to finishHsVar; previously we weren't doing the test at all in the OpApp case! * Quite a few changes (shortening the code) in the cross-stage checking code in TcExpr and RnSplice, notably to move the keepAlive call to the renamer One leftover piece: * In TcEnv I removed tcExtendGhciEnv and refactored tcExtendGlobalTyVars; this is really related to the next commit, but it was too hard to disentangle. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 22 16:47:55 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Nov 2013 16:47:55 -0000 Subject: [GHC] #8540: Template Haskell handling bug in ghc-7.7.20131115 ? In-Reply-To: <044.a2405e435a0516e234d799c5d8afd594@haskell.org> References: <044.a2405e435a0516e234d799c5d8afd594@haskell.org> Message-ID: <059.ba5a4ce3e0c48a81448c6c60b375989c@haskell.org> #8540: Template Haskell handling bug in ghc-7.7.20131115 ? -------------------------------------+------------------------------------ Reporter: awson | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"c0bca8841570b8c06e15ef95639c79fdeeb16f25/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="c0bca8841570b8c06e15ef95639c79fdeeb16f25" Test Trac #8540 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 22 16:49:39 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Nov 2013 16:49:39 -0000 Subject: [GHC] #8540: Template Haskell handling bug in ghc-7.7.20131115 ? In-Reply-To: <044.a2405e435a0516e234d799c5d8afd594@haskell.org> References: <044.a2405e435a0516e234d799c5d8afd594@haskell.org> Message-ID: <059.10afc0336a3e794f55892a3fe24c5515@haskell.org> #8540: Template Haskell handling bug in ghc-7.7.20131115 ? -------------------------------------+------------------------------------ Reporter: awson | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: th/T8540 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonpj): * status: new => closed * testcase: => th/T8540 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 22 17:19:03 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Nov 2013 17:19:03 -0000 Subject: [GHC] #2850: GeneralizedNewtypeDeriving + TypeFamilies doesn't work In-Reply-To: <042.bfabde61c4aa31a17887ff9436d679ab@haskell.org> References: <042.bfabde61c4aa31a17887ff9436d679ab@haskell.org> Message-ID: <057.52f96e810e0f48befc81a803bdf4899c@haskell.org> #2850: GeneralizedNewtypeDeriving + TypeFamilies doesn't work -------------------------------------------------+------------------------- Reporter: ajd | Owner: Type: feature request | Status: Priority: normal | closed Component: Compiler | Milestone: 6.12 Resolution: fixed | branch Operating System: Unknown/Multiple | Version: Type of failure: None/Unknown | 6.10.1 Test Case: | Keywords: indexed_types/should_compile/T2850 | Architecture: Blocking: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by goldfire): As far as I can tell, my comment above (comment 10) is pure gibberish. There was a thought in my head somewhere, but every time I feel like I'm getting close to it, it runs away. Besides, after a little while trying, I was unable to come up with a relevant example. If there really is an issue here, we'll wait for someone to really hit it and yell. Otherwise, I'll move on. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 22 17:56:29 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Nov 2013 17:56:29 -0000 Subject: [GHC] #8525: lib/integer/integerConstantFolding fails with -DDEBUG In-Reply-To: <046.5d4a4a7e5e2261c32eff470cf125498f@haskell.org> References: <046.5d4a4a7e5e2261c32eff470cf125498f@haskell.org> Message-ID: <061.aa9db2dc0e0b3e8a6027f2d3684676ca@haskell.org> #8525: lib/integer/integerConstantFolding fails with -DDEBUG -------------------------------------------+------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: integerConstantFolding | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------------+------------------------------- Comment (by nomeata): I wasn?t implying that; just the referenced patch marks all tests as broken that were broken by using `-DDEBUG`. I?ll push two patches next time to reduce the confusion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 22 18:28:59 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Nov 2013 18:28:59 -0000 Subject: [GHC] #8548: Coercible does not resolve type family application In-Reply-To: <046.8a91ee19cb9fa713b4f1e9492cfc9689@haskell.org> References: <046.8a91ee19cb9fa713b4f1e9492cfc9689@haskell.org> Message-ID: <061.c521b04625909a4583f207848c9cd4a9@haskell.org> #8548: Coercible does not resolve type family application --------------------------------------------+------------------------------ Reporter: nomeata | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: 8503 | Blocked By: | Related Tickets: #8503 --------------------------------------------+------------------------------ Comment (by Joachim Breitner ): In [changeset:"335031f0cbc03a8d3ba893b0dabb71088665e748/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="335031f0cbc03a8d3ba893b0dabb71088665e748" Extend Coercible to newtype instances This fixes: #8548 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 22 18:29:46 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Nov 2013 18:29:46 -0000 Subject: [GHC] #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough In-Reply-To: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> References: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> Message-ID: <062.6d53561b9a397fe38144c3aec16f602b@haskell.org> #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 8548 Blocking: | Related Tickets: #8541 -------------------------------------+------------------------------------ Comment (by Joachim Breitner ): In [changeset:"6468beebcf2b3a2dd9cbedd7b6dc9c7adaee626b/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="6468beebcf2b3a2dd9cbedd7b6dc9c7adaee626b" Add test cases for Coercing recursive newtypes (#8503) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 22 18:29:46 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Nov 2013 18:29:46 -0000 Subject: [GHC] #8548: Coercible does not resolve type family application In-Reply-To: <046.8a91ee19cb9fa713b4f1e9492cfc9689@haskell.org> References: <046.8a91ee19cb9fa713b4f1e9492cfc9689@haskell.org> Message-ID: <061.a30c888fda8d453feb24f7dba6518874@haskell.org> #8548: Coercible does not resolve type family application --------------------------------------------+------------------------------ Reporter: nomeata | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: 8503 | Blocked By: | Related Tickets: #8503 --------------------------------------------+------------------------------ Comment (by Joachim Breitner ): In [changeset:"8949a7cc453a7aec9bbcb752a07c140c2f15a619/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="8949a7cc453a7aec9bbcb752a07c140c2f15a619" Testcase for Coercible and newtype families (#8548) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 22 18:29:46 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Nov 2013 18:29:46 -0000 Subject: [GHC] #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough In-Reply-To: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> References: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> Message-ID: <062.a2e323196c8b55b7b4735af3d3340573@haskell.org> #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 8548 Blocking: | Related Tickets: #8541 -------------------------------------+------------------------------------ Comment (by Joachim Breitner ): In [changeset:"94128d393c820ed82f61052414cc1ffde8b2af82/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="94128d393c820ed82f61052414cc1ffde8b2af82" Updates perf numbers after #8503 implementation }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 22 18:37:12 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Nov 2013 18:37:12 -0000 Subject: [GHC] #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough In-Reply-To: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> References: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> Message-ID: <062.6572725ca179607b32a546de8151986a@haskell.org> #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 8548 Blocking: | Related Tickets: #8541 -------------------------------------+------------------------------------ Comment (by nomeata): Ok, pushed. Closing this ticket (is is far too long anyways, and trac spends too much time generating it), so any new issues with `Coercible` or GND please in new tickets. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 22 19:58:03 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Nov 2013 19:58:03 -0000 Subject: [GHC] #8537: confusing error message for specialize pragma In-Reply-To: <045.832f7ac508c2d7554c2e9563deea3e66@haskell.org> References: <045.832f7ac508c2d7554c2e9563deea3e66@haskell.org> Message-ID: <060.9174d3e9a23a6d87dcc39744e1de8528@haskell.org> #8537: confusing error message for specialize pragma -------------------------------------------------+------------------------- Reporter: carter | Owner: Type: bug | Status: Priority: normal | closed Component: Compiler | Milestone: Resolution: fixed | Version: 7.6.3 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: | Unknown/Multiple simplCore/should_compile/T8537 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by carter): great! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 22 20:11:13 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Nov 2013 20:11:13 -0000 Subject: [GHC] #8553: ASSERT failed compiler/typecheck/TcMType.lhs line 809 In-Reply-To: <046.c98e70d0ceeae727c974fb11a22a1bd7@haskell.org> References: <046.c98e70d0ceeae727c974fb11a22a1bd7@haskell.org> Message-ID: <061.c92e0fea5c3635c414ee04f701f3556b@haskell.org> #8553: ASSERT failed compiler/typecheck/TcMType.lhs line 809 --------------------------------------------+------------------------------ Reporter: nomeata | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: gadt6 T7474 T5246 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by Joachim Breitner ): In [changeset:"81a49bcc84f27245d11c5b151d41b2026a5a6602/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="81a49bcc84f27245d11c5b151d41b2026a5a6602" T5246 and T7474 back working with -DDEBUG thanks to SPJ'S fixes for #8553 in 985663ea47487a9e567814ba000e81d65358bf02 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 22 21:08:39 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Nov 2013 21:08:39 -0000 Subject: [GHC] #8556: Invalid constructor names are accepted in data declarations Message-ID: <044.fea5fff11e5ec10e023034a4e71b90cb@haskell.org> #8556: Invalid constructor names are accepted in data declarations ------------------------------------+------------------------------------- Reporter: dolio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Earlier today, someone was asking on #haskell why the constructor name {{{(^)}}} wouldn't work in GADT definitions. My response was that {{{(^)}}} isn't a constructor name, but much to my surprise, GHC accepts such names in a regular data declaration: {{{ data Foo = F | (^^^^) Int Int }}} This creates a {{{Foo}}} type and value constructor {{{F}}}, but no value constructor {{{(^^^^)}}}. However, in 7.6.3, if DataKinds are enabled, both constructors appear at the type level. In HEAD, the same definition is accepted, with only {{{F}}} existing at the value level, as before. But at the type level, both {{{F}}} and {{{(^^^^)}}} just generate errors that {{{Foo}}} is not a promotable type. At that point, I think there's no question that the declaration should just be ruled out. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 22 21:20:33 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Nov 2013 21:20:33 -0000 Subject: [GHC] #8556: Invalid constructor names are accepted in data declarations In-Reply-To: <044.fea5fff11e5ec10e023034a4e71b90cb@haskell.org> References: <044.fea5fff11e5ec10e023034a4e71b90cb@haskell.org> Message-ID: <059.040f6512cc966899f7310a4bdfd6adeb@haskell.org> #8556: Invalid constructor names are accepted in data declarations -------------------------------------+------------------------------------ Reporter: dolio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by monoidal): What about `data Foo a = F | (^^^^) a a`? This is promotable, e.g. `Maybe ^^^^ Maybe :: Foo (* -> *)`. My suggestion is to postpone this till implementing KindsWithoutData, and then we can forbid `data Foo a = F | (^^^^) a a` but allow `data kind Foo a = F | (^^^^) a a`. See also #7725. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 22 21:46:45 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Nov 2013 21:46:45 -0000 Subject: [GHC] #8557: Panic "tcTyVarDetails" when :forcing a kind-polymorphic data family instance Message-ID: <047.ee19f9cb863bee77e253732f4bf91ce3@haskell.org> #8557: Panic "tcTyVarDetails" when :forcing a kind-polymorphic data family instance ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I have {{{ {-# LANGUAGE TypeFamilies, DataKinds, PolyKinds #-} data family Sing (a :: k) data instance Sing (a :: [k]) = SNil x :: Sing '[] x = SNil }}} When I load into GHCi and tried to force `x`, this happened: {{{ *Main> :force x ghc: panic! (the 'impossible' happened) (GHC version 7.7.20131031 for x86_64-apple-darwin): tcTyVarDetails k{tv a3Gv} [tv] }}} This was tested on the build from Oct 31 -- apologies if it has since been fixed. If I make the `[k]` in the instance declaration `k`, the file compiles fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 22 21:50:01 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Nov 2013 21:50:01 -0000 Subject: [GHC] #8540: Template Haskell handling bug in ghc-7.7.20131115 ? In-Reply-To: <044.a2405e435a0516e234d799c5d8afd594@haskell.org> References: <044.a2405e435a0516e234d799c5d8afd594@haskell.org> Message-ID: <059.f7016cce89582ef771ec07d96151cf9b@haskell.org> #8540: Template Haskell handling bug in ghc-7.7.20131115 ? -------------------------------------+------------------------------------ Reporter: awson | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: th/T8540 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by nomeata): * status: closed => new * resolution: fixed => Comment: I believe this change causes test failures to fail with assertions (at least it touches the location of the assertion): {{{ =====> print019(ghci) 2936 of 3831 [0, 0, 0] cd ./ghci.debugger/scripts && HC='/home/jojo/build/haskell/ghc/inplace/bin /ghc-stage2' HC_OPTS='-dcore-lint -dcmm-lint -dno-debug-output -no-user- package-db -rtsopts -fno-ghci-history ' '/home/jojo/build/haskell/ghc/inplace/bin/ghc-stage2' --interactive -v0 -ignore-dot-ghci -dcore-lint -dcmm-lint -dno-debug-output -no-user- package-db -rtsopts -fno-ghci-history -ignore-dot-ghci print019.run.stdout 2>print019.run.stderr Actual stderr output differs from expected: --- ./ghci.debugger/scripts/print019.stderr 2013-09-13 20:58:44.089042446 +0100 +++ ./ghci.debugger/scripts/print019.run.stderr 2013-11-22 21:47:09.304630865 +0000 @@ -1,12 +1,9 @@ +ghc-stage2: panic! (the 'impossible' happened) + (GHC version 7.7.20131108 for x86_64-unknown-linux): + ASSERT failed! + file compiler/typecheck/TcEnv.lhs line 467 + it{v a1C8} [lid] + a1{tv a1w5} [rt] + +Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -:11:1: - No instance for (Show a1) arising from a use of ?print? - Cannot resolve unknown runtime type ?a1? - Use :print or :force to determine these types - Relevant bindings include it :: a1 (bound at :11:1) - Note: there are several potential instances: - instance Show a => Show (List1 a) -- Defined at ../Test.hs:11:12 - instance Show MyInt -- Defined at ../Test.hs:14:16 - instance Show a => Show (MkT a) -- Defined at ../Test.hs:17:13 - ...plus 32 others - In a stmt of an interactive GHCi command: print it *** unexpected failure for print019(ghci) =====> break003(ghci) 2955 of 3831 [0, 1, 0] cd ./ghci.debugger/scripts && HC='/home/jojo/build/haskell/ghc/inplace/bin /ghc-stage2' HC_OPTS='-dcore-lint -dcmm-lint -dno-debug-output -no-user- package-db -rtsopts -fno-ghci-history ' '/home/jojo/build/haskell/ghc/inplace/bin/ghc-stage2' --interactive -v0 -ignore-dot-ghci -dcore-lint -dcmm-lint -dno-debug-output -no-user- package-db -rtsopts -fno-ghci-history -ignore-dot-ghci break003.run.stdout 2>break003.run.stderr Actual stderr output differs from expected: --- ./ghci.debugger/scripts/break003.stderr 2013-09-02 15:07:33.148355402 +0100 +++ ./ghci.debugger/scripts/break003.run.stderr 2013-11-22 21:47:09.528630856 +0000 @@ -1,4 +1,9 @@ +ghc-stage2: panic! (the 'impossible' happened) + (GHC version 7.7.20131108 for x86_64-unknown-linux): + ASSERT failed! + file compiler/typecheck/TcEnv.lhs line 467 + it{v aR1} [lid] + t{tv IQD} [rt] -> t1{tv IQE} [rt] + +Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -:5:1: - No instance for (Show (t -> t1)) arising from a use of ?print? - In a stmt of an interactive GHCi command: print it *** unexpected failure for break003(ghci) =====> break006(ghci) 2957 of 3831 [0, 2, 0] cd ./ghci.debugger/scripts && HC='/home/jojo/build/haskell/ghc/inplace/bin /ghc-stage2' HC_OPTS='-dcore-lint -dcmm-lint -dno-debug-output -no-user- package-db -rtsopts -fno-ghci-history ' '/home/jojo/build/haskell/ghc/inplace/bin/ghc-stage2' --interactive -v0 -ignore-dot-ghci -dcore-lint -dcmm-lint -dno-debug-output -no-user- package-db -rtsopts -fno-ghci-history -ignore-dot-ghci break006.run.stdout 2>break006.run.stderr Actual stderr output differs from expected: --- ./ghci.debugger/scripts/break006.stderr 2013-09-13 20:58:44.085042446 +0100 +++ ./ghci.debugger/scripts/break006.run.stderr 2013-11-22 21:47:09.764630848 +0000 @@ -1,26 +1,33 @@ +ghc-stage2: panic! (the 'impossible' happened) + (GHC version 7.7.20131108 for x86_64-unknown-linux): + ASSERT failed! + file compiler/typecheck/TcEnv.lhs line 467 + it{v aX8} [lid] + t1{tv IWQ} [rt] + +Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug + +ghc-stage2: panic! (the 'impossible' happened) + (GHC version 7.7.20131108 for x86_64-unknown-linux): + ASSERT failed! + file compiler/typecheck/TcEnv.lhs line 467 + y{v aYb} [lid] + t1{tv IWQ} [rt] + +Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug + + +:8:1: Not in scope: ?y? + +Top level: Not in scope: ?y? + +Top level: Not in scope: ?y? +ghc-stage2: panic! (the 'impossible' happened) + (GHC version 7.7.20131108 for x86_64-unknown-linux): + ASSERT failed! + file compiler/typecheck/TcEnv.lhs line 467 + it{v aYm} [lid] + t1{tv IWQ} [rt] + +Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -:6:1: - No instance for (Show t1) arising from a use of ?print? - Cannot resolve unknown runtime type ?t1? - Use :print or :force to determine these types - Relevant bindings include it :: t1 (bound at :6:1) - Note: there are several potential instances: - instance Show Double -- Defined in ?GHC.Float? - instance Show Float -- Defined in ?GHC.Float? - instance (Integral a, Show a) => Show (GHC.Real.Ratio a) - -- Defined in ?GHC.Real? - ...plus 24 others - In a stmt of an interactive GHCi command: print it - -:8:1: - No instance for (Show t1) arising from a use of ?print? - Cannot resolve unknown runtime type ?t1? - Use :print or :force to determine these types - Relevant bindings include it :: t1 (bound at :8:1) - Note: there are several potential instances: - instance Show Double -- Defined in ?GHC.Float? - instance Show Float -- Defined in ?GHC.Float? - instance (Integral a, Show a) => Show (GHC.Real.Ratio a) - -- Defined in ?GHC.Real? - ...plus 24 others - In a stmt of an interactive GHCi command: print it Actual stdout output differs from expected: --- ./ghci.debugger/scripts/break006.stdout 2013-09-02 15:07:33.148355402 +0100 +++ ./ghci.debugger/scripts/break006.run.stdout 2013-11-22 21:47:09.760630848 +0000 @@ -9,12 +9,7 @@ x :: Integer = 1 f :: Integer -> t1 = _ _result :: [t1] = _ -y = (_t1::t1) -y = 2 xs :: [Integer] = [2,3] x :: Integer = 1 -f :: Integer -> Integer = _ -_result :: [Integer] = _ -y :: Integer = 2 -_t1 :: Integer = 2 -2 +f :: Integer -> t1 = _ +_result :: [t1] = _ *** unexpected failure for break006(ghci) Unexpected results from: TEST="break006 break003 print019" }}} (I hope this ?but it breaks my `-DDEBUG`? barfing is not too annoying...) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 22 21:50:44 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Nov 2013 21:50:44 -0000 Subject: [GHC] #8548: Coercible does not resolve type family application In-Reply-To: <046.8a91ee19cb9fa713b4f1e9492cfc9689@haskell.org> References: <046.8a91ee19cb9fa713b4f1e9492cfc9689@haskell.org> Message-ID: <061.7c28002de3ca591e6007068375391f12@haskell.org> #8548: Coercible does not resolve type family application --------------------------------------------+------------------------------ Reporter: nomeata | Owner: nomeata Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: 8503 | Blocked By: | Related Tickets: #8503 --------------------------------------------+------------------------------ Changes (by nomeata): * status: new => closed * resolution: => fixed Comment: This has hit master together with the changes for #8503, closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 22 21:50:51 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Nov 2013 21:50:51 -0000 Subject: [GHC] #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough In-Reply-To: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> References: <047.6b95e16715dce14fab21d5d759c34093@haskell.org> Message-ID: <062.26fcafc18204de5ce2d72051c158491c@haskell.org> #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 8548 Blocking: | Related Tickets: #8541 -------------------------------------+------------------------------------ Changes (by nomeata): * status: new => closed * resolution: => fixed Comment: It seems that trac does not do NLP, but Richard does. So again: Closing the ticket... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 22 21:54:29 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Nov 2013 21:54:29 -0000 Subject: [GHC] #8555: Simplify given `Coercible` constraints In-Reply-To: <046.a1497cad7416e0b2528d2d39ab4215f8@haskell.org> References: <046.a1497cad7416e0b2528d2d39ab4215f8@haskell.org> Message-ID: <061.4df9a7130a6f588b56a4bfa19e81e855@haskell.org> #8555: Simplify given `Coercible` constraints ----------------------------------------------+---------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8503 ----------------------------------------------+---------------------------- Comment (by goldfire): Certainly nothing blocking this at the Core level... the `Nth` coercion constructor would do the right thing here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 22 21:57:51 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Nov 2013 21:57:51 -0000 Subject: [GHC] #8556: Invalid constructor names are accepted in data declarations In-Reply-To: <044.fea5fff11e5ec10e023034a4e71b90cb@haskell.org> References: <044.fea5fff11e5ec10e023034a4e71b90cb@haskell.org> Message-ID: <059.08583497885012a88692407917b19520@haskell.org> #8556: Invalid constructor names are accepted in data declarations -------------------------------------+------------------------------------ Reporter: dolio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by monoidal): Here's a simple fix for 7.7 discussed on IRC: Writing a data declaration which contains at least one operator not starting with : should require -XDataKinds. So if you write `data A a = (&) a a` you have to enable DataKinds, since the `(&)` is available only in the promoted form. After KindsWithoutData get merged we will forbid it completely by changing the test to unconditional error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 22 21:58:46 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Nov 2013 21:58:46 -0000 Subject: [GHC] #7725: Operators without colons In-Reply-To: <047.40372880668cc29eb1d7fa48ba885ac2@haskell.org> References: <047.40372880668cc29eb1d7fa48ba885ac2@haskell.org> Message-ID: <062.4aecb979bdf96dab017cf2c7216e9096@haskell.org> #7725: Operators without colons ------------------------------------------------+-------------------------- Reporter: monoidal | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts invalid program | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by monoidal): * status: new => closed * resolution: => duplicate Comment: Closing in favor of #8556. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 22 22:59:38 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Nov 2013 22:59:38 -0000 Subject: [GHC] #8128: Standalone deriving fails for GADTs due to inaccessible code In-Reply-To: <049.b5f919d61189346fb956f5afd152d2c9@haskell.org> References: <049.b5f919d61189346fb956f5afd152d2c9@haskell.org> Message-ID: <064.dd8248cc00934dbe6e6e90c60bb08e95@haskell.org> #8128: Standalone deriving fails for GADTs due to inaccessible code ----------------------------------------------+---------------------------- Reporter: adamgundry | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by carter): I'm hitting some example GADT code where the "type erasure" of the GADT type would be yield the correct code for the GADT deriving, I'd be interested in helping take a whack at this sometime after december (2013). I also seem to getting a failure of Typeable on Datakinds! See the end for the Example. That sounds worrisome! {{{ {-# LANGUAGE PolyKinds #-} {-# LANGUAGE BangPatterns #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE DeriveDataTypeable #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE StandaloneDeriving #-} {-# LANGUAGE CPP #-} {-# LANGUAGE DeriveFunctor #-} {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE NoImplicitPrelude #-} module Numerical.Types.Shape where data Nat = S !Nat | Z deriving (Eq,Show,Read,) data Shape (rank :: Nat) a where Nil :: Shape Z a (:*) :: !(a) -> !(Shape r a ) -> Shape (S r) a --deriving (Eq) --deriving instance Eq a => Eq (Shape Z a) }}} Interestingly, I can derive a Typeable instance for the Shape data type, but NOT a Data instances when i do a {{{ data Shape .... deriving (Typeable,Data) }}} I get {{{ Numerical/Types/Shape.hs:57:28: Can't make a derived instance of ?Data (Shape rank a)?: Constructor ?Nil? must have a Haskell-98 type Constructor ?:*? must have a Haskell-98 type Possible fix: use a standalone deriving declaration instead In the data declaration for ?Shape? Failed, modules loaded: Numerical.Types.Nat. *Numerical.Types.Nat> }}} when i then follow that suggestion and do a standalone deriving I get {{{ deriving instance (Data a) => Data (Shape n a) }}} I then get this lovely message {{{ [2 of 2] Compiling Numerical.Types.Shape ( Numerical/Types/Shape.hs, interpreted ) Numerical/Types/Shape.hs:59:1: Could not deduce (Typeable n) arising from the superclasses of an instance declaration from the context (Data a) bound by the instance declaration at Numerical/Types/Shape.hs:59:1-48 In the instance declaration for ?Data (Shape n a)? Numerical/Types/Shape.hs:59:1: Could not deduce (Typeable r) arising from a use of ?k? from the context (Typeable (Shape n a), Data a) bound by the instance declaration at Numerical/Types/Shape.hs:59:1-48 or from (n ~ 'S r) bound by a pattern with constructor :* :: forall a (r :: Nat). a -> Shape r a -> Shape ('S r) a, in an equation for ?gfoldl? at Numerical/Types/Shape.hs:59:1-48 In the expression: ((z (:*) `k` a1) `k` a2) In an equation for ?gfoldl?: gfoldl k z ((:*) a1 a2) = ((z (:*) `k` a1) `k` a2) When typechecking the code for ?gfoldl? in a standalone derived instance for ?Data (Shape n a)?: To see the code I am typechecking, use -ddump-deriv In the instance declaration for ?Data (Shape n a)? Numerical/Types/Shape.hs:59:1: Couldn't match type ?'Z? with ?'S r0? Expected type: a -> Shape r0 a -> Shape n a Actual type: a -> Shape r0 a -> Shape ('S r0) a In the first argument of ?z?, namely ?(:*)? In the first argument of ?k?, namely ?z (:*)? When typechecking the code for ?gunfold? in a standalone derived instance for ?Data (Shape n a)?: To see the code I am typechecking, use -ddump-deriv Failed, modules loaded: Numerical.Types.Nat. }}} I then tried the following to keep it simple {{{ deriving instance (Data a)=> Data (Shape Z a) }}} and got {{{ 2 of 2] Compiling Numerical.Types.Shape ( Numerical/Types/Shape.hs, interpreted ) Numerical/Types/Shape.hs:60:1: Could not deduce (Typeable 'Z) arising from the superclasses of an instance declaration from the context (Data a) bound by the instance declaration at Numerical/Types/Shape.hs:60:1-45 In the instance declaration for ?Data (Shape 'Z a)? Numerical/Types/Shape.hs:60:1: Couldn't match type ?'Z? with ?'S r? Inaccessible code in a pattern with constructor :* :: forall a (r :: Nat). a -> Shape r a -> Shape ('S r) a, in an equation for ?gfoldl? In the pattern: (:*) a1 a2 In an equation for ?gfoldl?: gfoldl k z ((:*) a1 a2) = ((z (:*) `k` a1) `k` a2) When typechecking the code for ?gfoldl? in a standalone derived instance for ?Data (Shape 'Z a)?: To see the code I am typechecking, use -ddump-deriv In the instance declaration for ?Data (Shape 'Z a)? Numerical/Types/Shape.hs:60:1: Couldn't match type ?'S r0? with ?'Z? Expected type: a -> Shape r0 a -> Shape 'Z a Actual type: a -> Shape r0 a -> Shape ('S r0) a In the first argument of ?z?, namely ?(:*)? In the first argument of ?k?, namely ?z (:*)? When typechecking the code for ?gunfold? in a standalone derived instance for ?Data (Shape 'Z a)?: To see the code I am typechecking, use -ddump-deriv Numerical/Types/Shape.hs:60:1: Couldn't match type ?'Z? with ?'S r? Inaccessible code in a pattern with constructor :* :: forall a (r :: Nat). a -> Shape r a -> Shape ('S r) a, in an equation for ?toConstr? In the pattern: (:*) _ _ In an equation for ?toConstr?: toConstr ((:*) _ _) = (Numerical.Types.Shape.$c:*) When typechecking the code for ?toConstr? in a standalone derived instance for ?Data (Shape 'Z a)?: To see the code I am typechecking, use -ddump-deriv In the instance declaration for ?Data (Shape 'Z a)? Failed, modules loaded: Numerical.Types.Nat. }}} The Typeable 'Z thing is a bit odd! This is on a recent copy of head, built in the past month... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 22 23:56:11 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Nov 2013 23:56:11 -0000 Subject: [GHC] #8558: Build xhtml and haddock only when `HADDOCK_DOCS=YES` Message-ID: <046.58d7da5028bf9a8ae08210a8bd83e6b5@haskell.org> #8558: Build xhtml and haddock only when `HADDOCK_DOCS=YES` ------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- In order to save contributor?s time, and in order to run the test suite faster, I suggest to not builds haddock and its dependencies (xhtml, anything else?) if `HADDOCK_DOCS=YES` is specified. The change is rather simple: {{{ diff --git a/ghc.mk b/ghc.mk index dd91a82..b0f93a0 100644 --- a/ghc.mk +++ b/ghc.mk @@ -437,7 +437,9 @@ REGULAR_INSTALL_PACKAGES += compiler endif REGULAR_INSTALL_PACKAGES += $(addprefix libraries/,$(PACKAGES_STAGE2)) +ifeq "$(HADDOCK_DOCS)" "YES" PACKAGES_STAGE1 += xhtml +endif ifeq "$(Windows_Target)" "NO" ifneq "$(TargetOS_CPP)" "ios" PACKAGES_STAGE1 += terminfo @@ -652,8 +654,10 @@ BUILD_DIRS += libraries/integer-gmp/gmp BUILD_DIRS += libraries/integer-gmp/mkGmpDerivedConstants endif +ifeq "$(HADDOCK_DOCS)" "YES" BUILD_DIRS += utils/haddock BUILD_DIRS += utils/haddock/doc +endif BUILD_DIRS += compiler BUILD_DIRS += utils/hsc2hs BUILD_DIRS += utils/ghc-pkg }}} and it does not affect validate runs, as validate has `HADDOCK_DOCS` set to `YES`. If this is introduced, I suggest to annotate these two with a tag in packages, so that one can run `./sync-all get --no-haddock`, similar to `--no-dph`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 23 09:50:51 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Nov 2013 09:50:51 -0000 Subject: [GHC] #8559: Compiling dph-lifted fails with "NoSpecConstr" not in scope Message-ID: <047.bfd0a661fd10de18ea4220effdf6c9b9@haskell.org> #8559: Compiling dph-lifted fails with "NoSpecConstr" not in scope -------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Data Parallel | Version: 7.7 Haskell | Operating System: Linux Keywords: | Type of failure: Building GHC Architecture: powerpc64 | failed Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Building ghc-7.7.20131120 fails with this on powerpc64 Linux: {{{ "inplace/bin/ghc-stage2" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -package-name dph-lifted-copy-0.8.0.1 -hide-all-packages -i -ilibraries/dph/dph-lifted-copy/. -ilibraries/dph/dph-lifted-copy/dist- install/build -ilibraries/dph/dph-lifted-copy/dist-install/build/autogen -Ilibraries/dph/dph-lifted-copy/dist-install/build -Ilibraries/dph/dph- lifted-copy/dist-install/build/autogen -Ilibraries/dph/dph-lifted-copy/. -optP-include -optPlibraries/dph/dph-lifted-copy/dist- install/build/autogen/cabal_macros.h -package array-0.5.0.0 -package base-4.7.0.0 -package dph-base-0.8.0.1 -package dph-prim-par-0.8.0.1 -package ghc-7.7.20131115 -package random-1.0.1.1 -package template- haskell-2.9.0.0 -package vector-0.10.9.1 -Odph -funbox-strict-fields -fcpr-off -fno-warn-orphans -fno-warn-missing-signatures -XHaskell98 -XTypeFamilies -XGADTs -XRankNTypes -XBangPatterns -XMagicHash -XUnboxedTuples -XTypeOperators -O2 -no-user-package-db -rtsopts -odir libraries/dph/dph-lifted-copy/dist-install/build -hidir libraries/dph/dph-lifted-copy/dist-install/build -stubdir libraries/dph /dph-lifted-copy/dist-install/build -c libraries/dph/dph-lifted- copy/./Data/Array/Parallel/PArray/PData.hs -o libraries/dph/dph-lifted- copy/dist-install/build/Data/Array/Parallel/PArray/PData.o [23775s] [23775s] libraries/dph/dph-lifted- copy/Data/Array/Parallel/PArray/PData.hs:49:20: [23775s] Not in scope: data constructor `NoSpecConstr' [23775s] make[1]: *** [libraries/dph/dph-lifted-copy/dist- install/build/Data/Array/Parallel/PArray/PData.o] Error 1 [23775s] make: *** [all] Error 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 23 10:32:17 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Nov 2013 10:32:17 -0000 Subject: [GHC] #8558: Build xhtml and haddock only when `HADDOCK_DOCS=YES` In-Reply-To: <046.58d7da5028bf9a8ae08210a8bd83e6b5@haskell.org> References: <046.58d7da5028bf9a8ae08210a8bd83e6b5@haskell.org> Message-ID: <061.4d09e7db84a0403aa4da1c934f976b53@haskell.org> #8558: Build xhtml and haddock only when `HADDOCK_DOCS=YES` -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by hvr): > I suggest to not builds haddock and its dependencies (xhtml, anything else?) if HADDOCK_DOCS=YES is specified. There's a negation-typo in there, right? Your proposal looks good to me. However, wrt to the package-tag suggestion: I think the tag column in `packages` makes the build-system a bit more complicated just to save cloning/syncing a few small repositories; and as a side-effect of #8545 I was planing to get rid of the package-tags altogether. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 23 19:42:38 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Nov 2013 19:42:38 -0000 Subject: [GHC] #8560: undeducable Typeable error with data kinds when deriving Data for GADT in GHC version 7.7.20131122 Message-ID: <045.08c7497f3d39ab287608a0acc7513dc1@haskell.org> #8560: undeducable Typeable error with data kinds when deriving Data for GADT in GHC version 7.7.20131122 ------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- This may be an artifact of issue #8128 (see https://ghc.haskell.org/trac/ghc/ticket/8128#comment:5), but I'm seeing examples involving data kinds where Typeable isn't deducible. This could be an artifact of other problems, BUT since with 7.7 onwards, we have baked in polykinded Typeable, things should always "just work?" right? the error with current head is as follows (and i'm attaching the code + current finger print too) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 23 19:44:09 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Nov 2013 19:44:09 -0000 Subject: [GHC] #8560: undeducable Typeable error with data kinds when deriving Data for GADT in GHC version 7.7.20131122 In-Reply-To: <045.08c7497f3d39ab287608a0acc7513dc1@haskell.org> References: <045.08c7497f3d39ab287608a0acc7513dc1@haskell.org> Message-ID: <060.a75d89f4c8e5222f3c48bcd5a3202aa7@haskell.org> #8560: undeducable Typeable error with data kinds when deriving Data for GADT in GHC version 7.7.20131122 -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by dreixel): Thanks for the report, I'll have a look. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 23 19:58:35 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Nov 2013 19:58:35 -0000 Subject: [GHC] #8560: undeducable Typeable error with data kinds when deriving Data for GADT in GHC version 7.7.20131122 In-Reply-To: <045.08c7497f3d39ab287608a0acc7513dc1@haskell.org> References: <045.08c7497f3d39ab287608a0acc7513dc1@haskell.org> Message-ID: <060.7772602a08c3ce25e730804db0353360@haskell.org> #8560: undeducable Typeable error with data kinds when deriving Data for GADT in GHC version 7.7.20131122 -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by carter): the error message itself is the "cannot deduce typeable" piece of the following {{{ [1 of 1] Compiling Test ( test.hs, interpreted ) test.hs:33:1: No instance for (Typeable n) arising from the superclasses of an instance declaration In the instance declaration for ?Data (Shape n a)? test.hs:33:1: Could not deduce (Typeable r) arising from a use of ?k? from the context (Typeable (Shape n a)) bound by the instance declaration at test.hs:33:1-34 or from (n ~ 'S r) bound by a pattern with constructor :* :: forall a (r :: Nat). a -> Shape r a -> Shape ('S r) a, in an equation for ?gfoldl? at test.hs:33:1-34 In the expression: ((z (:*) `k` a1) `k` a2) In an equation for ?gfoldl?: gfoldl k z ((:*) a1 a2) = ((z (:*) `k` a1) `k` a2) When typechecking the code for ?gfoldl? in a standalone derived instance for ?Data (Shape n a)?: To see the code I am typechecking, use -ddump-deriv In the instance declaration for ?Data (Shape n a)? test.hs:33:1: Could not deduce (n ~ 'Z) from the context (Typeable (Shape n a)) bound by the instance declaration at test.hs:33:1-34 ?n? is a rigid type variable bound by the instance declaration at test.hs:33:19 Expected type: Shape n a Actual type: Shape 'Z a Relevant bindings include gunfold :: (forall b r. Data b => c (b -> r) -> c r) -> (forall r. r -> c r) -> Constr -> c (Shape n a) (bound at test.hs:33:1) In the first argument of ?z?, namely ?Nil? In the expression: z Nil When typechecking the code for ?gunfold? in a standalone derived instance for ?Data (Shape n a)?: To see the code I am typechecking, use -ddump-deriv test.hs:33:1: Overlapping instances for Typeable (Shape r0 a) arising from a use of ?k? Matching givens (or their superclasses): (Typeable (Shape n a)) bound by the instance declaration at test.hs:33:1-34 Matching instances: instance [overlap ok] (Typeable s, Typeable a) => Typeable (s a) -- Defined in ?Data.Typeable.Internal? (The choice depends on the instantiation of ?a, r0?) In the expression: k (k (z (:*))) In a case alternative: _ -> k (k (z (:*))) In the expression: case constrIndex c of { GHC.Types.I# 1# -> z Nil _ -> k (k (z (:*))) } When typechecking the code for ?gunfold? in a standalone derived instance for ?Data (Shape n a)?: To see the code I am typechecking, use -ddump-deriv Failed, modules loaded: none. }}} it may be the case that its a spurious piece of the deriving GADT instances problem -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 23 21:48:03 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Nov 2013 21:48:03 -0000 Subject: [GHC] #8128: Standalone deriving fails for GADTs due to inaccessible code In-Reply-To: <049.b5f919d61189346fb956f5afd152d2c9@haskell.org> References: <049.b5f919d61189346fb956f5afd152d2c9@haskell.org> Message-ID: <064.678223cd770c879b8b0c298373d9e17b@haskell.org> #8128: Standalone deriving fails for GADTs due to inaccessible code ----------------------------------------------+---------------------------- Reporter: adamgundry | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by monoidal): @carter: Regarding `Typeable 'Z`, you just need to write `deriving instance Typeable 'Z` and likewise for 'N. I don't know what's going on with `Data`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 23 21:57:04 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Nov 2013 21:57:04 -0000 Subject: [GHC] #8561: Clang/iOS: __builtin___clear_cache doesn't exist in clang, use __clear_cache instead Message-ID: <045.fb8c4675779e8bc63ac8ffba3bcfbb67@haskell.org> #8561: Clang/iOS: __builtin___clear_cache doesn't exist in clang, use __clear_cache instead -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Other Architecture: Unknown/Multiple | Type of failure: Building GHC Difficulty: Easy (less than 1 | failed hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- The __builtin___clear_cache from GCC is just called __clear_cache with clang, and must be declared. Otherwise the build fails (introduced in https://github.com/ghc/ghc/commit/5bab1a57f572e29dfdffd6d1ce8e53a2772b18fd) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 23 22:09:48 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Nov 2013 22:09:48 -0000 Subject: [GHC] #8561: Clang/iOS: __builtin___clear_cache doesn't exist in clang, use __clear_cache instead In-Reply-To: <045.fb8c4675779e8bc63ac8ffba3bcfbb67@haskell.org> References: <045.fb8c4675779e8bc63ac8ffba3bcfbb67@haskell.org> Message-ID: <060.2df4c6477664ecc5cb9173d48116af6e@haskell.org> #8561: Clang/iOS: __builtin___clear_cache doesn't exist in clang, use __clear_cache instead -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Other | Architecture: Unknown/Multiple Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by lukexi): Actually, __clear_cache seems to be missing entirely on iOS, so I'm not sure what to do here. (I found a reference to someone reimplementing it in assembly? http://permalink.gmane.org/gmane.comp.lang.pcre.devel/1986) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 23 22:19:22 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Nov 2013 22:19:22 -0000 Subject: [GHC] #8561: Clang/iOS: __builtin___clear_cache doesn't exist in clang, use __clear_cache instead In-Reply-To: <045.fb8c4675779e8bc63ac8ffba3bcfbb67@haskell.org> References: <045.fb8c4675779e8bc63ac8ffba3bcfbb67@haskell.org> Message-ID: <060.6a841b54dd52e69404cfe0df37e70bef@haskell.org> #8561: Clang/iOS: __builtin___clear_cache doesn't exist in clang, use __clear_cache instead -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Other | Architecture: Unknown/Multiple Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by thoughtpolice): A few years ago I helped Mike Pall (of LuaJIT) dig into using the JIT component on iOS, which involved finding a way to clear the icache. I dug up the code. On Darwin, the trick seems to be `sys_icache_invalidate`: http://repo.or.cz/w/luajit-2.0.git/blob/HEAD:/src/lj_mcode.c#l31 I imagine this still works, but I can't test it (I no longer have a jailbroken iOS device where the JIT would work.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 23 23:42:23 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Nov 2013 23:42:23 -0000 Subject: [GHC] #8560: undeducable Typeable error with data kinds when deriving Data for GADT in GHC version 7.7.20131122 In-Reply-To: <045.08c7497f3d39ab287608a0acc7513dc1@haskell.org> References: <045.08c7497f3d39ab287608a0acc7513dc1@haskell.org> Message-ID: <060.8d5c47d6dd9d6190a61d75fc706042d8@haskell.org> #8560: undeducable Typeable error with data kinds when deriving Data for GADT in GHC version 7.7.20131122 -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by carter): the key bit is that however I add typeable info for the datakind level variant of Nat, i get {{{ test.hs:33:1: No instance for (Typeable n) arising from the superclasses of an instance declaration In the instance declaration for ?Data (Shape ('S n) a)? }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 23 23:46:38 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Nov 2013 23:46:38 -0000 Subject: [GHC] #8128: Standalone deriving fails for GADTs due to inaccessible code In-Reply-To: <049.b5f919d61189346fb956f5afd152d2c9@haskell.org> References: <049.b5f919d61189346fb956f5afd152d2c9@haskell.org> Message-ID: <064.cc4180c829c8a2c9f5a7995042e040c2@haskell.org> #8128: Standalone deriving fails for GADTs due to inaccessible code ----------------------------------------------+---------------------------- Reporter: adamgundry | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by carter): @monoidal, yup. That works out fine. Though see https://ghc.haskell.org/trac/ghc/ticket/8560#comment:3 for a possibly related issue. (though it may just be a spurious artifact of this one, not sure) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 23 23:53:23 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Nov 2013 23:53:23 -0000 Subject: [GHC] #8561: Clang/iOS: __builtin___clear_cache doesn't exist in clang, use __clear_cache instead In-Reply-To: <045.fb8c4675779e8bc63ac8ffba3bcfbb67@haskell.org> References: <045.fb8c4675779e8bc63ac8ffba3bcfbb67@haskell.org> Message-ID: <060.05ad7898c38da32548eed38c87abacd5@haskell.org> #8561: Clang/iOS: __builtin___clear_cache doesn't exist in clang, use __clear_cache instead -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Other | Architecture: Unknown/Multiple Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by lukexi): OK, thanks for that! I'm running a build now with {{{ #if defined(ios_HOST_OS) || defined (darwin_HOST_OS) void sys_icache_invalidate(void *start, size_t len); #endif /* Synchronize data/instruction cache. */ void clearCache(void *start, void *end) { #if defined(ios_HOST_OS) || defined (darwin_HOST_OS) sys_icache_invalidate(start, (char *)end-(char *)start); #elif defined(__GNUC__) __builtin___clear_cache(start, end); #else #error "Missing builtin to flush instruction cache" #endif }}} adapted from that to test -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 24 09:20:30 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Nov 2013 09:20:30 -0000 Subject: [GHC] #8561: Clang/iOS: __builtin___clear_cache doesn't exist in clang, use __clear_cache instead In-Reply-To: <045.fb8c4675779e8bc63ac8ffba3bcfbb67@haskell.org> References: <045.fb8c4675779e8bc63ac8ffba3bcfbb67@haskell.org> Message-ID: <060.70aa7e7dced9d9c16042e485609f4e92@haskell.org> #8561: Clang/iOS: __builtin___clear_cache doesn't exist in clang, use __clear_cache instead -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Other | Architecture: Unknown/Multiple Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by carter): heatsink is likely to follow up on this, but GCC 4.2 lacks the builtin clear cache primitive, and thus any OS X system with XCode < 5 has a GCC old enough that builtin___clear_cache shoudn't be used. (at least if we want to support working at all on older OS X systems, which i think is worth doing) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 24 09:21:36 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Nov 2013 09:21:36 -0000 Subject: [GHC] #8561: Clang/iOS: __builtin___clear_cache doesn't exist in clang, use __clear_cache instead In-Reply-To: <045.fb8c4675779e8bc63ac8ffba3bcfbb67@haskell.org> References: <045.fb8c4675779e8bc63ac8ffba3bcfbb67@haskell.org> Message-ID: <060.5a4d947b4505b52b6097c170a4a3adcd@haskell.org> #8561: Clang/iOS: __builtin___clear_cache doesn't exist in clang, use __clear_cache instead -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Other | Architecture: Unknown/Multiple Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by carter): that is, on x86 architectures we perhaps shouldn't be calling clear cache at all. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 24 12:30:52 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Nov 2013 12:30:52 -0000 Subject: [GHC] #8509: Doc Formatting - Patch Included In-Reply-To: <047.0136021a5f52b8cacd4f472da4a4b00e@haskell.org> References: <047.0136021a5f52b8cacd4f472da4a4b00e@haskell.org> Message-ID: <062.cc2fc387ea0426f5b6f96273e3cb4931@haskell.org> #8509: Doc Formatting - Patch Included -------------------------------------+------------------------------------- Reporter: cschneid | Owner: Type: bug | Status: patch Priority: low | Milestone: Component: | Version: 7.6.3 libraries/directory | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: Documentation | hour) bug | Blocked By: Test Case: | Related Tickets: Blocking: | -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"b3abf7a00436ad7ab9e0b3a2f7c570e3e9874e8f/directory"]: {{{ #!CommitTicketReference repository="directory" revision="b3abf7a00436ad7ab9e0b3a2f7c570e3e9874e8f" Fix the formatting of error docs of removeDirectory (#8509) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 24 12:31:53 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Nov 2013 12:31:53 -0000 Subject: [GHC] #8509: Doc Formatting - Patch Included In-Reply-To: <047.0136021a5f52b8cacd4f472da4a4b00e@haskell.org> References: <047.0136021a5f52b8cacd4f472da4a4b00e@haskell.org> Message-ID: <062.ae089a9cf67801be9376bbe21432a39c@haskell.org> #8509: Doc Formatting - Patch Included -------------------------------------+------------------------------------- Reporter: cschneid | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: | Version: 7.6.3 libraries/directory | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: Documentation | hour) bug | Blocked By: Test Case: | Related Tickets: Blocking: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: patch => closed * resolution: => fixed Comment: Applied, thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 24 18:22:10 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Nov 2013 18:22:10 -0000 Subject: [GHC] #8540: Template Haskell handling bug in ghc-7.7.20131115 ? In-Reply-To: <044.a2405e435a0516e234d799c5d8afd594@haskell.org> References: <044.a2405e435a0516e234d799c5d8afd594@haskell.org> Message-ID: <059.1b0907f2fed2c9f5e4246501f9152d7a@haskell.org> #8540: Template Haskell handling bug in ghc-7.7.20131115 ? -------------------------------------+------------------------------------ Reporter: awson | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: th/T8540 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Joachim Breitner ): In [changeset:"55eb21beab18a6e9a7c156d91e17119b2de9827c/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="55eb21beab18a6e9a7c156d91e17119b2de9827c" Mark break006 break003 print019 as broken by #8540 ...when debugging is on, to keep builds reports clean. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 24 18:33:29 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Nov 2013 18:33:29 -0000 Subject: [GHC] #8562: Builtin function __builtin___clear_cache is unavailable on GCC 4.2 Message-ID: <047.84726fd9ab3632509c55e16aa3ebee4d@haskell.org> #8562: Builtin function __builtin___clear_cache is unavailable on GCC 4.2 ------------------------------+-------------------------------------------- Reporter: heatsink | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.7 System | Operating System: MacOS X Keywords: | Type of failure: GHC doesn't work at all Architecture: x86_64 | Test Case: (amd64) | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: #8561 | ------------------------------+-------------------------------------------- A recent update to the RTS uses the GCC builtin function `__builtin___clear_cache`. This function was introduced in GCC 4.3. In older GCCs that don't have this builtin function, it's treated as an undefined function, leading to a link-time error. My system has GCC 4.2.1, bundled with XCode 3.2.6. The function is called from `rts/sm/Storage.c`. It seems that x86 architectures don't need a cache flush, so a possible fix is to do nothing on GCC < 4.3.6 on x86 architectures. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 24 18:35:12 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Nov 2013 18:35:12 -0000 Subject: [GHC] #8561: Clang/iOS: __builtin___clear_cache doesn't exist in clang, use __clear_cache instead In-Reply-To: <045.fb8c4675779e8bc63ac8ffba3bcfbb67@haskell.org> References: <045.fb8c4675779e8bc63ac8ffba3bcfbb67@haskell.org> Message-ID: <060.db8775d1631aea81859f14747e081ec6@haskell.org> #8561: Clang/iOS: __builtin___clear_cache doesn't exist in clang, use __clear_cache instead -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Other | Architecture: Unknown/Multiple Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: #8562 -------------------------------------+------------------------------------- Changes (by heatsink): * related: => #8562 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 25 08:50:44 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Nov 2013 08:50:44 -0000 Subject: [GHC] #8540: Template Haskell handling bug in ghc-7.7.20131115 ? In-Reply-To: <044.a2405e435a0516e234d799c5d8afd594@haskell.org> References: <044.a2405e435a0516e234d799c5d8afd594@haskell.org> Message-ID: <059.e6003bb0186bc7b4215938338ea357ea@haskell.org> #8540: Template Haskell handling bug in ghc-7.7.20131115 ? -------------------------------------+------------------------------------ Reporter: awson | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: th/T8540 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): I have `-DDEBUG` on too (certainly in `TcEnv`), and these tests work fine for me. I don't know how to account for this. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 25 09:15:44 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Nov 2013 09:15:44 -0000 Subject: [GHC] #8540: Template Haskell handling bug in ghc-7.7.20131115 ? In-Reply-To: <044.a2405e435a0516e234d799c5d8afd594@haskell.org> References: <044.a2405e435a0516e234d799c5d8afd594@haskell.org> Message-ID: <059.fb5ea3c8f7ee13cbceb6b435128f8681@haskell.org> #8540: Template Haskell handling bug in ghc-7.7.20131115 ? -------------------------------------+------------------------------------ Reporter: awson | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: th/T8540 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): I just reproduced it here again, starting from a clean tree, and the build host on travis has it. Have you tried running `make clean` first? And are you sure there is no `mk/are-validating.mk` overriding your settings? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 25 10:06:12 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Nov 2013 10:06:12 -0000 Subject: [GHC] #5075: CPR optimisation for sum types if only one constructor is used In-Reply-To: <053.3ffd551e0053819cbbe3bb221ae15b3f@haskell.org> References: <053.3ffd551e0053819cbbe3bb221ae15b3f@haskell.org> Message-ID: <068.ab340b964ed0db2e770c60d526bcd002@haskell.org> #5075: CPR optimisation for sum types if only one constructor is used -------------------------------------+------------------------------------ Reporter: batterseapower | Owner: simonpj Type: feature request | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by nomeata): * cc: mail@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 25 10:07:06 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Nov 2013 10:07:06 -0000 Subject: [GHC] #1885: Improve CPR analysis In-Reply-To: <046.6c11df8aecc98c3db1f131fb2c9dc642@haskell.org> References: <046.6c11df8aecc98c3db1f131fb2c9dc642@haskell.org> Message-ID: <061.b150d6497775a4cf098415bba5ddfe37@haskell.org> #1885: Improve CPR analysis -------------------------------------+------------------------------------ Reporter: simonpj | Owner: simonpj Type: feature request | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by nomeata): * cc: mail@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 25 17:14:04 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Nov 2013 17:14:04 -0000 Subject: [GHC] #8560: undeducable Typeable error with data kinds when deriving Data for GADT in GHC version 7.7.20131122 In-Reply-To: <045.08c7497f3d39ab287608a0acc7513dc1@haskell.org> References: <045.08c7497f3d39ab287608a0acc7513dc1@haskell.org> Message-ID: <060.4b783ca960441ebf5138a06902f10d54@haskell.org> #8560: undeducable Typeable error with data kinds when deriving Data for GADT in GHC version 7.7.20131122 -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): I have not even begun to think what `deriving( Data )` might do for GADTs. At Lennart's request, we did make "standalone deriving" simply generate code, and if it doesn't typecheck it's your problem. See [http://www.haskell.org/ghc/docs/latest/html/users_guide/deriving.html #stand-alone-deriving the manual] (fourth bullet). See #3102, and #3702 for someone who liked it. I'm not sure that was a good decision, especially for jolly complicated classes like `Data`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 25 17:27:53 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Nov 2013 17:27:53 -0000 Subject: [GHC] #1600: Optimisation: CPR the results of IO In-Reply-To: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> References: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> Message-ID: <062.d746bf89645c7e54e69ef8b7dfc6c910@haskell.org> #1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Moderate (less performance bug | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by nomeata): I?m working on nested cpr now. There a few related tickets (#1885 and #2289), but I?ll report my progress here, mostly because this has the lowest number and the fine `factIO` example. Building on a patch from SPJ I now have a branch that works in simple cases. I have some doubts about correctness (i.e. `bothDmdType` is used both for type applications and cases, but I believe these need to treat the question of convergence differently). Also, it does ''not'' work for the `factIO` example yet, probably because there is an unboxed tuple to begin with. Need to investigate. The testsuite goes through (reporting, as it seems, only differences in, well, demand signatures), but nofib?s `typecheck` fills the memory quickly, so the analysis clearly is not conservative yet.. Need to investigate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 25 17:46:19 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Nov 2013 17:46:19 -0000 Subject: [GHC] #8563: Deriving with PolyKinds broken Message-ID: <044.47e748e68347bc8a5fc9914b91da60b6@haskell.org> #8563: Deriving with PolyKinds broken ------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Compiling {{{ {-# LANGUAGE DeriveDataTypeable, PolyKinds #-} module Tagged where import Data.Typeable import Data.Ix newtype Tagged s b = Tagged { unTagged :: b } deriving ( Eq, Ord, Ix, Bounded, Typeable ) }}} gives {{{ Tagged.hs:8:5: ?Tagged? is applied to too many type arguments In an expression type signature: Tagged k s b -> Tagged k s b -> Bool In the expression: GHC.Prim.coerce ((==) :: b -> b -> Bool) :: Tagged k s b -> Tagged k s b -> Bool In an equation for ?==?: (==) = GHC.Prim.coerce ((==) :: b -> b -> Bool) :: Tagged k s b -> Tagged k s b -> Bool Tagged.hs:8:9: ?Tagged? is applied to too many type arguments In an expression type signature: Tagged k s b -> Tagged k s b -> Ordering In the expression: GHC.Prim.coerce (compare :: b -> b -> Ordering) :: Tagged k s b -> Tagged k s b -> Ordering In an equation for ?compare?: compare = GHC.Prim.coerce (compare :: b -> b -> Ordering) :: Tagged k s b -> Tagged k s b -> Ordering Tagged.hs:8:14: ?Tagged? is applied to too many type arguments In an expression type signature: (,) (Tagged k s b) (Tagged k s b) -> [] (Tagged k s b) In the expression: GHC.Prim.coerce (range :: (,) b b -> [] b) :: (,) (Tagged k s b) (Tagged k s b) -> [] (Tagged k s b) In an equation for ?range?: range = GHC.Prim.coerce (range :: (,) b b -> [] b) :: (,) (Tagged k s b) (Tagged k s b) -> [] (Tagged k s b) Tagged.hs:8:18: ?Tagged? is applied to too many type arguments In an expression type signature: Tagged k s b In the expression: GHC.Prim.coerce (minBound :: b) :: Tagged k s b In an equation for ?minBound?: minBound = GHC.Prim.coerce (minBound :: b) :: Tagged k s b }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 25 17:54:50 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Nov 2013 17:54:50 -0000 Subject: [GHC] #8563: Deriving with PolyKinds broken In-Reply-To: <044.47e748e68347bc8a5fc9914b91da60b6@haskell.org> References: <044.47e748e68347bc8a5fc9914b91da60b6@haskell.org> Message-ID: <059.4588a1bf549222896987e8c786fa4d43@haskell.org> #8563: Deriving with PolyKinds broken -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Thanks for the report, added as T8563 in a even simpler form: {{{ {-# LANGUAGE PolyKinds #-} module Tagged where newtype Tagged s b = Tagged b deriving Eq }}} The problems goes away without `PolyKinds` so it is related to that. Probably the `k` option to `Tagged` should not be explicitly given here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 25 17:54:53 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Nov 2013 17:54:53 -0000 Subject: [GHC] #8563: Deriving with PolyKinds broken In-Reply-To: <044.47e748e68347bc8a5fc9914b91da60b6@haskell.org> References: <044.47e748e68347bc8a5fc9914b91da60b6@haskell.org> Message-ID: <059.d001306682b77849156e43c2f9845b35@haskell.org> #8563: Deriving with PolyKinds broken -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Joachim Breitner ): In [changeset:"d7702a16c4a1d62a184c13cb9097747dfa559335/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="d7702a16c4a1d62a184c13cb9097747dfa559335" Add testcase for #8563 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 25 18:00:35 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Nov 2013 18:00:35 -0000 Subject: [GHC] #8563: Deriving with PolyKinds broken In-Reply-To: <044.47e748e68347bc8a5fc9914b91da60b6@haskell.org> References: <044.47e748e68347bc8a5fc9914b91da60b6@haskell.org> Message-ID: <059.b54c1ca8d35f184d4ca7d5c299df6f20@haskell.org> #8563: Deriving with PolyKinds broken -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): Filter out the kind vars in `cls_tys` and `cls_tvs` in `gen_Newtype_binds` in !TcGenDeriv -- I think that should fix it. Let me know if you want me to take a closer look, but it seems like you're on it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 25 18:01:44 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Nov 2013 18:01:44 -0000 Subject: [GHC] #8563: Deriving with PolyKinds broken In-Reply-To: <044.47e748e68347bc8a5fc9914b91da60b6@haskell.org> References: <044.47e748e68347bc8a5fc9914b91da60b6@haskell.org> Message-ID: <059.f8cf136e04388659e1657a3dad4af8f9@haskell.org> #8563: Deriving with PolyKinds broken -------------------------------------+------------------------------------ Reporter: edsko | Owner: nomeata Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by nomeata): * owner: => nomeata Comment: I?m on it, just put a trace on `cls_tys`. I?ll let you know if I have problems ? thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 25 18:19:28 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Nov 2013 18:19:28 -0000 Subject: [GHC] #8563: Deriving with PolyKinds broken In-Reply-To: <044.47e748e68347bc8a5fc9914b91da60b6@haskell.org> References: <044.47e748e68347bc8a5fc9914b91da60b6@haskell.org> Message-ID: <059.ddc5c87efd921919c1d42054dacb1149@haskell.org> #8563: Deriving with PolyKinds broken -------------------------------------+------------------------------------ Reporter: edsko | Owner: nomeata Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): The problem seems to be in `toHsType` in `HsUtils`; if I do {{{ to_hs_type (TyConApp tc args) = nlHsTyConApp (getRdrName tc) (map toHsType args') where args' = filter (not . isKind) args }}} it works. (Which make sense: In Core types, we want kinds; in the user- visible type that `toHsType` provides us, we don?t want them). Do you agree? Running validate right now... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 25 18:43:36 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Nov 2013 18:43:36 -0000 Subject: [GHC] #8563: Deriving with PolyKinds broken In-Reply-To: <044.47e748e68347bc8a5fc9914b91da60b6@haskell.org> References: <044.47e748e68347bc8a5fc9914b91da60b6@haskell.org> Message-ID: <059.05b709629832973847eba927961aec08@haskell.org> #8563: Deriving with PolyKinds broken -------------------------------------+------------------------------------ Reporter: edsko | Owner: nomeata Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Joachim Breitner ): In [changeset:"803afa31c5884dbd5f3cffc05f0bda9106352714/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="803afa31c5884dbd5f3cffc05f0bda9106352714" In toHsType, filter out kind variables (This fixes #8563) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 25 18:44:04 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Nov 2013 18:44:04 -0000 Subject: [GHC] #8562: Builtin function __builtin___clear_cache is unavailable on GCC 4.2 In-Reply-To: <047.84726fd9ab3632509c55e16aa3ebee4d@haskell.org> References: <047.84726fd9ab3632509c55e16aa3ebee4d@haskell.org> Message-ID: <062.f23dd182e11b3078ee51205d25fcc66e@haskell.org> #8562: Builtin function __builtin___clear_cache is unavailable on GCC 4.2 --------------------------------------------+------------------------------ Reporter: heatsink | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: GHC doesn't work at all | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8561 --------------------------------------------+------------------------------ Comment (by Joachim Breitner ): In [changeset:"66de8c1e8f1a101bbfe551c46edca49473f6acd0/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="66de8c1e8f1a101bbfe551c46edca49473f6acd0" Mark #8562 as fixed }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 25 18:44:57 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Nov 2013 18:44:57 -0000 Subject: [GHC] #8563: Deriving with PolyKinds broken In-Reply-To: <044.47e748e68347bc8a5fc9914b91da60b6@haskell.org> References: <044.47e748e68347bc8a5fc9914b91da60b6@haskell.org> Message-ID: <059.4bd46f7142944941a6e62b578f4dc1a9@haskell.org> #8563: Deriving with PolyKinds broken -------------------------------------+------------------------------------ Reporter: edsko | Owner: nomeata Type: bug | Status: closed Priority: high | Milestone: Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by nomeata): * status: new => closed * resolution: => fixed Comment: Yes, validate went through (and I need a faster machine so that I can go home earlier ;-)). If you disagree with the fix, let me know. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 25 18:45:44 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Nov 2013 18:45:44 -0000 Subject: [GHC] #8562: Builtin function __builtin___clear_cache is unavailable on GCC 4.2 In-Reply-To: <047.84726fd9ab3632509c55e16aa3ebee4d@haskell.org> References: <047.84726fd9ab3632509c55e16aa3ebee4d@haskell.org> Message-ID: <062.e19e93b9e263ef2ab30bdc4e1b26d9a8@haskell.org> #8562: Builtin function __builtin___clear_cache is unavailable on GCC 4.2 --------------------------------------------+------------------------------ Reporter: heatsink | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: GHC doesn't work at all | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8561 --------------------------------------------+------------------------------ Comment (by nomeata): Replying to [comment:1 Joachim Breitner ]: > In [changeset:"66de8c1e8f1a101bbfe551c46edca49473f6acd0/testsuite"]: > {{{ > #!CommitTicketReference repository="testsuite" revision="66de8c1e8f1a101bbfe551c46edca49473f6acd0" > Mark #8562 as fixed > }}} Sorry, that?s a typo. I did not do anything about #8562. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 25 19:58:14 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Nov 2013 19:58:14 -0000 Subject: [GHC] #8451: Link problem on FreeBSD In-Reply-To: <052.b8772d44ba9b4118081982759aed2ca1@haskell.org> References: <052.b8772d44ba9b4118081982759aed2ca1@haskell.org> Message-ID: <067.a68604178d037e84a5ff5eb1eb820283@haskell.org> #8451: Link problem on FreeBSD --------------------------------------------+------------------------------ Reporter: kazu-yamamoto | Owner: pgj Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: FreeBSD | Architecture: Type of failure: GHC doesn't work at all | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by pgj): * owner: => pgj Comment: I can take a look at this issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 25 20:00:40 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Nov 2013 20:00:40 -0000 Subject: [GHC] #8013: Strange closure type error building hs-kqueue on FreeBSD In-Reply-To: <049.81816b82b3a17d10624a4b508e0be873@haskell.org> References: <049.81816b82b3a17d10624a4b508e0be873@haskell.org> Message-ID: <064.bfd1f5d3fd6bd2deec4ed454e03703e4@haskell.org> #8013: Strange closure type error building hs-kqueue on FreeBSD ---------------------------------------+---------------------------------- Reporter: ahktenzero | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.6.3 Resolution: | Keywords: Operating System: FreeBSD | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Changes (by pgj): * cc: pgj@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 25 20:02:15 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Nov 2013 20:02:15 -0000 Subject: [GHC] #8442: Cabal-install internal error with any use In-Reply-To: <043.647995df1e92d2ba03fcc0642ce966a9@haskell.org> References: <043.647995df1e92d2ba03fcc0642ce966a9@haskell.org> Message-ID: <058.7aabbba1e4a9c5229d979a32dddbb750@haskell.org> #8442: Cabal-install internal error with any use -----------------------------------+---------------------------------- Reporter: senk | Owner: pgj Type: bug | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.6.3 Resolution: | Keywords: Operating System: FreeBSD | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+---------------------------------- Changes (by pgj): * owner: => pgj Comment: I can take a look at this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 25 20:09:16 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Nov 2013 20:09:16 -0000 Subject: [GHC] #8564: Unhandled ELF relocation types on dynamically loading object files with GHCi Message-ID: <042.c71c0fc83010a14dadf11ed6c7cfbe83@haskell.org> #8564: Unhandled ELF relocation types on dynamically loading object files with GHCi ------------------------------------+------------------------------- Reporter: pgj | Owner: pgj Type: task | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Keywords: | Operating System: FreeBSD Architecture: Unknown/Multiple | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------- GHCi cannot handle ELF symbols with relocation types 15 (i386) and 22 (amd64) (such as {{{ThreadRuneLocale}}}, coming from libc on systems later than 9.0) when dynamically loading object files. This can be reproduced by the issuing the following commands: {{{ # pkg install hs-hs-bibutils .. $ ghci Prelude> :m Text.Bibutils Prelude> bibl_init Loading package syb-0.4.0 ... linking ... done. Loading package hs-bibutils-5.0 ... linking ... : /usr/local/lib/cabal/ghc-7.6.3/hs-bibutils-5.0/HShs-bibutils-5.0.o: unhandled ELF relocation(Rel) type 15 ghc: unable to load package `hs-bibutils-5.0' Prelude> }}} The source file {{{rts/Linker.c}}}, function {{{do_Elf_Rela_relocations()}}} is missing the case branches for types 15 ({{{R_386_TLS_IE}}}) and 22 ({{{R_X86_64_GOTTPOFF}}}). They shall be implemented for FreeBSD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 25 21:33:03 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Nov 2013 21:33:03 -0000 Subject: [GHC] #8564: Unhandled ELF relocation types on dynamically loading object files with GHCi In-Reply-To: <042.c71c0fc83010a14dadf11ed6c7cfbe83@haskell.org> References: <042.c71c0fc83010a14dadf11ed6c7cfbe83@haskell.org> Message-ID: <057.f8d69c39b51efd8f9dbe8d43af8af347@haskell.org> #8564: Unhandled ELF relocation types on dynamically loading object files with GHCi -------------------------------+------------------------------------ Reporter: pgj | Owner: pgj Type: task | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: FreeBSD | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+------------------------------------ Comment (by carter): does the same problem happen in ghci in head? 'cause i think ghci 7.7 / HEAD on those platforms should be using the system dy linker. That said, definitely should be fixed! :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 25 21:33:26 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Nov 2013 21:33:26 -0000 Subject: [GHC] #8560: undeducable Typeable error with data kinds when deriving Data for GADT in GHC version 7.7.20131122 In-Reply-To: <045.08c7497f3d39ab287608a0acc7513dc1@haskell.org> References: <045.08c7497f3d39ab287608a0acc7513dc1@haskell.org> Message-ID: <060.7e9c85465373f45593ce8c72466adad6@haskell.org> #8560: undeducable Typeable error with data kinds when deriving Data for GADT in GHC version 7.7.20131122 -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by carter): totally reasonable, and honestly I don't need a Data instance for my use case (and i'm not sure what i'd use it for!), I just found this to be quite odd and hence worth reporting, because weird corner cases are worth knowing/documenting. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 25 22:08:31 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Nov 2013 22:08:31 -0000 Subject: [GHC] #8564: Unhandled ELF relocation types on dynamically loading object files with GHCi In-Reply-To: <042.c71c0fc83010a14dadf11ed6c7cfbe83@haskell.org> References: <042.c71c0fc83010a14dadf11ed6c7cfbe83@haskell.org> Message-ID: <057.38043e946a9c0e5764a13564b9d0042f@haskell.org> #8564: Unhandled ELF relocation types on dynamically loading object files with GHCi -------------------------------+------------------------------------ Reporter: pgj | Owner: pgj Type: task | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: FreeBSD | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+------------------------------------ Comment (by pgj): Replying to [comment:1 carter]: > does the same problem happen in ghci in head? Yes, I have just tested with the snapshot of today on i386. {{{R_X86_64_GOTTPOFF}}} is implemented for !DragonFly BSD only, while {{{R_386_TLS_IE}}} does not seem to be handled everywhere at all. > 'cause i think ghci 7.7 / HEAD on those platforms should be using the system dy linker. I am not entirely familiar with the internals of the GHCi linker, but apparently it directly loads {{{.o}}} files and that is where it relies on the routines of {{{rts/Linker.c}}}. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 25 22:14:21 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Nov 2013 22:14:21 -0000 Subject: [GHC] #8564: Unhandled ELF relocation types on dynamically loading object files with GHCi In-Reply-To: <042.c71c0fc83010a14dadf11ed6c7cfbe83@haskell.org> References: <042.c71c0fc83010a14dadf11ed6c7cfbe83@haskell.org> Message-ID: <057.d3ce0089dea3b984155c250338e6360c@haskell.org> #8564: Unhandled ELF relocation types on dynamically loading object files with GHCi -------------------------------+------------------------------------ Reporter: pgj | Owner: pgj Type: task | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: FreeBSD | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+------------------------------------ Comment (by carter): ok fair enough, I'm not super familiar with those pieces as yet myself, hence wondering outloud. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 26 00:19:10 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Nov 2013 00:19:10 -0000 Subject: [GHC] #2233: Overhaul System.Process In-Reply-To: <047.24a366415ff9b59c03e5bf49850898a6@haskell.org> References: <047.24a366415ff9b59c03e5bf49850898a6@haskell.org> Message-ID: <062.5de5f484e5018a33784c7bb61a695563@haskell.org> #2233: Overhaul System.Process --------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: task | Status: patch Priority: normal | Milestone: _|_ Component: libraries/process | Version: 6.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by duncan): A few follow-up patches. The last one needs rather careful review. It's all rather subtle. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 26 03:20:07 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Nov 2013 03:20:07 -0000 Subject: [GHC] #8451: Link problem on FreeBSD In-Reply-To: <052.b8772d44ba9b4118081982759aed2ca1@haskell.org> References: <052.b8772d44ba9b4118081982759aed2ca1@haskell.org> Message-ID: <067.3fe809faea646d57d2c65cc702693388@haskell.org> #8451: Link problem on FreeBSD --------------------------------------------+------------------------------ Reporter: kazu-yamamoto | Owner: pgj Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: FreeBSD | Architecture: Type of failure: GHC doesn't work at all | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by kazu-yamamoto): I can reproduce this today. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 26 05:07:44 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Nov 2013 05:07:44 -0000 Subject: [GHC] #8561: Clang/iOS: __builtin___clear_cache doesn't exist in clang, use __clear_cache instead In-Reply-To: <045.fb8c4675779e8bc63ac8ffba3bcfbb67@haskell.org> References: <045.fb8c4675779e8bc63ac8ffba3bcfbb67@haskell.org> Message-ID: <060.fe26f0867c013699c56828def808012b@haskell.org> #8561: Clang/iOS: __builtin___clear_cache doesn't exist in clang, use __clear_cache instead -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Other | Architecture: Unknown/Multiple Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: #8562 -------------------------------------+------------------------------------- Changes (by nkpart): * cc: nkpart@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 26 05:08:17 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Nov 2013 05:08:17 -0000 Subject: [GHC] #8562: Builtin function __builtin___clear_cache is unavailable on GCC 4.2 In-Reply-To: <047.84726fd9ab3632509c55e16aa3ebee4d@haskell.org> References: <047.84726fd9ab3632509c55e16aa3ebee4d@haskell.org> Message-ID: <062.85b5385d87c0497a9fc153f2e38c60ea@haskell.org> #8562: Builtin function __builtin___clear_cache is unavailable on GCC 4.2 --------------------------------------------+------------------------------ Reporter: heatsink | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: GHC doesn't work at all | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8561 --------------------------------------------+------------------------------ Changes (by nkpart): * cc: nkpart@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 26 06:17:01 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Nov 2013 06:17:01 -0000 Subject: [GHC] #8561: Clang/iOS: __builtin___clear_cache doesn't exist in clang, use __clear_cache instead In-Reply-To: <045.fb8c4675779e8bc63ac8ffba3bcfbb67@haskell.org> References: <045.fb8c4675779e8bc63ac8ffba3bcfbb67@haskell.org> Message-ID: <060.fc289080150bb33972257a6bfa2c8354@haskell.org> #8561: Clang/iOS: __builtin___clear_cache doesn't exist in clang, use __clear_cache instead -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Other | Architecture: Unknown/Multiple Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: #8562 -------------------------------------+------------------------------------- Comment (by lukexi): (just the above in patch form, it's been working quite happily in intense use on iOS) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 26 06:21:45 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Nov 2013 06:21:45 -0000 Subject: [GHC] #8561: Clang/iOS: __builtin___clear_cache doesn't exist in clang, use __clear_cache instead In-Reply-To: <045.fb8c4675779e8bc63ac8ffba3bcfbb67@haskell.org> References: <045.fb8c4675779e8bc63ac8ffba3bcfbb67@haskell.org> Message-ID: <060.e3c319189a4cc812b4f2b4faf972022d@haskell.org> #8561: Clang/iOS: __builtin___clear_cache doesn't exist in clang, use __clear_cache instead -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Other | Architecture: Unknown/Multiple Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: #8562 -------------------------------------+------------------------------------- Comment (by amosrobinson): Thanks! I'm trying now on OSX10.8.5 & GCC 4.2.1. I got a warning (and error due to -Werror) that clearCache didn't have a prototype before it, so I made it static. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 26 06:24:44 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Nov 2013 06:24:44 -0000 Subject: [GHC] #8561: Clang/iOS: __builtin___clear_cache doesn't exist in clang, use __clear_cache instead In-Reply-To: <045.fb8c4675779e8bc63ac8ffba3bcfbb67@haskell.org> References: <045.fb8c4675779e8bc63ac8ffba3bcfbb67@haskell.org> Message-ID: <060.916ae03217273a760d1fcea15e5d51b9@haskell.org> #8561: Clang/iOS: __builtin___clear_cache doesn't exist in clang, use __clear_cache instead -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Other | Architecture: Unknown/Multiple Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: #8562 -------------------------------------+------------------------------------- Comment (by lukexi): Thanks! updated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 26 07:06:01 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Nov 2013 07:06:01 -0000 Subject: [GHC] #8561: Clang/iOS: __builtin___clear_cache doesn't exist in clang, use __clear_cache instead In-Reply-To: <045.fb8c4675779e8bc63ac8ffba3bcfbb67@haskell.org> References: <045.fb8c4675779e8bc63ac8ffba3bcfbb67@haskell.org> Message-ID: <060.604d14f6b6ccecc7972c785f85e6b72c@haskell.org> #8561: Clang/iOS: __builtin___clear_cache doesn't exist in clang, use __clear_cache instead -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Other | Architecture: Unknown/Multiple Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: #8562 -------------------------------------+------------------------------------- Comment (by carter): i'm meh about that fixup patch, the real issue is we don't need to call any cache synchronization on x86/ x86_64 architectures. I'll integrate the above patch into my fixup. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 26 09:11:51 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Nov 2013 09:11:51 -0000 Subject: [GHC] #2233: Overhaul System.Process In-Reply-To: <047.24a366415ff9b59c03e5bf49850898a6@haskell.org> References: <047.24a366415ff9b59c03e5bf49850898a6@haskell.org> Message-ID: <062.a7ada717675d3adec2cd3b6e3755bfba@haskell.org> #2233: Overhaul System.Process --------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: task | Status: patch Priority: normal | Milestone: _|_ Component: libraries/process | Version: 6.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by simonmar): Heh, clearly we need to pull the `async` package into the core libraries. But the patches look ok to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 26 09:58:51 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Nov 2013 09:58:51 -0000 Subject: [GHC] #1600: Optimisation: CPR the results of IO In-Reply-To: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> References: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> Message-ID: <062.642c6b4f898a39220bf74df09c7e09a5@haskell.org> #1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Moderate (less performance bug | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by nomeata): Analysing the `typecheck` divergence yields a very interesting example of how nested CPR can go wrong, which I?d like to document here. It completely wreak havoc with this innocent function: {{{ repeat :: x -> [x] repeat x = x : repeat x }}} (This requires nesting of sum types, but just imagine for this example that `[]` was a stream data type with only one constructor, if you want). The analyizer figurs out that its demand signature is `DmdType tm2(d,tm2(d,tm2(d,d)))`, i.e. it lazily uses its argument and will, with guaranteed convergence, produce a `:` constructor, and evaluating the second parameter thereof will also converge to a `:`, and so on. The signature could actually be infinite; my code cuts them off a a certain depth. This signature is certainly correct. So it seems this is eligible to a worker-wrapper-transformation. But when we do it we end up with (using non-core patterns for clarity): {{{ $wrepeat :: x -> (# a, a, a, [a] #) $wrepeat x = case x : repeat x of (x1:x2:x3:r) -> (# x1, x2, x3, r#) repeat x :: -> [x] repeat x = case $wrepeat x of (# x1, x2, x3, r#) -> (x1:x2:x3:r) }}} and now this diverges. I?m not entirely sure who is at fault here. Since the analysis yields a correct result, most likely the w/w transformation. But that does not seem to have enough information to prevent this. Needs more thinking. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 26 10:22:07 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Nov 2013 10:22:07 -0000 Subject: [GHC] #1600: Optimisation: CPR the results of IO In-Reply-To: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> References: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> Message-ID: <062.8efc508e1e997925b64c1fa66ee9bec7@haskell.org> #1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Moderate (less performance bug | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by nomeata): One solution, which seems to make sense, is to make the analysis a little bit less precise and more careful with recursive definition. If I make sure that an `Id` that is a LoopBreaker never has a `DmdResult` that `Converges` (by lub?ing it with `Diverges`), both the example above and the typecheck program of nofib compiles. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 26 10:45:34 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Nov 2013 10:45:34 -0000 Subject: [GHC] #2233: Overhaul System.Process In-Reply-To: <047.24a366415ff9b59c03e5bf49850898a6@haskell.org> References: <047.24a366415ff9b59c03e5bf49850898a6@haskell.org> Message-ID: <062.cf9337fbcc622bbc92a1cbfb253f635a@haskell.org> #2233: Overhaul System.Process --------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: task | Status: patch Priority: normal | Milestone: _|_ Component: libraries/process | Version: 6.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by hvr): Replying to [comment:21 simonmar]: > Heh, clearly we need to pull the `async` package into the core libraries. But the patches look ok to me. ...that would pull in `stm` as well, wouldn't it? :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 26 11:01:39 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Nov 2013 11:01:39 -0000 Subject: [GHC] #8565: New GeneralisedNewtypeDeriving needs help with higher rank types Message-ID: <046.65b1982efc44c02d3b266905ffc6cec0@haskell.org> #8565: New GeneralisedNewtypeDeriving needs help with higher rank types ------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Consider {{{ {-# LANGUAGE RankNTypes, GeneralizedNewtypeDeriving #-} module Foo where class C a where op :: (forall b. b -> a) -> a newtype T x = MkT x deriving( C ) }}} With the new "coerce" implementation of GND, this fails: {{{ Foo.hs:7:31: Cannot instantiate unification variable ?b0? with a type involving foralls: (forall b. b -> T x) -> T x Perhaps you want ImpredicativeTypes In the expression: GHC.Prim.coerce (op :: (forall (b :: *). b -> x) -> x) :: (forall (b :: *). b -> T x) -> T x In an equation for ?op?: op = GHC.Prim.coerce (op :: (forall (b :: *). b -> x) -> x) :: (forall (b :: *). b -> T x) -> T x }}} We want to coerce betweeen {{{ (forall b. b -> x) -> x ~R (forall b. b -> T x) -> T x }}} There are two difficulties with the new `coerce` approach: * Regarded as source code, instance declaration {{{ instance C x => C (T x) where op = coerce (op :: (forall b. b -> x) -> x) }}} requires impredicative instantiation. * We probably don't have a decomposition rule for `Coercible (forall a. t1) (forall a. t2)` There is no difficulty in principle here, but it's not quite obvious what the best approach to a fix is. But it would be good to fix before release; we don't want to break `conduit` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 26 11:21:11 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Nov 2013 11:21:11 -0000 Subject: [GHC] #2408: threadWaitRead on mingw32 threaded causes internal error In-Reply-To: <044.646a5d9cf31ef2594dbfe492fec77132@haskell.org> References: <044.646a5d9cf31ef2594dbfe492fec77132@haskell.org> Message-ID: <059.c719d697dea38270a9f5aab3d3177bc4@haskell.org> #2408: threadWaitRead on mingw32 threaded causes internal error -----------------------------------+--------------------------- Reporter: kirby | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: libraries/base | Version: 7.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+--------------------------- Changes (by blackbox.dev): * status: closed => new * cc: blackbox.dev.ml@? (added) * failure: => Runtime crash * version: 6.8.3 => 7.6.1 * owner: simonmar => * resolution: fixed => Comment: This bug still occurs, see last comment on https://github.com/twittner /zeromq-haskell/issues/8 {{{ display.exe: internal error: waitRead# on threaded RTS (GHC version 7.6.3 for i386_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. }}} Replying to [ticket:2408 kirby]: > threadWaitRead (used in 6.8.x to avoid the non-interruptable getChar) causes internal error on GHC 6.8.2 and 6.8.3: > > {{{ > prompt: test: internal error: waitRead# on threaded RTS > (GHC version 6.8.2 for i386_unknown_mingw32) > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > This application has requested the Runtime to terminate it in an unusual way. > Please contact the application's support team for more information. > }}} > > This is because in GHC.Conc: > {{{ > threadWaitRead :: Fd -> IO () > threadWaitRead fd > #ifndef mingw32_HOST_OS > | threaded = waitForReadEvent fd > #endif > | otherwise = IO $ \s -> > case fromIntegral fd of { I# fd# -> > case waitRead# fd# s of { s -> (# s, () #) > }} > }}} > So the threaded case is ignored on mingw32, and waitRead# crashes on threaded RTS. > It should be at least written on the threadWaitRead documentation, and a workaround provided. > > I've attached a little program to show the issue (if compiled with -threaded on windows). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 26 11:25:43 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Nov 2013 11:25:43 -0000 Subject: [GHC] #8565: New GeneralisedNewtypeDeriving needs help with higher rank types In-Reply-To: <046.65b1982efc44c02d3b266905ffc6cec0@haskell.org> References: <046.65b1982efc44c02d3b266905ffc6cec0@haskell.org> Message-ID: <061.3a85768141e716031f59e236a4a54783@haskell.org> #8565: New GeneralisedNewtypeDeriving needs help with higher rank types -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Joachim Breitner ): In [changeset:"2f78a4e2ad68b3dd0ca76405e650bc37fe99e00b/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="2f78a4e2ad68b3dd0ca76405e650bc37fe99e00b" Add testcase for #8565 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 26 11:26:00 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Nov 2013 11:26:00 -0000 Subject: [GHC] #8565: New GeneralisedNewtypeDeriving needs help with higher rank types In-Reply-To: <046.65b1982efc44c02d3b266905ffc6cec0@haskell.org> References: <046.65b1982efc44c02d3b266905ffc6cec0@haskell.org> Message-ID: <061.5217eb8a5ac3f8e767cc4540784445b4@haskell.org> #8565: New GeneralisedNewtypeDeriving needs help with higher rank types -------------------------------------------------+------------------------- Reporter: simonpj | Owner: 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 Test Case: | Difficulty: typecheck/should_compile/T8565 | Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by nomeata): * testcase: => typecheck/should_compile/T8565 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 26 11:26:41 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Nov 2013 11:26:41 -0000 Subject: [GHC] #8565: New GeneralisedNewtypeDeriving needs help with higher rank types In-Reply-To: <046.65b1982efc44c02d3b266905ffc6cec0@haskell.org> References: <046.65b1982efc44c02d3b266905ffc6cec0@haskell.org> Message-ID: <061.03d48c11c457c2c5a738a4cb8a0be33d@haskell.org> #8565: New GeneralisedNewtypeDeriving needs help with higher rank types -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by kazu-yamamoto): * cc: kazu@? (added) * testcase: typecheck/should_compile/T8565 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 26 11:30:34 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Nov 2013 11:30:34 -0000 Subject: [GHC] #8565: New GeneralisedNewtypeDeriving needs help with higher rank types In-Reply-To: <046.65b1982efc44c02d3b266905ffc6cec0@haskell.org> References: <046.65b1982efc44c02d3b266905ffc6cec0@haskell.org> Message-ID: <061.e9e5a4eb8f0f16fcadabddb6a43dd8c5@haskell.org> #8565: New GeneralisedNewtypeDeriving needs help with higher rank types -------------------------------------------------+------------------------- Reporter: simonpj | Owner: 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 Test Case: | Difficulty: typecheck/should_compile/T8565 | Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by nomeata): * testcase: => typecheck/should_compile/T8565 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 26 12:14:49 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Nov 2013 12:14:49 -0000 Subject: [GHC] #1600: Optimisation: CPR the results of IO In-Reply-To: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> References: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> Message-ID: <062.b487c6a2cfcbb444ef83299b6aa56e5e@haskell.org> #1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Moderate (less performance bug | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by simonpj): Great example! Graham Hutton would be interested, since he wrote a [http://www.cs.nott.ac.uk/~gmh/wrapper.pdf paper about worker/wrapper] (JFP 2009). A neat approach might be to say that, when doing the fixpoint on a recursive group, trim off any nested CPR info from the demand signatures we use when processing the RHSs. Simom -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 26 12:16:27 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Nov 2013 12:16:27 -0000 Subject: [GHC] #1600: Optimisation: CPR the results of IO In-Reply-To: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> References: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> Message-ID: <062.cef4c629c5566d15955255b3987bcb2d@haskell.org> #1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Moderate (less performance bug | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by nomeata): Replying to [comment:22 simonpj]: > A neat approach might be to say that, when doing the fixpoint on a recursive group, trim off any nested CPR info from the demand signatures we use when processing the RHSs. Woudn?t that be far too imprecise? That would completely prevent nested CPR in loops, like `factIO` above... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 26 13:01:48 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Nov 2013 13:01:48 -0000 Subject: [GHC] #8566: Panic with kindFunResult Message-ID: <046.8c016f9279bc4f1e089a2406e478ec67@haskell.org> #8566: Panic with kindFunResult ------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The following program: {{{ {-# LANGUAGE DataKinds #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE MultiParamTypeClasses #-} module Bug where data U (s :: *) = forall k. AA k [U s] data I (u :: U *) (r :: [*]) :: * where A :: I (AA t as) r -- fs unused, but needs to be present for the bug class C (u :: U *) (r :: [*]) (fs :: [*]) where c :: I u r -> I u r instance (C (AA (t (I a ps)) as) ps fs) => C (AA t (a ': as)) ps fs where c A = c undefined }}} crashes a fresh copy of GHC HEAD with the following: {{{ ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20131126 for i386-unknown-linux): kindFunResult k1{tv a24f} [ssk] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 26 14:19:14 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Nov 2013 14:19:14 -0000 Subject: [GHC] #8565: New GeneralisedNewtypeDeriving needs help with higher rank types In-Reply-To: <046.65b1982efc44c02d3b266905ffc6cec0@haskell.org> References: <046.65b1982efc44c02d3b266905ffc6cec0@haskell.org> Message-ID: <061.57f052d52b9f9945845bfe83586467eb@haskell.org> #8565: New GeneralisedNewtypeDeriving needs help with higher rank types -------------------------------------------------+------------------------- Reporter: simonpj | Owner: 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 Test Case: | Difficulty: typecheck/should_compile/T8565 | Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by goldfire): I just tested this with `ImpredicativeTypes` on, and the error message was from the `Coercible` stuff. With another case in that code (and `ImpredicativeTypes`), I think this would work. The underlying roles machinery is certainly strong enough to handle this case. I'm OK if we require a user to specify `ImpredicativeTypes` for this to work -- it really is impredicative! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 26 14:20:12 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Nov 2013 14:20:12 -0000 Subject: [GHC] #8563: Deriving with PolyKinds broken In-Reply-To: <044.47e748e68347bc8a5fc9914b91da60b6@haskell.org> References: <044.47e748e68347bc8a5fc9914b91da60b6@haskell.org> Message-ID: <059.7545083e8da9d9464bb47bd215ee66ab@haskell.org> #8563: Deriving with PolyKinds broken -------------------------------------+------------------------------------ Reporter: edsko | Owner: nomeata Type: bug | Status: closed Priority: high | Milestone: Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): Looks great to me. I agree that `toHsType` is the right place for this, not in the deriving code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 26 14:54:47 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Nov 2013 14:54:47 -0000 Subject: [GHC] #8565: New GeneralisedNewtypeDeriving needs help with higher rank types In-Reply-To: <046.65b1982efc44c02d3b266905ffc6cec0@haskell.org> References: <046.65b1982efc44c02d3b266905ffc6cec0@haskell.org> Message-ID: <061.a93c8a36b661b701696182f9ce3c6cf2@haskell.org> #8565: New GeneralisedNewtypeDeriving needs help with higher rank types -------------------------------------------------+------------------------- Reporter: simonpj | Owner: 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 Test Case: | Difficulty: typecheck/should_compile/T8565 | Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by nomeata): I?m working on {{{ instance (forall a. (Coercible t1 t2)) => Coercible (forall a. t1) (forall a. t2) }}} and am almost done, just trying to get the desugarer cope with new type variables in derived constraints. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 26 15:11:57 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Nov 2013 15:11:57 -0000 Subject: [GHC] #8565: New GeneralisedNewtypeDeriving needs help with higher rank types In-Reply-To: <046.65b1982efc44c02d3b266905ffc6cec0@haskell.org> References: <046.65b1982efc44c02d3b266905ffc6cec0@haskell.org> Message-ID: <061.6b70f08c713d5bc4e09f72da50482d8f@haskell.org> #8565: New GeneralisedNewtypeDeriving needs help with higher rank types -------------------------------------------------+------------------------- Reporter: simonpj | Owner: 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 Test Case: | Difficulty: typecheck/should_compile/T8565 | Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by nomeata): Unfortunately, it seems that no such instances, with `forall` on the left, existed so far, so writing it by hand yields `Malformed instance head`. I tried to trick GHC to accept a forall on the left hand side of the instance heads (using `ConstraintTypes` and `KindSignatures`) {{{ class C a where op :: a type Foo (a:: * -> Constraint) = forall b. a b instance Foo C => C Int }}} but that only yielded {{{ Malformed predicate ?Foo C? In the context: (Foo C) While checking an instance declaration In the instance declaration for ?C Int? }}} Do we really want instances for `Coercible` where the instance head is not valid GHC code? (I don?t even dare to call it Haskell code ;-)) Or can the instance be somehow phrased differently? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 26 15:25:54 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Nov 2013 15:25:54 -0000 Subject: [GHC] #8567: Poor error message when GeneralizedNewtypeDeriving fails Message-ID: <047.019b4a48a0a3d68a214e0cd69bcf8b30@haskell.org> #8567: Poor error message when GeneralizedNewtypeDeriving fails ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Say I try to compile this silly module: {{{ {-# LANGUAGE GeneralizedNewtypeDeriving, TypeFamilies #-} module Bug where class C a where meth :: a -> F a type family F a type instance F Int = Bool type instance F Age = Char instance C Int where meth = (> 0) newtype Age = MkAge Int deriving C }}} Then, I get this output: {{{ Bug.hs:16:12: No instance for (GHC.Types.Coercible Bool Char) because ?Bool? and ?Char? are different types. arising from a use of ?GHC.Prim.coerce? In the expression: GHC.Prim.coerce (meth :: Int -> F Int) :: Age -> F Age In an equation for ?meth?: meth = GHC.Prim.coerce (meth :: Int -> F Int) :: Age -> F Age In the instance declaration for ?C Age? }}} What a confusing error message! Of the 9 lines of error, only 3 make sense: the line number (which is correct, at the line number of my `deriving` statement), saying that `Bool` and `Char` are different, and the conclusion that we're in an instance declaration. This might be better: {{{ Bug.hs:16:12: Cannot coerce from ?Bool? to ?Char? because ?Bool? and ?Char? are different types arising from the need to coerce ?Int -> F Int? to ?Age -> F Age? In the instance declaration for ?C Age? generated automatically through GeneralizedNewtypeDeriving To see the code I am typechecking, use -ddump-deriv }}} I actually went ahead and tried to fix this myself, but it's unclear to me what the best implementation plan for such an error message is. The code in !TcDeriv generates `HsSyn RdrName` and then renames it to `HsSyn Name`, but that code then gets sent through the normal type-checking pipeline. That pipeline builds up the error-reporting context without much heed to the fact that GHC itself generated the code. So, while I'm sure I could hack away long enough to get the error message to come out right, I'm equally sure that the resulting code would make people want to cry. Any advice? Or does someone with a better perspective want to take a stab? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 26 15:52:23 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Nov 2013 15:52:23 -0000 Subject: [GHC] #8565: New GeneralisedNewtypeDeriving needs help with higher rank types In-Reply-To: <046.65b1982efc44c02d3b266905ffc6cec0@haskell.org> References: <046.65b1982efc44c02d3b266905ffc6cec0@haskell.org> Message-ID: <061.8f59b6fb5b4689a20747aa54236682a8@haskell.org> #8565: New GeneralisedNewtypeDeriving needs help with higher rank types -------------------------------------------------+------------------------- Reporter: simonpj | Owner: 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 Test Case: | Difficulty: typecheck/should_compile/T8565 | Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by nomeata): Hmm, after more reading of the type class inference code I have doubts that this can be implemented without a larger refactoring of the the the typechecker and desugarer for instances. One of the reasons is that when `instance (forall a. (Coercible t1 t2)) => Coercible (forall a. t1) (forall a. t2)` were used when solving a constraint, the type variable will get turned into a parameter to the dictionary for the superclass, so is local to that. But if that constraint requires further instances, their dictionaries will require the same parameter, so this would require, in a way, a nested structure for the type class solver. The only work-around I can think of is asking the user to write the instance for `C` (or in the case of conduit, `MFunctor`) by hand. Which is unsatisfying. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 26 16:34:02 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Nov 2013 16:34:02 -0000 Subject: [GHC] #8568: internal error: allocation of ... bytes too large Message-ID: <047.44f15a8730cfbfb111ae73ca03abf808@haskell.org> #8568: internal error: allocation of ... bytes too large ------------------------------------+------------------------------------- Reporter: mojojojo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Running the following GHCi session: {{{ import GHC.DataSize import qualified Data.HashTable.IO as HT import Control.Monad t <- HT.new :: IO (HT.BasicHashTable Int Char) forM_ [0..100000] $ \i -> HT.insert t i 'a' recursiveSize t }}} results in the following error: {{{ : internal error: allocation of 1208480 bytes too large (GHC should have complained at compile-time) (GHC version 7.6.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 Tue Nov 26 19:26:56 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Nov 2013 19:26:56 -0000 Subject: [GHC] #6084: Add stg_ap_pnnv and related call patterns In-Reply-To: <049.725af368c945c55559bda8b9bf6a9e31@haskell.org> References: <049.725af368c945c55559bda8b9bf6a9e31@haskell.org> Message-ID: <064.b16cadf16f2828bc7a981420cc33298b@haskell.org> #6084: Add stg_ap_pnnv and related call patterns -------------------------------------+------------------------------------ Reporter: SimonMeier | Owner: simonmar Type: feature request | Status: new Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: 8313 | Related Tickets: -------------------------------------+------------------------------------ Comment (by parcs): Shouldn't the `funInfoArity` function be using `StgFunInfoExtraRev.arity`, not `StgFunInfoExtraFmd.arity`, when `tablesNextToCode` is true? {{{ #!haskell -- Takes the info pointer of a function, returns the function's arity funInfoArity :: DynFlags -> CmmExpr -> CmmExpr funInfoArity dflags iptr = cmmToWord dflags (cmmLoadIndex dflags rep fun_info offset) where fun_info = funInfoTable dflags iptr rep = cmmBits (widthFromBytes rep_bytes) (rep_bytes, offset) | tablesNextToCode dflags = ( pc_REP_StgFunInfoExtraFwd_arity pc , oFFSET_StgFunInfoExtraFwd_arity dflags ) | otherwise = ( pc_REP_StgFunInfoExtraRev_arity pc , oFFSET_StgFunInfoExtraRev_arity dflags ) pc = sPlatformConstants (settings dflags) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 26 20:35:15 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Nov 2013 20:35:15 -0000 Subject: [GHC] #8094: Intermittent segfault when using ghc-7.6.3 -e on OSX 10.6.8 In-Reply-To: <046.b62b3553268043815d7b86071673cb91@haskell.org> References: <046.b62b3553268043815d7b86071673cb91@haskell.org> Message-ID: <061.67034f842219b642a3e3f87b6117dc70@haskell.org> #8094: Intermittent segfault when using ghc-7.6.3 -e on OSX 10.6.8 ----------------------------------+---------------------------------- Reporter: rampion | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by blitzcode): As far as I can tell ever since HP 2012.2.0.0 / GHC 7.4.1 'ghc -e' has been broken on 10.6 / 64bit. 32bit continuous to work just fine, though. I just tried building 7.6.3 from source using the HP 2013.2.0.0 GHC 7.6.3 + XCode 4.1, and I still have no luck with 'ghc -e', same crash, it seems. So it's not just the >4.1 XCode build environment that causes an issue then? I would be great if the upcoming HP release would work on 10.6 64bit again. I'm no GHC hacker, but if there's anything I can try out / test that helps to resolve the issue, please let me know. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 26 22:42:44 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Nov 2013 22:42:44 -0000 Subject: [GHC] #8565: New GeneralisedNewtypeDeriving needs help with higher rank types In-Reply-To: <046.65b1982efc44c02d3b266905ffc6cec0@haskell.org> References: <046.65b1982efc44c02d3b266905ffc6cec0@haskell.org> Message-ID: <061.11b86a7a2cdb0b432e0cc15057b7c54c@haskell.org> #8565: New GeneralisedNewtypeDeriving needs help with higher rank types -------------------------------------------------+------------------------- Reporter: simonpj | Owner: 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 Test Case: | Difficulty: typecheck/should_compile/T8565 | Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by simonpj): It should be fine. Solving `Coercible s t` constraints is very very like solving `s ~ t` constraints. Just as we have a rule for `[s] ~ [t]` (by solving the constraint `s~t`), so we have a rule for `Coercible [s] [t]`. Now, we do have a rule for `(forall a. s) ~ (forall a. t)`, but it's a bit tricky because of the scoping of `a`. We have to solve the implication constraint `forall a. s~t`. To see how we do this for equality constraint, look on line 745 of `TcCanonical`, and the key support function `TcSMonad.deferTcSForAllEq`. The latter is the whole reason for `TcLetCo`, which was a significant innovation at the time. (Previously we could not decompose `forall/forall` equalities.) But now it's there, you should be able to use the exact same strategy for `Coercible`. (Provided you complete the `EvCoercible` refactoring you started.) Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 26 22:54:14 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Nov 2013 22:54:14 -0000 Subject: [GHC] #8565: New GeneralisedNewtypeDeriving needs help with higher rank types In-Reply-To: <046.65b1982efc44c02d3b266905ffc6cec0@haskell.org> References: <046.65b1982efc44c02d3b266905ffc6cec0@haskell.org> Message-ID: <061.e55dae13b20c3b1ed257a77762bc81b3@haskell.org> #8565: New GeneralisedNewtypeDeriving needs help with higher rank types -------------------------------------------------+------------------------- Reporter: simonpj | Owner: 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 Test Case: | Difficulty: typecheck/should_compile/T8565 | Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by nomeata): Thanks for pointing me to `deferTcSForAllEq`, I?ll look into it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 27 01:30:16 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Nov 2013 01:30:16 -0000 Subject: [GHC] #8561: Clang/iOS: __builtin___clear_cache doesn't exist in clang, use __clear_cache instead In-Reply-To: <045.fb8c4675779e8bc63ac8ffba3bcfbb67@haskell.org> References: <045.fb8c4675779e8bc63ac8ffba3bcfbb67@haskell.org> Message-ID: <060.545d48218706aec1117e39b99867e3b7@haskell.org> #8561: Clang/iOS: __builtin___clear_cache doesn't exist in clang, use __clear_cache instead -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Other | Architecture: Unknown/Multiple Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: #8562 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"9fbb8c788d4bdf091709778b42a1294bbdabef95/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="9fbb8c788d4bdf091709778b42a1294bbdabef95" Rejigger flushExec implementation (#8562, #8561) Instead, just don't do anything on x86/amd64, and on !x86, use either A) __clear_cache from libgcc, or B) sys_icache_invalidate for OS X (and iOS.) Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 27 01:30:17 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Nov 2013 01:30:17 -0000 Subject: [GHC] #8562: Builtin function __builtin___clear_cache is unavailable on GCC 4.2 In-Reply-To: <047.84726fd9ab3632509c55e16aa3ebee4d@haskell.org> References: <047.84726fd9ab3632509c55e16aa3ebee4d@haskell.org> Message-ID: <062.9da4d4089c17004a9d9652635bb01e43@haskell.org> #8562: Builtin function __builtin___clear_cache is unavailable on GCC 4.2 --------------------------------------------+------------------------------ Reporter: heatsink | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: GHC doesn't work at all | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8561 --------------------------------------------+------------------------------ Comment (by Austin Seipp ): In [changeset:"9fbb8c788d4bdf091709778b42a1294bbdabef95/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="9fbb8c788d4bdf091709778b42a1294bbdabef95" Rejigger flushExec implementation (#8562, #8561) Instead, just don't do anything on x86/amd64, and on !x86, use either A) __clear_cache from libgcc, or B) sys_icache_invalidate for OS X (and iOS.) Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 27 01:32:05 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Nov 2013 01:32:05 -0000 Subject: [GHC] #8561: Clang/iOS: __builtin___clear_cache doesn't exist in clang, use __clear_cache instead In-Reply-To: <045.fb8c4675779e8bc63ac8ffba3bcfbb67@haskell.org> References: <045.fb8c4675779e8bc63ac8ffba3bcfbb67@haskell.org> Message-ID: <060.648e68efda05fcfd95834f28797ed743@haskell.org> #8561: Clang/iOS: __builtin___clear_cache doesn't exist in clang, use __clear_cache instead -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Other | Architecture: Unknown/Multiple Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: #8562 -------------------------------------+------------------------------------- Comment (by thoughtpolice): This should now be fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 27 01:32:18 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Nov 2013 01:32:18 -0000 Subject: [GHC] #8561: Clang/iOS: __builtin___clear_cache doesn't exist in clang, use __clear_cache instead In-Reply-To: <045.fb8c4675779e8bc63ac8ffba3bcfbb67@haskell.org> References: <045.fb8c4675779e8bc63ac8ffba3bcfbb67@haskell.org> Message-ID: <060.54dc4ba6ff6c746617d2d2c8714bbe45@haskell.org> #8561: Clang/iOS: __builtin___clear_cache doesn't exist in clang, use __clear_cache instead -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Type: bug | Status: closed Priority: high | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Other | Architecture: Unknown/Multiple Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: #8562 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 27 01:32:28 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Nov 2013 01:32:28 -0000 Subject: [GHC] #8562: Builtin function __builtin___clear_cache is unavailable on GCC 4.2 In-Reply-To: <047.84726fd9ab3632509c55e16aa3ebee4d@haskell.org> References: <047.84726fd9ab3632509c55e16aa3ebee4d@haskell.org> Message-ID: <062.c38ef7a5f07df96cd216a9d15745d685@haskell.org> #8562: Builtin function __builtin___clear_cache is unavailable on GCC 4.2 --------------------------------------------+------------------------------ Reporter: heatsink | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 7.7 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: GHC doesn't work at all | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8561 --------------------------------------------+------------------------------ Changes (by thoughtpolice): * status: new => closed * resolution: => fixed Comment: This should now be fixed, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 27 03:59:10 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Nov 2013 03:59:10 -0000 Subject: [GHC] #6084: Add stg_ap_pnnv and related call patterns In-Reply-To: <049.725af368c945c55559bda8b9bf6a9e31@haskell.org> References: <049.725af368c945c55559bda8b9bf6a9e31@haskell.org> Message-ID: <064.76e53530b794c890abd5edcc96018ced@haskell.org> #6084: Add stg_ap_pnnv and related call patterns -------------------------------------+------------------------------------ Reporter: SimonMeier | Owner: simonmar Type: feature request | Status: new Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: 8313 | Related Tickets: -------------------------------------+------------------------------------ Comment (by parcs): Also I think that the call to `cmmLoadIndex` is wrong. It should be {{{(offset `div` rep_bytes)}}}, not just `offset`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 27 05:22:54 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Nov 2013 05:22:54 -0000 Subject: [GHC] #7962: "ghc -e " should return non-zero exit status In-Reply-To: <046.b219f88aa753aa2b186103bc8ef072c0@haskell.org> References: <046.b219f88aa753aa2b186103bc8ef072c0@haskell.org> Message-ID: <061.e877f1fdbf23c7cca33187adad235f40@haskell.org> #7962: "ghc -e " should return non-zero exit status ------------------------------------+------------------------------------ Reporter: timmaxw | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ------------------------------------+------------------------------------ Changes (by khyperia): * cc: hvr (added) Comment: Attempting to take this on as my first ticket, ran into a couple problems. Essentially, using -e eventually calls into code common between GHCi and -e. All the code for the following is in `ghc/InteractiveUI.hs` Relevant control enters in runGHCi, in the `case maybe_exprs` block. Both cases of the block (one with -e arguments, the other with normal interpreting) then call `runCommands`, which eventually filters down to `GhciMonad.runStmt`, which eventually handles the source errors. I am unsure of where to insert the logic to return a nonzero exit code, as putting it in `GhciMonad`/related would also affect normal GHCi. Any tips? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 27 14:39:22 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Nov 2013 14:39:22 -0000 Subject: [GHC] #6084: Add stg_ap_pnnv and related call patterns In-Reply-To: <049.725af368c945c55559bda8b9bf6a9e31@haskell.org> References: <049.725af368c945c55559bda8b9bf6a9e31@haskell.org> Message-ID: <064.e2cb2911e46561c214960528230c387e@haskell.org> #6084: Add stg_ap_pnnv and related call patterns -------------------------------------+------------------------------------ Reporter: SimonMeier | Owner: simonmar Type: feature request | Status: new Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: 8313 | Related Tickets: -------------------------------------+------------------------------------ Comment (by parcs): Here's a patch that fixes up Simon's original patch. It fixes three issues with the original patch: 1. The offset passed to `cmmLoadIndex` should be in units of the object's representation size, not necessarily bytes. So we divide `offset` by `rep_bytes`. 2. The `tablesNextToCode` logic was reversed. 3. We weren't untagging and dereferencing the function closure before passing it to `funInfoArity` and `entryCode`. With these three changes, the code in #8313 has a significant speed improvement. Before (that is, with vanilla GHC), the `auto` case would take 2.15s and the `manual` case 4.0s. Now, the `manual` case takes 0.75s. nofib doesn't seem to show a significant improvement in program runtime, but nofib compile times are down an average of 1.5% with a maximum improvement of 8%. I may be misinterpreting the results, however. int-e, how did you trigger the "PAP object entered!" error? I haven't come across it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 27 14:40:40 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Nov 2013 14:40:40 -0000 Subject: [GHC] #6084: Add stg_ap_pnnv and related call patterns In-Reply-To: <049.725af368c945c55559bda8b9bf6a9e31@haskell.org> References: <049.725af368c945c55559bda8b9bf6a9e31@haskell.org> Message-ID: <064.2ee35b51f569232505849f3c7e492da1@haskell.org> #6084: Add stg_ap_pnnv and related call patterns -------------------------------------+------------------------------------ Reporter: SimonMeier | Owner: simonmar Type: feature request | Status: patch Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: 8313 | Related Tickets: -------------------------------------+------------------------------------ Changes (by parcs): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 27 15:01:41 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Nov 2013 15:01:41 -0000 Subject: [GHC] #6084: Add stg_ap_pnnv and related call patterns In-Reply-To: <049.725af368c945c55559bda8b9bf6a9e31@haskell.org> References: <049.725af368c945c55559bda8b9bf6a9e31@haskell.org> Message-ID: <064.49c0d291128f3649fc6ccf5784a3a732@haskell.org> #6084: Add stg_ap_pnnv and related call patterns -------------------------------------+------------------------------------ Reporter: SimonMeier | Owner: simonmar Type: feature request | Status: patch Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: 8313 | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonmar): Thanks for revising the patch. I spotted one problem: you're referring to `fun` in two places, which might duplicate some code. The original patch put it in a temp variable for this reason. It's a good idea to peer at the Cmm code being generated to see whether it looks as you expect. We'll need a test for this in `testsuite/codeGen`. The nofib results are slightly suspicious: this patch should never increase allocation, but there's a 0.1% increase for `cacheprof`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 27 15:29:17 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Nov 2013 15:29:17 -0000 Subject: [GHC] #6084: Add stg_ap_pnnv and related call patterns In-Reply-To: <049.725af368c945c55559bda8b9bf6a9e31@haskell.org> References: <049.725af368c945c55559bda8b9bf6a9e31@haskell.org> Message-ID: <064.57ae5e8209374ef150b22cf4718ff324@haskell.org> #6084: Add stg_ap_pnnv and related call patterns -------------------------------------+------------------------------------ Reporter: SimonMeier | Owner: simonmar Type: feature request | Status: patch Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: 8313 | Related Tickets: -------------------------------------+------------------------------------ Comment (by parcs): Replying to [comment:30 simonmar]: > Thanks for revising the patch. > > I spotted one problem: you're referring to `fun` in two places, which might duplicate some code. The original patch put it in a temp variable for this reason. It's a good idea to peer at the Cmm code being generated to see whether it looks as you expect. Ah, okay. I will reinstate the temp variable for `fun` and then run nofib again, this time more carefully. > We'll need a test for this in `testsuite/codeGen`. Okay. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 27 17:31:27 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Nov 2013 17:31:27 -0000 Subject: [GHC] #8565: New GeneralisedNewtypeDeriving needs help with higher rank types In-Reply-To: <046.65b1982efc44c02d3b266905ffc6cec0@haskell.org> References: <046.65b1982efc44c02d3b266905ffc6cec0@haskell.org> Message-ID: <061.bc9f61eba7c1e612dc721afb6511b3b3@haskell.org> #8565: New GeneralisedNewtypeDeriving needs help with higher rank types -------------------------------------------------+------------------------- Reporter: simonpj | Owner: 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 Test Case: | Difficulty: typecheck/should_compile/T8565 | Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by Joachim Breitner ): In [changeset:"e19dc21f8a876a0b4849311d664472e61658d06d/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="e19dc21f8a876a0b4849311d664472e61658d06d" Testcase #8565 no longer broken at least with ImpredicativeTypes enabled in this module. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 27 17:31:32 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Nov 2013 17:31:32 -0000 Subject: [GHC] #8565: New GeneralisedNewtypeDeriving needs help with higher rank types In-Reply-To: <046.65b1982efc44c02d3b266905ffc6cec0@haskell.org> References: <046.65b1982efc44c02d3b266905ffc6cec0@haskell.org> Message-ID: <061.fa2d39e9b94c2081c0deef745791499e@haskell.org> #8565: New GeneralisedNewtypeDeriving needs help with higher rank types -------------------------------------------------+------------------------- Reporter: simonpj | Owner: Type: bug | Status: Priority: normal | closed Component: Compiler | Milestone: Resolution: fixed | Version: 7.6.3 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: | Unknown/Multiple typecheck/should_compile/T8565 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by nomeata): * status: new => closed * resolution: => fixed Comment: After a day of refactoring I got it to work. The code will still need `{-# LANGUAGES ImpredicativeTypes #-}, but otherwise things work as expected. Pushing as we speak... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 27 22:13:15 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Nov 2013 22:13:15 -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.9ed4f3c83b46a6fe475a476a2ded1e6f@haskell.org> #4426: Simplify the rules for implicit quantification -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: feature request | Status: patch Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 6.12.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #7880 -------------------------------------+------------------------------------ Comment (by monoidal): Patch updated for current HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 28 02:10:36 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Nov 2013 02:10:36 -0000 Subject: [GHC] #6084: Add stg_ap_pnnv and related call patterns In-Reply-To: <049.725af368c945c55559bda8b9bf6a9e31@haskell.org> References: <049.725af368c945c55559bda8b9bf6a9e31@haskell.org> Message-ID: <064.912bf098b2dac993897b27299b4139f7@haskell.org> #6084: Add stg_ap_pnnv and related call patterns -------------------------------------+------------------------------------ Reporter: SimonMeier | Owner: simonmar Type: feature request | Status: patch Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: 8313 | Related Tickets: -------------------------------------+------------------------------------ Comment (by parcs): I updated the patch to accommodate `fun` with a temporary variable. Let me know what you think. This optimization only triggers four times inside the nofib testsuite: twice in `lift:Print.lhs` and twice in `n-body:Main.hs`. According to subsequent nofib runs, the runtime of these two programs is not affected by the optimization. Compile time doesn't seem to have been affected either. But, as mentioned before, the runtime of the program in #8313 is significantly improved: 0.75s vs 3.9s. I also uploaded a test for the testsuite. The test is essentially a modified version of the program in #8313 which checks that the program returns the expected result. But I'm not confident that this is the best way to go about testing this optimization. Do you have a better idea? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 28 03:19:16 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Nov 2013 03:19:16 -0000 Subject: [GHC] #8266: Dynamic linking on Mac In-Reply-To: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> References: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> Message-ID: <067.78baa77511f66c72fab511242a4072f5@haskell.org> #8266: Dynamic linking on Mac --------------------------------------------+------------------------------ Reporter: kazu-yamamoto | Owner: Type: bug | thoughtpolice Priority: highest | Status: closed Component: Build System | Milestone: 7.8.1 Resolution: fixed | Version: 7.7 Operating System: MacOS X | Keywords: Type of failure: GHC doesn't work at all | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by amosrobinson): It looks like this is still an issue: {{{ % ghc Main.hs -dynamic % ./Main dyld: Library not loaded: @rpath/base-4.7.0.0/libHSbase-4.7.0.0-ghc7.7.20131125.dylib Referenced from: /Users/amos/ghc/ghc-head/libraries/dph/dph- examples/t/./Main Reason: image not found Trace/BPT trap: 5 }}} I don't have the libraries in `ghc-head/inplace/lib` or `ghc-head/lib` - only in `ghc-head/bindisttest/install\ \ \ dir/lib/`. This is the incantation I needed to get a dynamic to work: {{{ ghc Main.hs -dynamic -optl "-Wl,-rpath,/Users/amos/ghc/ghc- head/bindisttest/install dir/lib/ghc-7.7.20131125/" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 28 04:42:35 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Nov 2013 04:42:35 -0000 Subject: [GHC] #7962: "ghc -e " should return non-zero exit status In-Reply-To: <046.b219f88aa753aa2b186103bc8ef072c0@haskell.org> References: <046.b219f88aa753aa2b186103bc8ef072c0@haskell.org> Message-ID: <061.e8c148e7b67e4973a89a35e752de0e19@haskell.org> #7962: "ghc -e " should return non-zero exit status ------------------------------------+------------------------------------ Reporter: timmaxw | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ------------------------------------+------------------------------------ Comment (by khyperia): Patch created and attached. The test suite currently does not run on my Windows machine ("tee: standard output: Permission denied", followed by a hang), so I was unable to run the validation script. As this is my first patch, please tell me what I did wrong :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 28 07:48:29 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Nov 2013 07:48:29 -0000 Subject: [GHC] #8266: Dynamic linking on Mac In-Reply-To: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> References: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> Message-ID: <067.6205071c84aefef4a854a308a9c788f2@haskell.org> #8266: Dynamic linking on Mac --------------------------------------------+------------------------------ Reporter: kazu-yamamoto | Owner: Type: bug | thoughtpolice Priority: highest | Status: closed Component: Build System | Milestone: 7.8.1 Resolution: fixed | Version: 7.7 Operating System: MacOS X | Keywords: Type of failure: GHC doesn't work at all | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by amosrobinson): I don't know if this helps, but I managed to hack around this for now with something like {{{ cd inplace/lib for lib in ../../bindisttest/install\ \ \ dir/lib/ghc-*/* do if [ -d "$lib" ] then ln -s "$lib" . fi done }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 28 08:17:34 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Nov 2013 08:17:34 -0000 Subject: [GHC] #8266: Dynamic linking on Mac In-Reply-To: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> References: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> Message-ID: <067.cec3edd2fde4f7380b8b51ec16553ff9@haskell.org> #8266: Dynamic linking on Mac --------------------------------------------+------------------------------ Reporter: kazu-yamamoto | Owner: Type: bug | thoughtpolice Priority: highest | Status: closed Component: Build System | Milestone: 7.8.1 Resolution: fixed | Version: 7.7 Operating System: MacOS X | Keywords: Type of failure: GHC doesn't work at all | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by darchon): The current design indeed only works for one, let's call it the //default//, situation; which is: * When GHC is installed in a //normal// directory using e.g. `make install` All other situations, including using the GHC binary from the build-tree, are either not working, or are working by accident. amosrobinson: could you link or include as attachment the output of `otool -l Main`? Of course of the version that doesn't have the extra rpath. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 28 09:30:26 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Nov 2013 09:30:26 -0000 Subject: [GHC] #8266: Dynamic linking on Mac In-Reply-To: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> References: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> Message-ID: <067.b7c1bb3827e517867e752e64fd60f199@haskell.org> #8266: Dynamic linking on Mac --------------------------------------------+------------------------------ Reporter: kazu-yamamoto | Owner: Type: bug | thoughtpolice Priority: highest | Status: closed Component: Build System | Milestone: 7.8.1 Resolution: fixed | Version: 7.7 Operating System: MacOS X | Keywords: Type of failure: GHC doesn't work at all | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by amosrobinson): Ok, fair enough. It would be nice if we could get it working without having to `make install` - I don't know about other people, but this is my method of having multiple versions of ghc to test against. Here's the output of otool. Not sure if it's of much help: {{{ kallisti:t amos$ otool -L Main Main: @rpath/base-4.7.0.0/libHSbase-4.7.0.0-ghc7.7.20131125.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/integer-gmp-0.5.1.0/libHSinteger- gmp-0.5.1.0-ghc7.7.20131125.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/ghc-prim-0.3.1.0/libHSghc- prim-0.3.1.0-ghc7.7.20131125.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/rts-1.0/libHSrts-ghc7.7.20131125.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/rts-1.0/libffi.dylib (compatibility version 7.0.0, current version 7.0.0) /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0) /usr/local/lib/libgmp.10.dylib (compatibility version 12.0.0, current version 12.1.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0) }}} The other thing is, the only reason I started compiling with `-dynamic` was because I was getting errors about missing `.dyn_o`. Something about template haskell? I don't really understand. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 28 09:36:49 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Nov 2013 09:36:49 -0000 Subject: [GHC] #8266: Dynamic linking on Mac In-Reply-To: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> References: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> Message-ID: <067.cbed98ae06bd533c64a8dee1ba799398@haskell.org> #8266: Dynamic linking on Mac --------------------------------------------+------------------------------ Reporter: kazu-yamamoto | Owner: Type: bug | thoughtpolice Priority: highest | Status: closed Component: Build System | Milestone: 7.8.1 Resolution: fixed | Version: 7.7 Operating System: MacOS X | Keywords: Type of failure: GHC doesn't work at all | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by darchon): Actually, I wanted the output of `otool -l`, so lower-case 'l', more specifically I wanted to know the value(s) of `LC_RPATH`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 28 09:39:18 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Nov 2013 09:39:18 -0000 Subject: [GHC] #7962: "ghc -e " should return non-zero exit status In-Reply-To: <046.b219f88aa753aa2b186103bc8ef072c0@haskell.org> References: <046.b219f88aa753aa2b186103bc8ef072c0@haskell.org> Message-ID: <061.03586d79e139af86a718e031b6781ce6@haskell.org> #7962: "ghc -e " should return non-zero exit status ------------------------------------+------------------------------------ Reporter: timmaxw | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ------------------------------------+------------------------------------ Comment (by simonmar): The patch looks ok. I would refactor it a bit, like this: {{{ when (not success) $ maybe (return ()) lift sourceErrorHandler runCommands' eh sourceErrorHandler gCmd }}} Don't forget to add a test to testsuite/tests/ghci. If the testsuite isn't working right now, search for a ticket about that, and if there isn't one, make one :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 28 09:39:55 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Nov 2013 09:39:55 -0000 Subject: [GHC] #7962: "ghc -e " should return non-zero exit status In-Reply-To: <046.b219f88aa753aa2b186103bc8ef072c0@haskell.org> References: <046.b219f88aa753aa2b186103bc8ef072c0@haskell.org> Message-ID: <061.4f9595a7e5a290aec8b86c3e6cdd5c5a@haskell.org> #7962: "ghc -e " should return non-zero exit status ------------------------------------+------------------------------------ Reporter: timmaxw | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ------------------------------------+------------------------------------ Comment (by simonmar): Patch reviewed, so leaving in the 'new' state. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 28 09:41:29 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Nov 2013 09:41:29 -0000 Subject: [GHC] #8266: Dynamic linking on Mac In-Reply-To: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> References: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> Message-ID: <067.dee2d4d1de6ff71a68988ecb647a2dbb@haskell.org> #8266: Dynamic linking on Mac --------------------------------------------+------------------------------ Reporter: kazu-yamamoto | Owner: Type: bug | thoughtpolice Priority: highest | Status: closed Component: Build System | Milestone: 7.8.1 Resolution: fixed | Version: 7.7 Operating System: MacOS X | Keywords: Type of failure: GHC doesn't work at all | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by amosrobinson): Ah, I misread! I've attached it, and the value of `LC_RPATH` is `/Users/amos/ghc/ghc- head/inplace/lib`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 28 11:49:23 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Nov 2013 11:49:23 -0000 Subject: [GHC] #3103: Compiling base with cabal fails. In-Reply-To: <045.1ec9768c2c79e83b67fadc73a8306022@haskell.org> References: <045.1ec9768c2c79e83b67fadc73a8306022@haskell.org> Message-ID: <060.c5a3957f36f1e4bf09ca28dd19ed625a@haskell.org> #3103: Compiling base with cabal fails. -------------------------------------+------------------------------------ Reporter: Lemmih | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 6.10.1 Resolution: worksforme | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: T3103 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Joachim Breitner ): In [changeset:"2e161a4753c439d25b67a9a141180657642d7f91/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="2e161a4753c439d25b67a9a141180657642d7f91" #3103 no longer broken, it seems }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 28 12:11:44 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Nov 2013 12:11:44 -0000 Subject: [GHC] #8567: Poor error message when GeneralizedNewtypeDeriving fails In-Reply-To: <047.019b4a48a0a3d68a214e0cd69bcf8b30@haskell.org> References: <047.019b4a48a0a3d68a214e0cd69bcf8b30@haskell.org> Message-ID: <062.291fc9f05261fd0363f26360a034f61d@haskell.org> #8567: Poor error message when GeneralizedNewtypeDeriving fails -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): There are two parts to this: * It would be dead easy to generate a better error message for an unsolved constraint `Coerce Int Bool`. Rather than generating a generic type-class error message, it'd be easy to produce a message about the inability to coerce `Int` to `Bool`. Error messages are generated by `TcErrors`. We already generate special error messages for implicit parameters, which are already type-class constraints; `?x:Int` is short for `IP "x" Int`. * The "arising from a use of corece" part is also generated in `TcErrors`. Again, it'd be easy to change the form of the message for a call to `coerce`. * A bit harder to omit the `In the expression`, `In the definition of meth` parts. They might even be helpful, if we explain in the manual how `newtype deriving` actually works (via `corece`). I'd be happy to advise Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 28 12:35:33 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Nov 2013 12:35:33 -0000 Subject: [GHC] #8569: ASSERT in testcase type-rep, only in some ways: Message-ID: <046.d7161ae2625fe2a79685c11907883efc@haskell.org> #8569: ASSERT in testcase type-rep, only in some ways: ------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- On HEAD, I currently (d55cc30658ae7c5afc0d62f3bd118fb2a5fcee40) get {{{ =====> type-rep(normal) 2696 of 3834 [0, 0, 0] =====> type-rep(hpc) 2696 of 3834 [0, 0, 0] Compile failed (status 256) errors were: [1 of 1] Compiling Main ( type-rep.hs, type-rep.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20131124 for x86_64-unknown-linux): ASSERT failed! file compiler/basicTypes/Demand.lhs, line 439 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for type-rep(hpc) =====> type-rep(optasm) 2696 of 3834 [0, 1, 0] Compile failed (status 256) errors were: [1 of 1] Compiling Main ( type-rep.hs, type-rep.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20131124 for x86_64-unknown-linux): ASSERT failed! file compiler/basicTypes/Demand.lhs, line 439 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for type-rep(optasm) =====> type-rep(ghci) 2696 of 3834 [0, 2, 0] =====> type-rep(threaded1) 2696 of 3834 [0, 2, 0] =====> type-rep(threaded2) 2696 of 3834 [0, 2, 0] Compile failed (status 256) errors were: [1 of 1] Compiling Main ( type-rep.hs, type-rep.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20131124 for x86_64-unknown-linux): ASSERT failed! file compiler/basicTypes/Demand.lhs, line 439 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for type-rep(threaded2) =====> type-rep(dyn) 2696 of 3834 [0, 3, 0] Compile failed (status 256) errors were: [1 of 1] Compiling Main ( type-rep.hs, type-rep.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20131124 for x86_64-unknown-linux): ASSERT failed! file compiler/basicTypes/Demand.lhs, line 439 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for type-rep(dyn) =====> type-rep(optllvm) 2696 of 3834 [0, 4, 0] Compile failed (status 256) errors were: [1 of 1] Compiling Main ( type-rep.hs, type-rep.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20131124 for x86_64-unknown-linux): ASSERT failed! file compiler/basicTypes/Demand.lhs, line 439 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for type-rep(optllvm) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 28 12:37:13 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Nov 2013 12:37:13 -0000 Subject: [GHC] #8569: ASSERT in testcase type-rep, only in some ways: In-Reply-To: <046.d7161ae2625fe2a79685c11907883efc@haskell.org> References: <046.d7161ae2625fe2a79685c11907883efc@haskell.org> Message-ID: <061.5477f56b19e0a2c488d7f10efd3401a9@haskell.org> #8569: ASSERT in testcase type-rep, only in some ways: -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): That should be 1df2116c221941ef40a0f6f8fb7dcc42c56738e7 (changed due to pull rebase). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 28 12:52:29 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Nov 2013 12:52:29 -0000 Subject: [GHC] #6084: Add stg_ap_pnnv and related call patterns In-Reply-To: <049.725af368c945c55559bda8b9bf6a9e31@haskell.org> References: <049.725af368c945c55559bda8b9bf6a9e31@haskell.org> Message-ID: <064.728d16f8a5515e26fa1028b74e214d52@haskell.org> #6084: Add stg_ap_pnnv and related call patterns -------------------------------------+------------------------------------ Reporter: SimonMeier | Owner: simonmar Type: feature request | Status: patch Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: 8313 | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Marlow ): In [changeset:"4d1ea482885481073d2fee0ea0355848b9d853a1/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="4d1ea482885481073d2fee0ea0355848b9d853a1" Implement shortcuts for slow calls (#6084) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 28 12:57:29 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Nov 2013 12:57:29 -0000 Subject: [GHC] #6084: Add stg_ap_pnnv and related call patterns In-Reply-To: <049.725af368c945c55559bda8b9bf6a9e31@haskell.org> References: <049.725af368c945c55559bda8b9bf6a9e31@haskell.org> Message-ID: <064.c4f89249a365ae944a4381c6783068b7@haskell.org> #6084: Add stg_ap_pnnv and related call patterns -------------------------------------+------------------------------------ Reporter: SimonMeier | Owner: simonmar Type: feature request | Status: closed Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: 8313 | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonmar): * status: patch => closed * resolution: => fixed Comment: Thanks - I pushed this today, with some more comments after peering at the generated code a bit. I also made a test that explored the three different code paths. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 28 12:58:45 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Nov 2013 12:58:45 -0000 Subject: [GHC] #8313: Poor performance of higher-order functions with unboxing In-Reply-To: <044.b6968c03bf741916b66e492dab74ef19@haskell.org> References: <044.b6968c03bf741916b66e492dab74ef19@haskell.org> Message-ID: <059.95ded59356b052566d805def45622f00@haskell.org> #8313: Poor performance of higher-order functions with unboxing -------------------------------------+------------------------------------- Reporter: dolio | Owner: Type: task | Status: new Priority: low | Milestone: _|_ Component: Compiler | Version: 7.6.3 Resolution: | Keywords: slow unboxed Operating System: Unknown/Multiple | higher order Type of failure: Runtime | Architecture: Unknown/Multiple performance bug | Difficulty: Easy (less than 1 Test Case: | hour) Blocking: | Blocked By: 6084 | Related Tickets: -------------------------------------+------------------------------------- Comment (by simonmar): The optimisation from #6084 is now committed. Todo: turn this program into a ''performance'' test, so that we can tell if the optimisation stops firing for any reason. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 28 14:36:16 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Nov 2013 14:36:16 -0000 Subject: [GHC] #8570: In a pattern binding:ghc: panic! (the 'impossible' happened): Bogus selector Id Message-ID: <050.1bd463d4d609cd00d0e900b5cf4e1272@haskell.org> #8570: In a pattern binding:ghc: panic! (the 'impossible' happened): Bogus selector Id ----------------------------------+--------------------------------------- Reporter: rzetterberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Compile-time crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------------- Hello, This is my first bug report for GHC. I encountered a type error when compiling my program that said to report the error as a bug here. I tried searching for similar bugs, but could not find any bugs with the same problem. I'm sorry in advance if I have misunderstood anything or if there indeed are any duplicates of this problem! '''The error output''' {{{ src/app/Templates/Pages.hs:214:17: Constructor `Image' does not have field `filepath' In the pattern: Image {filepath = fp} In a pattern binding: Image {filepath = fp} = logo In an equation for `renderLogo': renderLogo (Design {mlogo = (Just logo)}) = H.a ! A.href "/" ! A.class_ "navbar-brand" $ H.img ! A.src (toValue fp) where Image {filepath = fp} = logo src/app/Templates/Pages.hs:214:34: Couldn't match expected type `Field' with actual type `Image' In the expression: logo In a pattern binding:ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-unknown-linux): Bogus selector Id Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} '''When/why does this happen?''' I encountered this problem when I accidentally imported a field in a data named "Image" from module A, and imported the constructor of a different data structure from a different module also named "Image". I guess the type error itself is valid since it doesn't make sense to do what I did, but the way GHC handles this corner case internally is the source of the panic. Here are my imports: {{{ import Data.Image (Image(filepath)) import Data.Form (Field(..), FieldResult(..)) }}} Data.Image contains the data structure Image, whereas Data.Form contains the data structure Field which has a constructor named Image. Here is the the data structure in Data.Image: {{{ data Image = Image { id :: Integer , categoryId :: Integer , name :: String , filepath :: String , createdAt :: LocalTimestamp } deriving (Show) }}} And here is the data structure in Data.Form: {{{ data Field = Password Name Label | Text Name Label Value | Email Name Label Value | InlineArea Name Label Html | Hidden Name Value | Image Name Label | Select Name Label [SelectItem] SelectedId | CheckBox Name Label Selected }}} And here is the line I use the filepath field in my template file: {{{ where Image{filepath = fp} = logo }}} '''Can this GHC panic be avoided?''' Yes, by specifically importing from the same module. Like so: {{{ import Data.Image (Image(Image, filepath) import Data.Form (Field(InlineArea), FieldResult(..)) }}} ---- If there is anything more I can do to help, just let me know! Thank you Richard Zetterberg -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 28 15:59:53 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Nov 2013 15:59:53 -0000 Subject: [GHC] #8557: Panic "tcTyVarDetails" when :forcing a kind-polymorphic data family instance In-Reply-To: <047.ee19f9cb863bee77e253732f4bf91ce3@haskell.org> References: <047.ee19f9cb863bee77e253732f4bf91ce3@haskell.org> Message-ID: <062.5fecace3bc58fd415a1e908f9a8ff7f1@haskell.org> #8557: Panic "tcTyVarDetails" when :forcing a kind-polymorphic data family instance -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"a8ac471d435214dbdc1fa70f938c63128993a1db/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a8ac471d435214dbdc1fa70f938c63128993a1db" Fix the deugger (fixing Trac #8557) The runtime debugger (which has not received any love from anyone for many years) looks wrong to me; it was failing to instantiate the outer foralls of a variable when called from :force, which calls cvObtainTermFromId, which calls cvObtainTerm I simplified the code too. But I'm flaky on how this debugger stuff is really supposed to work, so I'm partly guessing. Tests pass though. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 28 15:59:54 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Nov 2013 15:59:54 -0000 Subject: [GHC] #8540: Template Haskell handling bug in ghc-7.7.20131115 ? In-Reply-To: <044.a2405e435a0516e234d799c5d8afd594@haskell.org> References: <044.a2405e435a0516e234d799c5d8afd594@haskell.org> Message-ID: <059.f152dfc803c0e5b3637b920ee85804df@haskell.org> #8540: Template Haskell handling bug in ghc-7.7.20131115 ? -------------------------------------+------------------------------------ Reporter: awson | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: th/T8540 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"f3a841612e754536d635e8c970fb67453fb57cab/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="f3a841612e754536d635e8c970fb67453fb57cab" More faff to get GHCi's top-level environment right This fixes #8540 (again), and simplifies matters a bit more. In particular, I got rid of ic_sys_vars altogether. Mostly they can just go in ic_tythings, apart from dfuns, which are readily gettable from the instances anyway. See documentation in Note [Initialising the type environment for GHCi] in TcEnv. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 28 16:02:03 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Nov 2013 16:02:03 -0000 Subject: [GHC] #8540: Template Haskell handling bug in ghc-7.7.20131115 ? In-Reply-To: <044.a2405e435a0516e234d799c5d8afd594@haskell.org> References: <044.a2405e435a0516e234d799c5d8afd594@haskell.org> Message-ID: <059.edf1ffa02ebbeb715b65760feca9a408@haskell.org> #8540: Template Haskell handling bug in ghc-7.7.20131115 ? -------------------------------------+------------------------------------ Reporter: awson | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: th/T8540 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"3549b37d47304230de45648c379c1c4fd1460434/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="3549b37d47304230de45648c379c1c4fd1460434" Fixed Trac #8540 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 28 16:02:26 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Nov 2013 16:02:26 -0000 Subject: [GHC] #8540: Template Haskell handling bug in ghc-7.7.20131115 ? In-Reply-To: <044.a2405e435a0516e234d799c5d8afd594@haskell.org> References: <044.a2405e435a0516e234d799c5d8afd594@haskell.org> Message-ID: <059.07b029350c9a4eabfefc6fdd8613dcf7@haskell.org> #8540: Template Haskell handling bug in ghc-7.7.20131115 ? -------------------------------------+------------------------------------ Reporter: awson | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: th/T8540 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonpj): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 28 16:06:51 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Nov 2013 16:06:51 -0000 Subject: [GHC] #8557: Panic "tcTyVarDetails" when :forcing a kind-polymorphic data family instance In-Reply-To: <047.ee19f9cb863bee77e253732f4bf91ce3@haskell.org> References: <047.ee19f9cb863bee77e253732f4bf91ce3@haskell.org> Message-ID: <062.f0264e4f8e1fa49dfa6a931a335b6344@haskell.org> #8557: Panic "tcTyVarDetails" when :forcing a kind-polymorphic data family instance -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"45f2d29d59dcff2a5aebb5aae00e217f8f2a532c/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="45f2d29d59dcff2a5aebb5aae00e217f8f2a532c" Test Trac #8557 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 28 16:07:15 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Nov 2013 16:07:15 -0000 Subject: [GHC] #8557: Panic "tcTyVarDetails" when :forcing a kind-polymorphic data family instance In-Reply-To: <047.ee19f9cb863bee77e253732f4bf91ce3@haskell.org> References: <047.ee19f9cb863bee77e253732f4bf91ce3@haskell.org> Message-ID: <062.d53a8a7bc70aabbc42de3d59c6e1c43c@haskell.org> #8557: Panic "tcTyVarDetails" when :forcing a kind-polymorphic data family instance ------------------------------------------------+-------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: ghci.debugger/scripts/T8557 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by simonpj): * status: new => closed * testcase: => ghci.debugger/scripts/T8557 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 28 16:52:34 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Nov 2013 16:52:34 -0000 Subject: [GHC] #8570: In a pattern binding:ghc: panic! (the 'impossible' happened): Bogus selector Id In-Reply-To: <050.1bd463d4d609cd00d0e900b5cf4e1272@haskell.org> References: <050.1bd463d4d609cd00d0e900b5cf4e1272@haskell.org> Message-ID: <065.86e89877552613ef73e346ddeabbb32d@haskell.org> #8570: In a pattern binding:ghc: panic! (the 'impossible' happened): Bogus selector Id ---------------------------------------+---------------------------------- Reporter: rzetterberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Comment (by simonpj): I can't reproduce this. Here are the modules I used. I used these modules: {{{ module T8570a where data Image = Image { id :: Integer , categoryId :: Integer , name :: String , filepath :: String } deriving (Show) module T8570b where data Field = Password String | Image Int module T8570 where import T8570a (Image(filepath)) import T8570b (Field(..)) foo logo = fp where Image{filepath = fp} = logo }}} I compiled thus: {{{ bash$ ghc -c T8570a.hs bash$ ghc -c T8570b.hs bash$ ghc -c T8570.hs T8570.hs:6:27: Constructor `Image' does not have field `filepath' In the pattern: Image {filepath = fp} In a pattern binding: Image {filepath = fp} = logo In an equation for `foo': foo logo = fp where Image {filepath = fp} = logo }}} I tried with ghc-7.6.3 and HEAD. They all work fine. Can you offer a precise, reproducible test case? Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 28 17:11:01 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Nov 2013 17:11:01 -0000 Subject: [GHC] #8570: In a pattern binding:ghc: panic! (the 'impossible' happened): Bogus selector Id In-Reply-To: <050.1bd463d4d609cd00d0e900b5cf4e1272@haskell.org> References: <050.1bd463d4d609cd00d0e900b5cf4e1272@haskell.org> Message-ID: <065.0706b0e01a123f799bc720c8ec68e444@haskell.org> #8570: In a pattern binding:ghc: panic! (the 'impossible' happened): Bogus selector Id ---------------------------------------+---------------------------------- Reporter: rzetterberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Comment (by parcs): I can reproduce the error if `logo` is defined and imported from the module that defines `data Image`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 28 17:12:20 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Nov 2013 17:12:20 -0000 Subject: [GHC] #7962: "ghc -e " should return non-zero exit status In-Reply-To: <046.b219f88aa753aa2b186103bc8ef072c0@haskell.org> References: <046.b219f88aa753aa2b186103bc8ef072c0@haskell.org> Message-ID: <061.131fb14adc02b5a08d2f8fb66b4ea0fb@haskell.org> #7962: "ghc -e " should return non-zero exit status ------------------------------------+------------------------------------ Reporter: timmaxw | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ------------------------------------+------------------------------------ Comment (by khyperia): Attached Simon's suggestion, and also some *possible* test files (which are, ironically, untested). I am not submitting them as a .patch because of their untested nature, and more of a "here's an example of what it might look like". Also, I thought it might be better if they go into testsuite/tests/ghc-e, not ghci. I'll go submit a ticket for the failing test suite now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 28 17:19:51 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Nov 2013 17:19:51 -0000 Subject: [GHC] #8571: Validation fails Message-ID: <047.033097cdeaab38530d03b9c092b94b8e@haskell.org> #8571: Validation fails ----------------------------------+--------------------------------- Reporter: khyperia | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.6.3 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------- {{{ =====> T5267(normal) 50 of 3812 [0, 0, 0] cd ./arrows/should_compile && 'c:/Users/Evan/Documents/ghc/bindisttest/install dir/bin/ghc.exe' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-us er-package-db -rtsopts -fno-ghci-history -c T5267.hs >T5267.comp.stderr 2>&1 Compile failed (status 256) errors were: T5267.hs:11:15: tee: standard output: Permission denied }}} followed by an infinite hang. If I comment out that specific test, another test fails a few tests later. If I comment out that one, another one fails a few later. If I comment out *that* one... you get the picture. Running as administrator does not solve the permission denied issue. I am on Windows 8.1, if that matters. I think, I am not sure, that any test with expect_broken in them hangs without moving on. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 28 17:29:12 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Nov 2013 17:29:12 -0000 Subject: [GHC] #8570: In a pattern binding:ghc: panic! (the 'impossible' happened): Bogus selector Id In-Reply-To: <050.1bd463d4d609cd00d0e900b5cf4e1272@haskell.org> References: <050.1bd463d4d609cd00d0e900b5cf4e1272@haskell.org> Message-ID: <065.a541e4f7e36f5b974d2b1654408ba52e@haskell.org> #8570: In a pattern binding:ghc: panic! (the 'impossible' happened): Bogus selector Id ---------------------------------------+---------------------------------- Reporter: rzetterberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Comment (by simonpj): Can you give me the code? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 28 17:40:38 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Nov 2013 17:40:38 -0000 Subject: [GHC] #8570: In a pattern binding:ghc: panic! (the 'impossible' happened): Bogus selector Id In-Reply-To: <050.1bd463d4d609cd00d0e900b5cf4e1272@haskell.org> References: <050.1bd463d4d609cd00d0e900b5cf4e1272@haskell.org> Message-ID: <065.9553232948b43af782b01eabb8a82ff6@haskell.org> #8570: In a pattern binding:ghc: panic! (the 'impossible' happened): Bogus selector Id ---------------------------------------+---------------------------------- Reporter: rzetterberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Comment (by parcs): This code reproduces the error: {{{ #!haskell module A where import B (Image(filepath), logo) import C (Field(Image)) foo = let Image {filepath = ()} = logo in () }}} {{{ module B where data Image = Image { filepath :: () } logo = Image () }}} {{{ module C where data Field = Image }}} {{{ $ ghc-stage2 A [1 of 3] Compiling C ( C.hs, C.o ) [2 of 3] Compiling B ( B.hs, B.o ) [3 of 3] Compiling A ( A.hs, A.o ) A.hs:6:18: Constructor ?Image? does not have field ?filepath? In the pattern: Image {filepath = ()} In a pattern binding: Image {filepath = ()} = logo In the expression: let Image {filepath = ()} = logo in () A.hs:6:35: Couldn't match expected type ?Field? with actual type ?Image? In the expression: logo In a pattern binding:ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20131127 for x86_64-unknown-linux): Bogus selector Id Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} One-shot mode behaves similarly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 28 19:06:30 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Nov 2013 19:06:30 -0000 Subject: [GHC] #8572: Building an empty module with profiling requires profiling libraries for integer-gmp Message-ID: <044.5aebbdf5a090b51634a7de92ab103ccd@haskell.org> #8572: Building an empty module with profiling requires profiling libraries for integer-gmp -------------------------------------------+------------------------------- Reporter: parcs | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.7 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- {{{ #!haskell {-# LANGUAGE NoImplicitPrelude #-} module A where }}} {{{ $ ghc-stage2 -prof -c A.hs Top level: Failed to load interface for ?GHC.Integer.Type? Perhaps you haven't installed the profiling libraries for package ?integer-gmp?? Use -v to see a list of the files searched for. }}} I can't built module `A` without profiling libraries for `integer-gmp`, even though I don't use `integer-gmp` anywhere in the module. This happens because the `Tidy Core` pass attempts to look up the `mkInteger` name (in order to desugar integer literals) even when there are no integer literals in the module. The obvious fix is to lazily look up `mkInteger` in `Coreprep.lookupMkIntegerName`: {{{ #!diff diff --git a/compiler/coreSyn/CorePrep.lhs b/compiler/coreSyn/CorePrep.lhs index 5e0cd65..9836982 100644 --- a/compiler/coreSyn/CorePrep.lhs +++ b/compiler/coreSyn/CorePrep.lhs @@ -56,6 +56,7 @@ import Config import Data.Bits import Data.List ( mapAccumL ) import Control.Monad +import System.IO.Unsafe ( unsafeInterleaveIO ) \end{code} -- --------------------------------------------------------------------------- @@ -1119,6 +1120,7 @@ lookupMkIntegerName dflags hsc_env else if thisPackage dflags == integerPackageId then return $ panic "Can't use Integer in integer" else liftM tyThingId + $ unsafeInterleaveIO $ initTcForLookup hsc_env (tcLookupGlobal mkIntegerName) mkInitialCorePrepEnv :: DynFlags -> HscEnv -> IO CorePrepEnv }}} This way, we don't attempt to look up `mkInteger` until we actually need it, i.e. if there are integer literals that we must desugar. Relevant commits are 2ef5cd26db27543ac8664a3d18f45550d0109a8b and fdd552e0ecaa17300670a48562995040e1d6687e -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 29 04:21:43 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Nov 2013 04:21:43 -0000 Subject: [GHC] #7962: "ghc -e " should return non-zero exit status In-Reply-To: <046.b219f88aa753aa2b186103bc8ef072c0@haskell.org> References: <046.b219f88aa753aa2b186103bc8ef072c0@haskell.org> Message-ID: <061.f1b51e850388425b5924d7382d56644f@haskell.org> #7962: "ghc -e " should return non-zero exit status ------------------------------------+------------------------------------ Reporter: timmaxw | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: GHCi | Version: 7.6.2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ------------------------------------+------------------------------------ Changes (by khyperia): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 29 07:31:54 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Nov 2013 07:31:54 -0000 Subject: [GHC] #8570: In a pattern binding:ghc: panic! (the 'impossible' happened): Bogus selector Id In-Reply-To: <050.1bd463d4d609cd00d0e900b5cf4e1272@haskell.org> References: <050.1bd463d4d609cd00d0e900b5cf4e1272@haskell.org> Message-ID: <065.1bb0d6e2772a13b6977e0dcd648563b6@haskell.org> #8570: In a pattern binding:ghc: panic! (the 'impossible' happened): Bogus selector Id ---------------------------------------+---------------------------------- Reporter: rzetterberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"59e17d6ef71c29f4e114e55be83f1b3722f04139/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="59e17d6ef71c29f4e114e55be83f1b3722f04139" Fail (rather than addErr) if you use a bogus field in a pattern This fixes Trac #8570 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 29 07:32:05 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Nov 2013 07:32:05 -0000 Subject: [GHC] #8570: In a pattern binding:ghc: panic! (the 'impossible' happened): Bogus selector Id In-Reply-To: <050.1bd463d4d609cd00d0e900b5cf4e1272@haskell.org> References: <050.1bd463d4d609cd00d0e900b5cf4e1272@haskell.org> Message-ID: <065.607d309b1e96d550ec77f2f82497890f@haskell.org> #8570: In a pattern binding:ghc: panic! (the 'impossible' happened): Bogus selector Id ---------------------------------------+---------------------------------- Reporter: rzetterberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"5f3c989258205158c523fbe218d52394f6a28cb8/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="5f3c989258205158c523fbe218d52394f6a28cb8" Wibbles when fixing Trac #8570 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 29 07:32:05 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Nov 2013 07:32:05 -0000 Subject: [GHC] #8570: In a pattern binding:ghc: panic! (the 'impossible' happened): Bogus selector Id In-Reply-To: <050.1bd463d4d609cd00d0e900b5cf4e1272@haskell.org> References: <050.1bd463d4d609cd00d0e900b5cf4e1272@haskell.org> Message-ID: <065.5a0a04a2cab59831eb62c556cd2b48bb@haskell.org> #8570: In a pattern binding:ghc: panic! (the 'impossible' happened): Bogus selector Id ---------------------------------------+---------------------------------- Reporter: rzetterberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"162765e02c0b2acfc731d47362c37db6cf00fcdf/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="162765e02c0b2acfc731d47362c37db6cf00fcdf" Test Trac #8570 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 29 07:45:09 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Nov 2013 07:45:09 -0000 Subject: [GHC] #8570: In a pattern binding:ghc: panic! (the 'impossible' happened): Bogus selector Id In-Reply-To: <050.1bd463d4d609cd00d0e900b5cf4e1272@haskell.org> References: <050.1bd463d4d609cd00d0e900b5cf4e1272@haskell.org> Message-ID: <065.936ea04950b856d08324d5f87f970b04@haskell.org> #8570: In a pattern binding:ghc: panic! (the 'impossible' happened): Bogus selector Id ---------------------------------------+---------------------------------- Reporter: rzetterberg | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: Thank you! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 29 07:45:29 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Nov 2013 07:45:29 -0000 Subject: [GHC] #8570: In a pattern binding:ghc: panic! (the 'impossible' happened): Bogus selector Id In-Reply-To: <050.1bd463d4d609cd00d0e900b5cf4e1272@haskell.org> References: <050.1bd463d4d609cd00d0e900b5cf4e1272@haskell.org> Message-ID: <065.91f5afba3d7ae1ca23ee285e49314d02@haskell.org> #8570: In a pattern binding:ghc: panic! (the 'impossible' happened): Bogus selector Id ------------------------------------------------+-------------------------- Reporter: rzetterberg | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time crash | (amd64) Test Case: typecheck/should_fail/T8570 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by simonpj): * testcase: => typecheck/should_fail/T8570 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 29 09:26:16 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Nov 2013 09:26:16 -0000 Subject: [GHC] #8266: Dynamic linking on Mac In-Reply-To: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> References: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> Message-ID: <067.8719403be9196cde82e16b15aa1e0a12@haskell.org> #8266: Dynamic linking on Mac --------------------------------------------+------------------------------ Reporter: kazu-yamamoto | Owner: Type: bug | thoughtpolice Priority: highest | Status: closed Component: Build System | Milestone: 7.8.1 Resolution: fixed | Version: 7.7 Operating System: MacOS X | Keywords: Type of failure: GHC doesn't work at all | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by darchon): The `LC_RPATH` value tells me that you're using the GHC binary from `/inplace/`. But how, and why, are you using the GHC binary from `/inplace/`, while using the libraries from `/bindisttest/install dir/`? If you're using the libraries from `/bindisttest/install dir/`, then why wouldn't you be using the GHC binary from `/bindisttest/install dir/`? I feel that this ticket should stay closed, as the original problem (references to the build directory) is fixed; //normal// users of GHC are no longer affected. However, I agree that the current design could be improved for //advanced// users and GHC developers. So perhaps you can file a feature request that specifically states your needs/use-case that is not met by the current design? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 29 09:39:33 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Nov 2013 09:39:33 -0000 Subject: [GHC] #8569: ASSERT in testcase type-rep, only in some ways: In-Reply-To: <046.d7161ae2625fe2a79685c11907883efc@haskell.org> References: <046.d7161ae2625fe2a79685c11907883efc@haskell.org> Message-ID: <061.ddf2829d25ccc16736518b9b1a9d13bd@haskell.org> #8569: ASSERT in testcase type-rep, only in some ways: -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): I have a freshly cleaned and built master checkout here, and it is reproducible again (using `make -C testsuite TEST="type-rep"`) Note that this patch is marked as `skip()` when running `make -C testsuite fast`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 29 09:55:12 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Nov 2013 09:55:12 -0000 Subject: [GHC] #8569: ASSERT in testcase type-rep, only in some ways: In-Reply-To: <046.d7161ae2625fe2a79685c11907883efc@haskell.org> References: <046.d7161ae2625fe2a79685c11907883efc@haskell.org> Message-ID: <061.99dc5c0914b752acdec8aff8a6c7074b@haskell.org> #8569: ASSERT in testcase type-rep, only in some ways: -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Minimalizing the example yields {{{ module Example (x) where data Rep t where Rint :: Rep Int Rdata :: Rep i -> (t -> i) -> (i -> t) -> Rep t addUp :: Rep a -> a -> Int addUp Rint n = n addUp (Rdata i f g) x = addUp i (f x) x = addUp undefined [1] }}} Again, the problem only occurs with `-O`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 29 09:59:36 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Nov 2013 09:59:36 -0000 Subject: [GHC] #8266: Dynamic linking on Mac In-Reply-To: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> References: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> Message-ID: <067.a090ad523275b555d3bde9c451f96759@haskell.org> #8266: Dynamic linking on Mac --------------------------------------------+------------------------------ Reporter: kazu-yamamoto | Owner: Type: bug | thoughtpolice Priority: highest | Status: closed Component: Build System | Milestone: 7.8.1 Resolution: fixed | Version: 7.7 Operating System: MacOS X | Keywords: Type of failure: GHC doesn't work at all | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by amosrobinson): I'm using the binary from `inplace/bin/` because that's how I've always done it - I thought that //was// the //normal// way. The only reason I was using libraries from `bindisttest/install dir/lib/` is because that's how I managed to get it to work. OK! So, if I set my path to `bindisttest/install dir/bin/` instead of `inplace/bin/` it works without the dodgy symlinks. That's good enough for now. I feel that this is a bug: it was my understanding `inplace` is supposed to work the same as an installed copy, but I'll file a separate ticket. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 29 10:13:59 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Nov 2013 10:13:59 -0000 Subject: [GHC] #8569: ASSERT in testcase type-rep, only in some ways: In-Reply-To: <046.d7161ae2625fe2a79685c11907883efc@haskell.org> References: <046.d7161ae2625fe2a79685c11907883efc@haskell.org> Message-ID: <061.5501efa6ef5a71c2d83f0b48ac0796c4@haskell.org> #8569: ASSERT in testcase type-rep, only in some ways: -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): I believe the problem is a mis-calculated demand for `addUp`: {{{ Rec { Example.addUp [Occ=LoopBreaker] :: forall a_aqp. Example.Rep a_aqp -> a_aqp -> GHC.Types.Int [LclIdX, Arity=2, Str=DmdType , Unf=Unf{Src=, TopLvl=True, Arity=2, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [30 0] 70 0}] Example.addUp = \ (@ a_aBI) (ds_dBY [Dmd=] :: Example.Rep a_aBI) (n_aqq [Dmd=] :: a_aBI) -> case ds_dBY of _ { Example.Rint dt_dC2 [Dmd=] -> n_aqq `cast` (Sub dt_dC2 :: a_aBI ~# GHC.Types.Int); Example.Rdata @ i_aBR i_aqr [Dmd=] f_aqs [Dmd=] g_aqt [Dmd=] -> Example.addUp @ i_aBR i_aqr (f_aqs n_aqq) } end Rec } }}} The demand on its first argument, `U(U)`, clearly comes from the `Rint` case (where it is true), but in the other case this demand does not even type-check, as `a` can be some other type. So what goes wrong here?.. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 29 10:45:15 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Nov 2013 10:45:15 -0000 Subject: [GHC] #8569: ASSERT in testcase type-rep, only in some ways: In-Reply-To: <046.d7161ae2625fe2a79685c11907883efc@haskell.org> References: <046.d7161ae2625fe2a79685c11907883efc@haskell.org> Message-ID: <061.1a97ea8ad48c9d6bd13310140ece906c@haskell.org> #8569: ASSERT in testcase type-rep, only in some ways: -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Here we go: {{{ dmdAnal:Case2 scrut ds_dBX{v} [lid] scrut_ty DmdType {dBX->} alt_tys [DmdType {aqq->}, DmdType {aqq->}] alt_ty DmdType {aqq->} res_ty DmdType {aqq-> dBX->} }}} If I read this correct, in human terms, this tell me ?The first case branch will use `aqq` (=`n`) at most once, and will take the box apart and use what?s inside, while do not know anything about how the right case branch uses `n`. The scrutinee does not talk about `n` at all. Therefore, the whole expression uses `n` in an unknown number of times, and also uses what?s inside?. This sounds wrong to me (but I?m not firm on reading demand signatures yet). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 29 10:52:08 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Nov 2013 10:52:08 -0000 Subject: [GHC] #2233: Overhaul System.Process In-Reply-To: <047.24a366415ff9b59c03e5bf49850898a6@haskell.org> References: <047.24a366415ff9b59c03e5bf49850898a6@haskell.org> Message-ID: <062.3a862d87f444895789153bfad801cc12@haskell.org> #2233: Overhaul System.Process --------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: task | Status: patch Priority: normal | Milestone: _|_ Component: libraries/process | Version: 6.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by duncan): hvr noticed that a test was failing. I noticed that the `ignoreSigPipe` should be cover the hFlush ''as well'' (my fault). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 29 10:59:29 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Nov 2013 10:59:29 -0000 Subject: [GHC] #8569: ASSERT in testcase type-rep, only in some ways: In-Reply-To: <046.d7161ae2625fe2a79685c11907883efc@haskell.org> References: <046.d7161ae2625fe2a79685c11907883efc@haskell.org> Message-ID: <061.ec60c21cf845449e0d2d98fd819bb508@haskell.org> #8569: ASSERT in testcase type-rep, only in some ways: -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Tracing this further I find this equation: {{{ lubUse :: UseDmd -> UseDmd -> UseDmd [..] lubUse (UProd ux1) (UProd ux2) | length ux1 == length ux2 = UProd $ zipWith lubMaybeUsed ux1 ux2 | otherwise = Used lubUse (UProd {}) (UCall {}) = Used -- lubUse (UProd {}) Used = Used lubUse (UProd ux) Used = UProd (map (`lubMaybeUsed` useTop) ux) lubUse Used (UProd ux) = UProd (map (`lubMaybeUsed` useTop) ux) [...] lubUse Used _ = Used -- Note [Used should win] }}} Note that `UProd` lub?ed with `Used` yields `UProd`. This contradicts the note `Used should win`. Time for some git archeology... hmm, seems to be like this since dawn of time`^W`the demand analyzer. And as long as no GADTs are around, it probably does not cause problems. A simple fix would be to change that equation, but surely there are reasons for it... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 29 11:40:50 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Nov 2013 11:40:50 -0000 Subject: [GHC] #8569: ASSERT in testcase type-rep, only in some ways: In-Reply-To: <046.d7161ae2625fe2a79685c11907883efc@haskell.org> References: <046.d7161ae2625fe2a79685c11907883efc@haskell.org> Message-ID: <061.01c77c8c5fb182a4201d3f5c9832e3ce@haskell.org> #8569: ASSERT in testcase type-rep, only in some ways: -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): This might be related to Note [Don't optimise UProd(Used) to Used]. There it says > But with the joint demand of doesn't convey any clue > that there is a product involved, and so the worthSplittingFun > will not fire. (We'd need to use the type as well to make it fire.) so all this trouble of non-canonical demands just to give some bit of information to `worthSplittingFun`, which can probably get this information from `tryWW`, which knows whether the type really is a product type (and not a type variable that was a product type in one branch of a case of the body)? Or are there likely other reasons to keep `UProd(Used)` instead of `UProd`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 29 14:43:37 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Nov 2013 14:43:37 -0000 Subject: [GHC] #8573: "evacuate: strange closure type 0" when creating large array Message-ID: <042.f5cd7a98abbf8cf5e70fa72eb7020fdc@haskell.org> #8573: "evacuate: strange closure type 0" when creating large array ----------------------------+---------------------------------- Reporter: nad | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+---------------------------------- Consider the following code: {{{ module Main where import Data.Array xs :: [Int] xs = [0 .. 64988] crash :: Int -> IO () crash m = array (0, m) [ (x, x) | x <- xs ] `seq` return () strangeClosureType = do print (sum xs) crash (maxBound - 1) segFault1 = crash (maxBound - 1) segFault2 = do print (sum xs) crash (maxBound - 2) }}} If I compile the program using `ghc --make Main.hs -O -main-is strangeClosureType`, then I get the following error message: {{{ Main: internal error: evacuate: strange closure type 0 (GHC version 7.6.3 for i386_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) }}} If I don't use `-O`, or if I let `segFault1` or `segFault2` be `main`, then I get the following error message instead: {{{ Segmentation fault (core dumped) }}} If the number `30000` is replaced by some other number, then the strange closure error may be replaced by a segfault, or even no error at all. Perhaps this is another instance of bug #7762; I have only tested using GHC 7.6.3. I am using base 4.6.0.1 and array 0.4.0.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 29 14:46:15 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Nov 2013 14:46:15 -0000 Subject: [GHC] #8573: "evacuate: strange closure type 0" when creating large array In-Reply-To: <042.f5cd7a98abbf8cf5e70fa72eb7020fdc@haskell.org> References: <042.f5cd7a98abbf8cf5e70fa72eb7020fdc@haskell.org> Message-ID: <057.3e833a666adc48408792b19f864ca75f@haskell.org> #8573: "evacuate: strange closure type 0" when creating large array ----------------------------------+--------------------------- Reporter: nad | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+--------------------------- Comment (by nad): 30000 should be 64988 (or vice versa). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 29 15:14:05 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Nov 2013 15:14:05 -0000 Subject: [GHC] #8574: Failure to require FlexibleContexts Message-ID: <048.e75c50ddb32d42d63f97cf8a5630ba59@haskell.org> #8574: Failure to require FlexibleContexts --------------------------+------------------------------------------------ Reporter: | Owner: Feuerbach | Status: new Type: bug | Milestone: Priority: normal | Version: 7.6.3 Component: | Operating System: Unknown/Multiple Compiler (Parser) | Type of failure: GHC accepts invalid program Keywords: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ GHC accepts the following code without any extensions: {{{ f :: Ord (i Int) => i Int -> i Int f = undefined }}} It ought to require FlexibleContexts. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 29 18:56:54 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Nov 2013 18:56:54 -0000 Subject: [GHC] #8275: Loopification breaks profiling In-Reply-To: <048.63a98da772d0fcd943c3debc22ba0a20@haskell.org> References: <048.63a98da772d0fcd943c3debc22ba0a20@haskell.org> Message-ID: <063.4bf13a788db5ff135e689e7d15f8c8c9@haskell.org> #8275: Loopification breaks profiling ----------------------------------------+---------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: Profiling | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: 8456 | Related Tickets: ----------------------------------------+---------------------------------- Changes (by parcs): * status: new => patch Comment: I have attached a patch that fixes loopification with profiling. The problem is that `nodeReg` aka R1 may get clobbered inside the body of a closure. With profiling, upon entering a closure, `enterFunCCS` is called with R1 passed to it. But since R1 may get clobbered inside the body of a closure, and since a self-recursive tail call does not restore R1, a subsequent call to `enterFunCCS` may be passed a bogus value from R1. The solution is to not pass `nodeReg` aka R1 to `enterFunCCS`. Instead, we pass `node`, the callee-saved temporary that stores the original value of R1. This way R1 may get clobbered and loopification will not care. I don't know whether it's necessary to re-run the LDV code after looping. Not doing so certainly does not cause a segfault, anyway. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 29 19:09:46 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Nov 2013 19:09:46 -0000 Subject: [GHC] #8569: ASSERT in testcase type-rep, only in some ways: In-Reply-To: <046.d7161ae2625fe2a79685c11907883efc@haskell.org> References: <046.d7161ae2625fe2a79685c11907883efc@haskell.org> Message-ID: <061.2ab94f44e07a049a0091ea9cd459cee4@haskell.org> #8569: ASSERT in testcase type-rep, only in some ways: -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Joachim Breitner ): In [changeset:"c9d164ac641fca43134201672db15c333d90805c/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="c9d164ac641fca43134201672db15c333d90805c" Add test case for #8569 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 29 20:39:37 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Nov 2013 20:39:37 -0000 Subject: [GHC] #8275: Loopification breaks profiling In-Reply-To: <048.63a98da772d0fcd943c3debc22ba0a20@haskell.org> References: <048.63a98da772d0fcd943c3debc22ba0a20@haskell.org> Message-ID: <063.98d4550d0dad34a1b8757bedab0d28bd@haskell.org> #8275: Loopification breaks profiling ----------------------------------------+---------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: Profiling | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: 8456 | Related Tickets: ----------------------------------------+---------------------------------- Comment (by jstolarek): Thanks Patrick! Currently I'm without my main laptop so I can't verify your patch - I will do it in Wednesday, unless someone else can do it before. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 29 20:57:52 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Nov 2013 20:57:52 -0000 Subject: [GHC] #8575: remove obsolete "stolen syntax" Message-ID: <045.e5f2024095fb54d9f5947b51c232359d@haskell.org> #8575: remove obsolete "stolen syntax" ------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Hi. The quasiquotes ```[:x| |]``` and implicitparams ```%x``` syntax listed as stolen have not been stolen for a long time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 29 21:06:50 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Nov 2013 21:06:50 -0000 Subject: [GHC] #8275: Loopification breaks profiling In-Reply-To: <048.63a98da772d0fcd943c3debc22ba0a20@haskell.org> References: <048.63a98da772d0fcd943c3debc22ba0a20@haskell.org> Message-ID: <063.a272e38b687dfa07b98843d9951a4ef7@haskell.org> #8275: Loopification breaks profiling ----------------------------------------+---------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: Profiling | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: 8456 | Related Tickets: ----------------------------------------+---------------------------------- Comment (by parcs): Replying to [comment:33 jstolarek]: > Thanks Patrick! Currently I'm without my main laptop so I can't verify your patch - I will do it in Wednesday, unless someone else can do it before. Okay, great. And here's an ugly PoC patch that moves the self-loop label below the stack check: {{{ #!diff diff --git a/compiler/codeGen/StgCmmBind.hs b/compiler/codeGen/StgCmmBind.hs index 16477c8..029b8af 100644 --- a/compiler/codeGen/StgCmmBind.hs +++ b/compiler/codeGen/StgCmmBind.hs @@ -481,7 +481,6 @@ closureCodeBody top_lvl bndr cl_info cc args arity body fv_details -- of a self-recursive tail call. See Note -- [Self-recursive tail calls] in StgCmmExpr ; loop_header_id <- newLabelC - ; emitLabel loop_header_id -- Extend reader monad with information that -- self-recursive tail calls can be optimized into local -- jumps diff --git a/compiler/codeGen/StgCmmHeap.hs b/compiler/codeGen/StgCmmHeap.hs index 55ddfd4..f01d042 100644 --- a/compiler/codeGen/StgCmmHeap.hs +++ b/compiler/codeGen/StgCmmHeap.hs @@ -615,6 +615,12 @@ do_checks mb_stk_hwm checkYield mb_alloc_lit do_gc = do Nothing -> return () Just stk_hwm -> tickyStackCheck >> (emit =<< mkCmmIfGoto (sp_oflo stk_hwm) gc_id) + self_loop_info <- getSelfLoop + case self_loop_info of + Just (_,loop_header_id,_) + | checkYield && isJust mb_stk_hwm -> emitLabel loop_header_id + _otherwise -> return () + if (isJust mb_alloc_lit) then do tickyHeapCheck }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 29 21:20:34 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Nov 2013 21:20:34 -0000 Subject: [GHC] #7240: Stack trace truncated too much with indirect recursion In-Reply-To: <046.c2e439432b2547033f57bf5a4e994245@haskell.org> References: <046.c2e439432b2547033f57bf5a4e994245@haskell.org> Message-ID: <061.5d259d6de62e9fb2e11cff181219c580@haskell.org> #7240: Stack trace truncated too much with indirect recursion -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Profiling | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by nomeata): * owner: nomeata => Comment: I kind stopped working on this, thus unowning me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 29 21:25:43 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Nov 2013 21:25:43 -0000 Subject: [GHC] #8576: Improve deriving error messages Message-ID: <046.f04aff3ace8ba1f81c9f829b37cc4f2d@haskell.org> #8576: Improve deriving error messages -------------------------------------------+------------------------------- Reporter: nomeata | Owner: nomeata Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type checker) | Version: Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- Instead of {{{ No instance for (Eq (Int -> Bool)) arising from the 'deriving' clause of a data type declaration Possible fix: add an instance declaration for (Eq (Int -> Bool)) or use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (Eq Foo) }}} for {{{ data Foo = Foo Int (Int -> Bool, Bool) deriving Eq }}} we want something like {{{ No instance for (Eq (Int -> Bool)) arising from the second field of the constructor Foo Possible fix: add an instance declaration for (Eq (Int -> Bool)) or use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (Eq Foo) }}} where we tell the user more precisely from where in its data type the problem comes from. Should be possible by beefing up `CtOrigin`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 29 21:30:28 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Nov 2013 21:30:28 -0000 Subject: [GHC] #8567: Poor error message when GeneralizedNewtypeDeriving fails In-Reply-To: <047.019b4a48a0a3d68a214e0cd69bcf8b30@haskell.org> References: <047.019b4a48a0a3d68a214e0cd69bcf8b30@haskell.org> Message-ID: <062.575b3636ce8d878ccb2a2d2a08924310@haskell.org> #8567: Poor error message when GeneralizedNewtypeDeriving fails -------------------------------------+------------------------------------ Reporter: goldfire | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by nomeata): * owner: => nomeata Comment: In discussion with SPJ, we thought about how we can catch missing instances already in the code for deriving, at least for non-standalone- deriving. I?ll work on that, and on making the error message a bit nicer. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 29 21:47:36 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Nov 2013 21:47:36 -0000 Subject: [GHC] #8575: remove obsolete "stolen syntax" In-Reply-To: <045.e5f2024095fb54d9f5947b51c232359d@haskell.org> References: <045.e5f2024095fb54d9f5947b51c232359d@haskell.org> Message-ID: <060.a87fabb25d31ac1e8e828533017b58c4@haskell.org> #8575: remove obsolete "stolen syntax" -------------------------------------+------------------------------------ Reporter: aavogt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Krzysztof Gogolewski ): In [changeset:"2e3c6a53330de8ed9e1dcbc8ab43c9405a3a89be/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="2e3c6a53330de8ed9e1dcbc8ab43c9405a3a89be" Update "stolen syntax" section (#8575) Thanks to aavogt }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 29 21:48:41 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Nov 2013 21:48:41 -0000 Subject: [GHC] #8575: remove obsolete "stolen syntax" In-Reply-To: <045.e5f2024095fb54d9f5947b51c232359d@haskell.org> References: <045.e5f2024095fb54d9f5947b51c232359d@haskell.org> Message-ID: <060.359307d2af4581e3c242dcf3357b108d@haskell.org> #8575: remove obsolete "stolen syntax" -------------------------------------+------------------------------------ Reporter: aavogt | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by monoidal): * status: new => closed * resolution: => fixed Comment: I've pushed it, thanks. Also added typed TH syntax. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 29 22:10:23 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Nov 2013 22:10:23 -0000 Subject: [GHC] #8266: Dynamic linking on Mac In-Reply-To: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> References: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> Message-ID: <067.195648d021525d4e2fcd3c713603a7c2@haskell.org> #8266: Dynamic linking on Mac --------------------------------------------+------------------------------ Reporter: kazu-yamamoto | Owner: Type: bug | thoughtpolice Priority: highest | Status: closed Component: Build System | Milestone: 7.8.1 Resolution: fixed | Version: 7.7 Operating System: MacOS X | Keywords: Type of failure: GHC doesn't work at all | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by thoughtpolice): Not being able to use the built inplace compiler as if it was a regular compiler is absolutely, 100% a bug. This is a crucial way to test GHC builds IMO without throwing installations everywhere on your `$PATH`, and is particularly useful for stress testing packages, since you can `cabal install -w ~/ghc-src/inplace/bin/ghc-stage2` to have it act normally. This also works on all other platforms. I missed this when I merged that patch. I'll investigate it ASAP. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 29 23:24:18 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Nov 2013 23:24:18 -0000 Subject: [GHC] #8577: Polymorphism and typed TH Message-ID: <047.42718c612858c204c7b6a7535f3af16b@haskell.org> #8577: Polymorphism and typed TH ------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Consider {{{ data A a = A x = [||A||] y = x :: Q (TExp (A Int)) }}} `$$x` is given type `A a`, as expected. However, `$$y` is also given type `A a`. I would expect it to be `A Int`. In other words, given `p :: Q (TExp T1), $$p :: T2` I think GHC should verify the equation `T1 ~ T2`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 30 00:40:14 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Nov 2013 00:40:14 -0000 Subject: [GHC] #7396: Improve "parse error on input `$'" when TemplateHaskell PRAGMA not declared In-Reply-To: <045.6c29ee0e9781fd9f6a3d1232f4250abc@haskell.org> References: <045.6c29ee0e9781fd9f6a3d1232f4250abc@haskell.org> Message-ID: <060.2d7d9bfdb2a64e45bdd5fdc0e9ba2849@haskell.org> #7396: Improve "parse error on input `$'" when TemplateHaskell PRAGMA not declared ----------------------------------------+--------------------------- Reporter: ydewit | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.4.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+--------------------------- Changes (by parcs): * status: closed => new * resolution: wontfix => Comment: Hi, This set of three patches augments errors that may be caused by not having TH enabled, to suggest enabling TH. Parse errors like the following will now suggest enabling TemplateHaskell: {{{ module A where $foo }}} {{{ module B where foo }}} {{{ module C where bar = 3 + $(x) }}} Of course, these are only heuristics so there will be false-positive and false-negative cases. But I think these heuristics will help more than they will hurt. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 30 00:40:24 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Nov 2013 00:40:24 -0000 Subject: [GHC] #7396: Improve "parse error on input `$'" when TemplateHaskell PRAGMA not declared In-Reply-To: <045.6c29ee0e9781fd9f6a3d1232f4250abc@haskell.org> References: <045.6c29ee0e9781fd9f6a3d1232f4250abc@haskell.org> Message-ID: <060.8d0940a0df292b1e16e78db816868b14@haskell.org> #7396: Improve "parse error on input `$'" when TemplateHaskell PRAGMA not declared ----------------------------------------+--------------------------- Reporter: ydewit | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: Template Haskell | Version: 7.4.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+--------------------------- Changes (by parcs): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 30 01:32:36 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Nov 2013 01:32:36 -0000 Subject: [GHC] #8578: Improvements to SpinLock implementation Message-ID: <044.7d4d696b896537d8c685483f715ea999@haskell.org> #8578: Improvements to SpinLock implementation ------------------------------------+------------------------------------- Reporter: parcs | Owner: parcs Type: task | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The SpinLock implementation has a number of deficiencies. Here is a pair of patches that improves its implementation. Let me know what you think. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 30 01:33:15 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Nov 2013 01:33:15 -0000 Subject: [GHC] #8578: Improvements to SpinLock implementation In-Reply-To: <044.7d4d696b896537d8c685483f715ea999@haskell.org> References: <044.7d4d696b896537d8c685483f715ea999@haskell.org> Message-ID: <059.f09199394ef619c30c207903c6d7512e@haskell.org> #8578: Improvements to SpinLock implementation -------------------------------------+------------------------------------ Reporter: parcs | Owner: parcs Type: task | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by parcs): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 30 04:53:19 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Nov 2013 04:53:19 -0000 Subject: [GHC] #8578: Improvements to SpinLock implementation In-Reply-To: <044.7d4d696b896537d8c685483f715ea999@haskell.org> References: <044.7d4d696b896537d8c685483f715ea999@haskell.org> Message-ID: <059.4396df79ea939987deeb7bb1b09d36c4@haskell.org> #8578: Improvements to SpinLock implementation -------------------------------------+------------------------------------ Reporter: parcs | Owner: parcs Type: task | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by parcs): According to a C microbenchmark, the new spinlock code is much more scalable than the old code. However, this scalability improvement remains to be seen in a GHC program. Is there a program one can test that is particularly sensitive to the scalability of the RTS's spinlocks? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 30 09:12:27 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Nov 2013 09:12:27 -0000 Subject: [GHC] #8266: Dynamic linking on Mac In-Reply-To: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> References: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> Message-ID: <067.5b09d6c4f04828a36bb8f8186c495105@haskell.org> #8266: Dynamic linking on Mac --------------------------------------------+------------------------------ Reporter: kazu-yamamoto | Owner: Type: bug | thoughtpolice Priority: highest | Status: closed Component: Build System | Milestone: 7.8.1 Resolution: fixed | Version: 7.7 Operating System: MacOS X | Keywords: Type of failure: GHC doesn't work at all | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by darchon): I currently don't have my OS X machine, so I can't make the patch right now. But the patch should be "straightforward": just make OS X (MACH-O) behave the same way as Linux (ELF). I guess this whole mess started in the first place because MACH-O only has absolute paths to dynamic libraries. Currently on OS X there's a single point of reference, an `@rpath`, that's pointing to a `lib/` directory, and expecting all libraries bundled with GHC to be there. This should be changed to multiple `@rpath`s. So the current situation looks like this: {{{ -- Installed by GHC install @rpath/package1-package1version/package1.dylib @rpath/package2-package1version/package2.dylib @rpath/package3-package1version/package3.dylib -- Installed by Cabal /absolute_path_to_library/package4.dylib /absolute_path_to_library/package5.dylib }}} Where a executable gets an `@rpath` pointing to the same location as the value of `ghc --print-libdir`. With the exception of the GHC binary, which has an `@rpath` pointing to `@loader_path/..`. The new situation should be: {{{ -- Installed by GHC install @rpath/package1.dylib @rpath/package2.dylib @rpath/package3.dylib -- Installed by Cabal @rpath/package4.dylib @rpath/package5.dylib }}} Where: * Libraries bundled with GHC should get, for all transitively depending libraries, an `@rpath` pointing to `@loader_path/../dependentpackage/` (similar to the situation on Linux, which uses `$ORIGIN/../dependentpackage/`) * The GHC executable should get, for all transitively depending libraries, an `@rpath` pointing to `@loader_path/../dependentpackage/` (again similar to Linux) * Libraries installed by Cabal should get, for all transitively depending library, an `@rpath` pointing to `/absolute_path_to_package` (similar to linux) * Executables should get, for all transitively depending libraries, an `@rpath` pointing to `/absolute_path_to_package` (similar to linux) This patch would involve adding a code-path for OS-X/MACH-O similar to lines 1757-1776 in `compiler/main/DriverPipeline.hs`, and of course changing `rules/relative-dynlib-references.mk`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 30 10:49:06 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Nov 2013 10:49:06 -0000 Subject: [GHC] #8578: Improvements to SpinLock implementation In-Reply-To: <044.7d4d696b896537d8c685483f715ea999@haskell.org> References: <044.7d4d696b896537d8c685483f715ea999@haskell.org> Message-ID: <059.044defc6ee67a5e218412feaf91525d5@haskell.org> #8578: Improvements to SpinLock implementation -------------------------------------+------------------------------------ Reporter: parcs | Owner: parcs Type: task | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonmar): The patch looks like a nice improvement, thanks! Before committing I want to run some benchmarks. The usual ones I use are `nofib/parallel` running on various numbers of cores, at least 8. I can try these sometimes next week. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 30 13:27:47 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Nov 2013 13:27:47 -0000 Subject: [GHC] #8575: remove obsolete "stolen syntax" In-Reply-To: <045.e5f2024095fb54d9f5947b51c232359d@haskell.org> References: <045.e5f2024095fb54d9f5947b51c232359d@haskell.org> Message-ID: <060.3eb6c24447db3cc1b259c5ead6cb25a7@haskell.org> #8575: remove obsolete "stolen syntax" -------------------------------------+------------------------------------ Reporter: aavogt | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Krzysztof Gogolewski ): In [changeset:"de9f17e40ca99dd22653aa360bbc6dd27ba19b2f/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="de9f17e40ca99dd22653aa360bbc6dd27ba19b2f" Update "stolen syntax" section (#8575) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 30 13:48:15 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Nov 2013 13:48:15 -0000 Subject: [GHC] #8574: Failure to require FlexibleContexts In-Reply-To: <048.e75c50ddb32d42d63f97cf8a5630ba59@haskell.org> References: <048.e75c50ddb32d42d63f97cf8a5630ba59@haskell.org> Message-ID: <063.5d32edee2ca869a85bcf66b265ea64ad@haskell.org> #8574: Failure to require FlexibleContexts ------------------------------------------------+-------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts invalid program | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by monoidal): It seems this is valid Haskell 98: http://www.haskell.org/onlinereport/decls.html, section 4.1.3, the class is allowed to take `(tyvar atype1 ... atypen)` as an argument, and `atype` includes `Int`. But the [http://www.haskell.org/ghc/docs/7.6.3/html/users_guide/other- type-extensions.html documentation], section 7.8.2 claims Haskell 98 requires `(class (type-variable type-variable ...))` form. So I think this documentation should be changed to `(class (type-variable type type ...))`. Do you agree? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 30 14:23:21 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Nov 2013 14:23:21 -0000 Subject: [GHC] #8579: Loading a module in GHCi affects shadowing Message-ID: <047.a3d8af90e3aba7e66fe2065e6ddde916@haskell.org> #8579: Loading a module in GHCi affects shadowing ------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- In GHCi we can redefine a data declaration; last definition counts. But loading a module has a side effect of bringing the first declaration to front: {{{ ?> data A = X ?> data A = Y ?> :i A data A = Y -- Defined at :3:6 ?> :m Data.List ?> :i A data A = X -- Defined at :2:6 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 30 14:26:02 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Nov 2013 14:26:02 -0000 Subject: [GHC] #8574: Failure to require FlexibleContexts In-Reply-To: <048.e75c50ddb32d42d63f97cf8a5630ba59@haskell.org> References: <048.e75c50ddb32d42d63f97cf8a5630ba59@haskell.org> Message-ID: <063.88c5dfd858834bee4e378fdbacd00a28@haskell.org> #8574: Failure to require FlexibleContexts ------------------------------------------------+-------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts invalid program | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by Feuerbach): Ah, you're absolutely right. I should've read the report first! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 30 15:24:42 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Nov 2013 15:24:42 -0000 Subject: [GHC] #8301: error BaseReg must be in a register for THREADED_RTS In-Reply-To: <044.0651fb01dd71f2601e90f46aa455c558@haskell.org> References: <044.0651fb01dd71f2601e90f46aa455c558@haskell.org> Message-ID: <059.9dc32144e9161375aaf51b1c02e528ae@haskell.org> #8301: error BaseReg must be in a register for THREADED_RTS ----------------------------------------+----------------------------- Reporter: erikd | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+----------------------------- Changes (by trommler): * cc: ptrommler@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 30 15:51:16 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Nov 2013 15:51:16 -0000 Subject: [GHC] #8574: Failure to require FlexibleContexts In-Reply-To: <048.e75c50ddb32d42d63f97cf8a5630ba59@haskell.org> References: <048.e75c50ddb32d42d63f97cf8a5630ba59@haskell.org> Message-ID: <063.b4202e2b532a703582ac0de2f62e34f1@haskell.org> #8574: Failure to require FlexibleContexts ------------------------------------------------+-------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts invalid program | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"4bbffb49ebddaa803f2c82c837a68553042f0793/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="4bbffb49ebddaa803f2c82c837a68553042f0793" Fix documentation of FlexibleContexts (#8574) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 30 15:52:08 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Nov 2013 15:52:08 -0000 Subject: [GHC] #8574: Failure to require FlexibleContexts In-Reply-To: <048.e75c50ddb32d42d63f97cf8a5630ba59@haskell.org> References: <048.e75c50ddb32d42d63f97cf8a5630ba59@haskell.org> Message-ID: <063.b8041f0838c665d2017a572f1ec5d7e8@haskell.org> #8574: Failure to require FlexibleContexts ------------------------------------------------+-------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Parser) | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts invalid program | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by monoidal): * status: new => closed * resolution: => fixed Comment: Documentation fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 30 18:18:00 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Nov 2013 18:18:00 -0000 Subject: [GHC] #8318: GHC does not infer type of `tagToEnum#` expression In-Reply-To: <048.ec88b096ee125380632b6d2dee0264c0@haskell.org> References: <048.ec88b096ee125380632b6d2dee0264c0@haskell.org> Message-ID: <063.9b2ed3a902d59349fc736199e84b588d@haskell.org> #8318: GHC does not infer type of `tagToEnum#` expression ----------------------------------------------+---------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Changes (by parcs): * cc: patrick@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 30 19:00:50 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Nov 2013 19:00:50 -0000 Subject: [GHC] #8562: Builtin function __builtin___clear_cache is unavailable on GCC 4.2 In-Reply-To: <047.84726fd9ab3632509c55e16aa3ebee4d@haskell.org> References: <047.84726fd9ab3632509c55e16aa3ebee4d@haskell.org> Message-ID: <062.44e0d4ee2db27986c4b9f401db052d90@haskell.org> #8562: Builtin function __builtin___clear_cache is unavailable on GCC 4.2 --------------------------------------------+------------------------------ Reporter: heatsink | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: GHC doesn't work at all | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8561 --------------------------------------------+------------------------------ Changes (by heatsink): * owner: simonmar => * status: closed => new * resolution: fixed => Comment: The fix only applies to linux (it's guarded by an `#if defined(linux_HOST_OS)`). On darwin, it still doesn't work. I'm attaching a patch to apply the fix to all OSes. It works for me, but I can't run the validation script because of #8266. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 30 19:14:41 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Nov 2013 19:14:41 -0000 Subject: [GHC] #8580: Integer size mismatch errors Message-ID: <047.d4333db31befff4b75ede8d807b689c8@haskell.org> #8580: Integer size mismatch errors -------------------------------------+------------------------------------- Reporter: heatsink | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: MacOS X Architecture: x86 | Type of failure: Building GHC Difficulty: Easy (less than 1 | failed hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- There is an integer size mismatch in `rts/Stats.c` that causes validation to fail when `size_t /= W_`. This patch adds casts to fix the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 30 20:42:53 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Nov 2013 20:42:53 -0000 Subject: [GHC] #8578: Improvements to SpinLock implementation In-Reply-To: <044.7d4d696b896537d8c685483f715ea999@haskell.org> References: <044.7d4d696b896537d8c685483f715ea999@haskell.org> Message-ID: <059.e1be88c137f4bbd8af9d13628af0c5c2@haskell.org> #8578: Improvements to SpinLock implementation -------------------------------------+------------------------------------ Reporter: parcs | Owner: parcs Type: task | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by thoughtpolice): Very good stuff Patrick looks nice to me - and I can see how it'd help scalability. I did a quick glance and one question I have is why are we using `busy_wait_nop` in the wait loop, which just becomes `rep; nop` on x86? For spinlock implementations, Intel at least has a `PAUSE` instruction which specifically informs the CPU that this is a spinlock wait-loop, which allows it to optimize cache and memory accesses if possible to avoid memory ordering violations, requiring the CPUs to synchronize. This can be quite dramatic on older processors I believe (I wouldn't be surprised if `rep; nop` devolved in `pause` on some microarchs, but probably not fully guaranteed.) `PAUSE` might also actually *delay* the CPU for this optimization to happen, where as `rep nop` will merely run as fast as possible. So I'd suggest replacing `busy_wait_nop` on x86 with something like `_pause_mm` from GCC: {{{ #define _mm_pause() \ ({ \ __asm__ __volatile__("pause" ::: "memory"); \ }) }}} Finally, one thing I did for fun a while back was write an accelerated spinlock implementation using the new TSX extensions in Intel processors. In my very non-scientific experiments, this essentially eliminated any lock contention (or even any need to take a lock) in a lot of cases. I wonder if it's worth adding here to see if there's any difference in throughput or contention. You can find the code here (pinpointed to the code in question): https://gist.github.com/thoughtpolice/7123036#file-spinlock-rtm-c-L230 Note my example does *not* use lock elision prefixes for `xchg` (which are backwards compatible,) but instead uses the new TSX RTM instructions to wrap locks/unlocks in a transaction, allowing speculative elision. In practice this works just as well and RTM is more flexible. It would however require checking `cpuid` to see if TSX is available and if so, dynamically replacing the code path as I have done. On Haswell, this indirect-branch would probably be predicted so well its overhead is basically zero, but I don't know what it might do to e.g. AMD machines in terms of prediction or throughput. In any case - Patrick, thanks. If you'd like to test the elision thing, or the impact of `_mm_pause`, I have a powerful Haswell server available (8 hardware threads/32GB RAM) you can play around with for testing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 30 21:04:25 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Nov 2013 21:04:25 -0000 Subject: [GHC] #8578: Improvements to SpinLock implementation In-Reply-To: <044.7d4d696b896537d8c685483f715ea999@haskell.org> References: <044.7d4d696b896537d8c685483f715ea999@haskell.org> Message-ID: <059.37a17b1a8de37bcff91cb23df4d1d763@haskell.org> #8578: Improvements to SpinLock implementation -------------------------------------+------------------------------------ Reporter: parcs | Owner: parcs Type: task | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonmar): "rep; nop" ''is'' the pause instruction :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 30 21:15:08 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Nov 2013 21:15:08 -0000 Subject: [GHC] #8578: Improvements to SpinLock implementation In-Reply-To: <044.7d4d696b896537d8c685483f715ea999@haskell.org> References: <044.7d4d696b896537d8c685483f715ea999@haskell.org> Message-ID: <059.d5a36bee67296434686407dc07da7ee2@haskell.org> #8578: Improvements to SpinLock implementation -------------------------------------+------------------------------------ Reporter: parcs | Owner: parcs Type: task | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by thoughtpolice): Ah, yes, you're right - I did some more digging. The tricky bit is that `rep; nop` and `pause` actually have the same opcodes (`F390`) for backwards compatibility, but on newer CPUs, `rep; nop` is treated magically (allowing other hyperthreads on the same core), and `pause` is simply an alias to make it more clear. In that case, ignore me and my inability to keep up with Intel shenanigans. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 30 23:03:30 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Nov 2013 23:03:30 -0000 Subject: [GHC] #2233: Overhaul System.Process In-Reply-To: <047.24a366415ff9b59c03e5bf49850898a6@haskell.org> References: <047.24a366415ff9b59c03e5bf49850898a6@haskell.org> Message-ID: <062.5749441687f9842356c8b5e40d1daf6a@haskell.org> #2233: Overhaul System.Process --------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: task | Status: patch Priority: normal | Milestone: _|_ Component: libraries/process | Version: 6.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by Herbert Valerio Riedel ): In [changeset:"b601209456e13ca3d08faffb7e6771bcb8c1b1b4/process"]: {{{ #!CommitTicketReference repository="process" revision="b601209456e13ca3d08faffb7e6771bcb8c1b1b4" All new sync process functions now terminate on an exception (#2233) Now all the functions that call a process synchronously have the same behaviour. Previously just readProcess, readProcessWithExitCode did this, now callProcess and callCommand do too. If a thread running one of these functions gets an exception, including async exceptions (such as from timeout or killThread), then the external process gets terminated. Introduce a helper function to implement this behaviour. Currently it is not exposed to users, but that could be changed easily. Authored-by: Duncan Coutts Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 30 23:03:30 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Nov 2013 23:03:30 -0000 Subject: [GHC] #2233: Overhaul System.Process In-Reply-To: <047.24a366415ff9b59c03e5bf49850898a6@haskell.org> References: <047.24a366415ff9b59c03e5bf49850898a6@haskell.org> Message-ID: <062.7d9c147d31fb542fc6ae8486bc25211d@haskell.org> #2233: Overhaul System.Process --------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: task | Status: patch Priority: normal | Milestone: _|_ Component: libraries/process | Version: 6.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by Herbert Valerio Riedel ): In [changeset:"79ae975aab5866de38e1a01aca7ac5bd9cde2285/process"]: {{{ #!CommitTicketReference repository="process" revision="79ae975aab5866de38e1a01aca7ac5bd9cde2285" Improve the code for ignoring EPIPE (#2233) Factor it out into an ignoreSigPipe util, and use it in both readProcess and readProcessWithExitCode. Authored-by: Duncan Coutts Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 30 23:03:31 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Nov 2013 23:03:31 -0000 Subject: [GHC] #2233: Overhaul System.Process In-Reply-To: <047.24a366415ff9b59c03e5bf49850898a6@haskell.org> References: <047.24a366415ff9b59c03e5bf49850898a6@haskell.org> Message-ID: <062.5866d8404a0a8a5881330d37a6d3f93a@haskell.org> #2233: Overhaul System.Process --------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: task | Status: patch Priority: normal | Milestone: _|_ Component: libraries/process | Version: 6.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by Herbert Valerio Riedel ): In [changeset:"d95a67012ea30b02144d193254d947cdf5400a9d/process"]: {{{ #!CommitTicketReference repository="process" revision="d95a67012ea30b02144d193254d947cdf5400a9d" Be even more careful with the threads that consume output (#2233) There is a potential deadlock with withCreateProcess in the case that there's an exception: cleanupProcess will try to hClose the various handles, but if another thread holds the Handle lock then that hClose will block. Takano Akio fixed the main case of this (in patch 32223a9ab174c22e939c81e24b6f48223c7cb020) by terminating the process (before closing the handles) This works because terminating the process will eventually cause those other threads to finish and release the Handle lock, so we can hClose. However on Unix terminateProcess is not guaranteed to terminate the process since it uses SIGTERM, which can be handled or ignored. So we have to separately guarantee that the handles can be hClosed, and the simplest way to do this is to ensure that the thread reading from the handles get killed in the case there's an exception. So we change forkWait to withForkWait that will kill off the thread if the body gets an exception. Authored-by: Duncan Coutts Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 30 23:03:31 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Nov 2013 23:03:31 -0000 Subject: [GHC] #2233: Overhaul System.Process In-Reply-To: <047.24a366415ff9b59c03e5bf49850898a6@haskell.org> References: <047.24a366415ff9b59c03e5bf49850898a6@haskell.org> Message-ID: <062.effd89fc3b12a37d934e94f49fa0c256@haskell.org> #2233: Overhaul System.Process --------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: task | Status: patch Priority: normal | Milestone: _|_ Component: libraries/process | Version: 6.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by Herbert Valerio Riedel ): In [changeset:"228297ec53e9ee7a1a6a3c5964ca7e89a6474c9b/process"]: {{{ #!CommitTicketReference repository="process" revision="228297ec53e9ee7a1a6a3c5964ca7e89a6474c9b" Drop redundant hFlush & add ignoreSigPipe to hClose This is a follow-up to 79ae975aab5866de38e1a01aca7ac5bd9cde2285 (addressing #2233) Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler