From ghc-devs at haskell.org Mon Dec 1 00:56:54 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Dec 2014 00:56:54 -0000 Subject: [GHC] #9849: GHC readme.md seems out of date Message-ID: <045.1648ba45c23de1341394f39c1acb1358@haskell.org> #9849: GHC readme.md seems out of date -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- https://github.com/ghc/ghc/blob/89f5f314e32c3e80c71f4b3dcc8835ae74d7d57f/README.md still mentions using sync-all script, but the wiki docs say its deprecated https://ghc.haskell.org/trac/ghc/wiki/Building/SyncAll -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 1 01:39:25 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Dec 2014 01:39:25 -0000 Subject: [GHC] #7608: LLVM only handles a hard-coded list of triples. In-Reply-To: <049.5e6798700ded89ff697ada495d9b6a1a@haskell.org> References: <049.5e6798700ded89ff697ada495d9b6a1a@haskell.org> Message-ID: <064.f4a01486bb7c0f8e0e5a77e95fbbfbbf@haskell.org> #7608: LLVM only handles a hard-coded list of triples. -------------------------------------+------------------------------------- Reporter: singpolyma | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.7 (LLVM) | Keywords: cross-compiling Resolution: | llvm Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: 7610 | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dterei): * owner: dterei => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 1 01:39:53 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Dec 2014 01:39:53 -0000 Subject: [GHC] #7610: Cross compilation support for LLVM backend In-Reply-To: <045.61f5f6b56d89e51923b19f01667c88c3@haskell.org> References: <045.61f5f6b56d89e51923b19f01667c88c3@haskell.org> Message-ID: <060.5ba587cadfe22f0e9e14912b00ba59b5@haskell.org> #7610: Cross compilation support for LLVM backend -------------------------------------+------------------------------------- Reporter: dterei | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.1 (LLVM) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: 7608, 7621, 7639 Type of failure: GHC | Related Tickets: doesn't work at all | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dterei): * owner: dterei => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 1 02:02:12 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Dec 2014 02:02:12 -0000 Subject: [GHC] #8439: add a CPP program field to Settings file (decouple CPP program and C compiler choice) In-Reply-To: <045.b102c8aef525c2e2e4e30540ff75513b@haskell.org> References: <045.b102c8aef525c2e2e4e30540ff75513b@haskell.org> Message-ID: <060.6ff30848249b6e770c79cc916cd26ba6@haskell.org> #8439: add a CPP program field to Settings file (decouple CPP program and C compiler choice) -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: feature | Status: closed request | Milestone: Priority: normal | Version: 7.7 Component: Build | Keywords: System | Architecture: Unknown/Multiple Resolution: duplicate | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #8683 Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * component: Compiler => Build System * milestone: 7.10.1 => Comment: Duplicate of #8683. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 1 03:52:05 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Dec 2014 03:52:05 -0000 Subject: [GHC] #9828: genprimopcode: parse error In-Reply-To: <044.4f61a9262a17977cdef988ddc024706a@haskell.org> References: <044.4f61a9262a17977cdef988ddc024706a@haskell.org> Message-ID: <059.51fd757821b300fdbdbf59c9080512aa@haskell.org> #9828: genprimopcode: parse error ----------------------------------------------+--------------------------- Reporter: erikd | Owner: thomie Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------------+--------------------------- Changes (by thomie): * owner: => thomie Comment: The cause of this bug is my patch for #9094. To install gcc-4.9 on Ubuntu 14.04: {{{ $ sudo add-apt-repository ppa:ubuntu-toolchain-r/test $ sudo apt-get update $ sudo apt-get install gcc-4.9 $ gcc-4.9 --version gcc-4.9 (Ubuntu 4.9.2-0ubuntu1~14.04) 4.9.2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 1 03:52:41 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Dec 2014 03:52:41 -0000 Subject: [GHC] #9094: remove RAW_CPP In-Reply-To: <045.99520725c7120b8fcb5e4c616ee15b05@haskell.org> References: <045.99520725c7120b8fcb5e4c616ee15b05@haskell.org> Message-ID: <060.87c44db21782a6094416e918238ffbc0@haskell.org> #9094: remove RAW_CPP -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: 8683 None/Unknown | Related Tickets: #8683 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: closed => new * resolution: fixed => Comment: Please revert that commit, it is the cause of #9828. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 1 04:41:28 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Dec 2014 04:41:28 -0000 Subject: [GHC] #9850: Template Haskell does not seem to support StandaloneDeriving Message-ID: <046.b737704c50810cf96099c7c92ddd4283@haskell.org> #9850: Template Haskell does not seem to support StandaloneDeriving -------------------------------------+------------------------------------- Reporter: vxanica | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.3 Keywords: | Operating System: StandaloneDeriving | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Easy (less than 1 | None/Unknown hour) | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- I want to write some TH to deriving Show instance recursively on composite data types, however, I think I have to use StandaloneDeriving which TH does not support this. At least, I did not see in Dec type. support in 7.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 1 04:42:45 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Dec 2014 04:42:45 -0000 Subject: [GHC] #9850: Template Haskell does not seem to support StandaloneDeriving In-Reply-To: <046.b737704c50810cf96099c7c92ddd4283@haskell.org> References: <046.b737704c50810cf96099c7c92ddd4283@haskell.org> Message-ID: <061.7321d81eb3052883891f9070ecf74d3d@haskell.org> #9850: Template Haskell does not seem to support StandaloneDeriving -------------------------------------+------------------------------------- Reporter: vxanica | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Template | Keywords: Haskell | StandaloneDeriving Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Description changed by vxanica: Old description: > I want to write some TH to deriving Show instance recursively on > composite data types, however, I think I have to use StandaloneDeriving > which TH does not support this. At least, I did not see in Dec type. > support in 7.8.3 New description: I want to write some TH to deriving Show instance recursively on composite data types, however, I think I have to use StandaloneDeriving which TH does not support this. At least, I did not see it in Dec type in GHC 7.8.3 -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 1 06:02:57 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Dec 2014 06:02:57 -0000 Subject: [GHC] #9850: Template Haskell does not seem to support StandaloneDeriving In-Reply-To: <046.b737704c50810cf96099c7c92ddd4283@haskell.org> References: <046.b737704c50810cf96099c7c92ddd4283@haskell.org> Message-ID: <061.2664577e1da81ba3fc66215a59337b30@haskell.org> #9850: Template Haskell does not seem to support StandaloneDeriving -------------------------------------+------------------------------------- Reporter: vxanica | Owner: Type: feature | Status: closed request | Milestone: Priority: normal | Version: 7.8.3 Component: Template | Keywords: Haskell | StandaloneDeriving Resolution: duplicate | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: #8100 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by jstolarek): * status: new => closed * resolution: => duplicate * related: => #8100 Comment: I believe this is already fixed in HEAD. See #8100. Closing as duplicate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 1 07:40:31 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Dec 2014 07:40:31 -0000 Subject: [GHC] #9828: genprimopcode: parse error In-Reply-To: <044.4f61a9262a17977cdef988ddc024706a@haskell.org> References: <044.4f61a9262a17977cdef988ddc024706a@haskell.org> Message-ID: <059.c2dfa9c16ece9a0a07a69122f39fc2eb@haskell.org> #9828: genprimopcode: parse error ----------------------------------------------+--------------------------- Reporter: erikd | Owner: thomie Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------------+--------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"0511c0ab09f705c3012b405781c9398a143b0e38/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="0511c0ab09f705c3012b405781c9398a143b0e38" Revert "Remove RAWCPP_FLAGS" This reverts commit 460eebec65811c6a7bbe11645df322dda868e80d. Thomas requested to revert the commit with the words: > Please revert this commit, it is horribly wrong. I'll have a proper look > later, but not supplying `-traditional` to the C preprocessor is the cause > of #9828. the reverted commit was related to #9094 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 1 07:40:31 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Dec 2014 07:40:31 -0000 Subject: [GHC] #9094: remove RAW_CPP In-Reply-To: <045.99520725c7120b8fcb5e4c616ee15b05@haskell.org> References: <045.99520725c7120b8fcb5e4c616ee15b05@haskell.org> Message-ID: <060.a4b442fd85c407387432d10d17e3026d@haskell.org> #9094: remove RAW_CPP -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: 8683 None/Unknown | Related Tickets: #8683 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"0511c0ab09f705c3012b405781c9398a143b0e38/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="0511c0ab09f705c3012b405781c9398a143b0e38" Revert "Remove RAWCPP_FLAGS" This reverts commit 460eebec65811c6a7bbe11645df322dda868e80d. Thomas requested to revert the commit with the words: > Please revert this commit, it is horribly wrong. I'll have a proper look > later, but not supplying `-traditional` to the C preprocessor is the cause > of #9828. the reverted commit was related to #9094 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 1 09:15:01 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Dec 2014 09:15:01 -0000 Subject: [GHC] #9828: genprimopcode: parse error In-Reply-To: <044.4f61a9262a17977cdef988ddc024706a@haskell.org> References: <044.4f61a9262a17977cdef988ddc024706a@haskell.org> Message-ID: <059.e7ff5c16980b58829cdfad676f981be1@haskell.org> #9828: genprimopcode: parse error ----------------------------------------------+--------------------------- Reporter: erikd | Owner: thomie Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------------+--------------------------- Comment (by erikd): I can confirm that this fixes it for me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 1 11:50:51 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Dec 2014 11:50:51 -0000 Subject: [GHC] #8100: Standalone deriving using template haskell In-Reply-To: <044.0add0211f14c3e1d8f3c2c4a3d5c37d4@haskell.org> References: <044.0add0211f14c3e1d8f3c2c4a3d5c37d4@haskell.org> Message-ID: <059.199075c043b2f4224359beb352ba734f@haskell.org> #8100: Standalone deriving using template haskell -------------------------------------+------------------------------------- Reporter: acube | Owner: goldfire Type: feature | Status: closed request | Milestone: Priority: normal | Version: Component: Template | Keywords: Haskell | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: th/T8100 | Blocking: | Differential Revisions: Phab:D439 | -------------------------------------+------------------------------------- Comment (by vxanica): Will it be merged into next release? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 1 12:59:24 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Dec 2014 12:59:24 -0000 Subject: [GHC] #9005: Ship default bash completion file with ghc In-Reply-To: <044.36e9f7350e06cce5a30d1a2bcf83acd9@haskell.org> References: <044.36e9f7350e06cce5a30d1a2bcf83acd9@haskell.org> Message-ID: <059.dcd617aa31de81c4b9a386e4f5afa8cf@haskell.org> #9005: Ship default bash completion file with ghc -------------------------------------+------------------------------------- Reporter: td123 | Owner: kolmodin Type: feature | Status: closed request | Milestone: Priority: lowest | Version: 7.8.2 Component: None | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D536 | -------------------------------------+------------------------------------- Changes (by kolmodin): * status: new => closed * resolution: => fixed Comment: Bash completion file and README has been added to the repo. The file is to be installed by the distro packagers, so no additional work will be done during the installation phase. Closing as fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 1 13:02:37 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Dec 2014 13:02:37 -0000 Subject: [GHC] #9828: genprimopcode: parse error In-Reply-To: <044.4f61a9262a17977cdef988ddc024706a@haskell.org> References: <044.4f61a9262a17977cdef988ddc024706a@haskell.org> Message-ID: <059.4472ccec992c168cf2915db63f783431@haskell.org> #9828: genprimopcode: parse error ----------------------------------------------+--------------------------- Reporter: erikd | Owner: thomie Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Build System | Version: 7.9 Resolution: fixed | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------------+--------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed * component: Compiler => Build System * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 1 13:22:47 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Dec 2014 13:22:47 -0000 Subject: [GHC] #9005: Ship default bash completion file with ghc In-Reply-To: <044.36e9f7350e06cce5a30d1a2bcf83acd9@haskell.org> References: <044.36e9f7350e06cce5a30d1a2bcf83acd9@haskell.org> Message-ID: <059.87ff8d6d7b2477ea7336f88bb947eb5c@haskell.org> #9005: Ship default bash completion file with ghc -------------------------------------+------------------------------------- Reporter: td123 | Owner: kolmodin Type: feature | Status: closed request | Milestone: Priority: lowest | Version: 7.8.2 Component: None | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D536 | -------------------------------------+------------------------------------- Comment (by jstolarek): Shouldn't we keep this one open until User's Guide gets updated? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 1 14:16:09 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Dec 2014 14:16:09 -0000 Subject: [GHC] #8100: Standalone deriving using template haskell In-Reply-To: <044.0add0211f14c3e1d8f3c2c4a3d5c37d4@haskell.org> References: <044.0add0211f14c3e1d8f3c2c4a3d5c37d4@haskell.org> Message-ID: <059.cb26692c40633ee499efcdcc581e6ad3@haskell.org> #8100: Standalone deriving using template haskell -------------------------------------+------------------------------------- Reporter: acube | Owner: goldfire Type: feature | Status: closed request | Milestone: Priority: normal | Version: Component: Template | Keywords: Haskell | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: th/T8100 | Blocking: | Differential Revisions: Phab:D439 | -------------------------------------+------------------------------------- Comment (by simonpj): Replying to [comment:13 vxanica]: > Will it be merged into next release? For 7.10, yes certainly. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 1 14:19:19 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Dec 2014 14:19:19 -0000 Subject: [GHC] #9833: GHCi suggestion for instance signature (InstanceSigs) is wrong In-Reply-To: <051.4f374768f35d40920f184256a5b1e2ba@haskell.org> References: <051.4f374768f35d40920f184256a5b1e2ba@haskell.org> Message-ID: <066.3a9fa95437394750b144c738f972edeb@haskell.org> #9833: GHCi suggestion for instance signature (InstanceSigs) is wrong -------------------------------------+------------------------------------- Reporter: | Owner: Iceland_jack | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.2 Component: GHCi | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"e6a2050ebb6da316aecec66a6795715fbab355ca/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="e6a2050ebb6da316aecec66a6795715fbab355ca" Fix the handling of instance signatures (Trac #9582, #9833) This finally solves the issue of instance-method signatures that are more polymorphic than the instanted class method. See Note [Instance method signatures] in TcInstDcls. A very nice fix for the two Trac tickets above. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 1 14:19:19 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Dec 2014 14:19:19 -0000 Subject: [GHC] #9582: Associated Type Synonyms do not unfold in InstanceSigs In-Reply-To: <051.1c38a1e6c743f17158ef37805e71fa91@haskell.org> References: <051.1c38a1e6c743f17158ef37805e71fa91@haskell.org> Message-ID: <066.72f2a7c7831f303edc7d7e5d637c1fc7@haskell.org> #9582: Associated Type Synonyms do not unfold in InstanceSigs -------------------------------------+------------------------------------- Reporter: | Owner: andreas.abel | Status: infoneeded Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: InstanceSigs (Type checker) | TypeFamilies Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"e6a2050ebb6da316aecec66a6795715fbab355ca/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="e6a2050ebb6da316aecec66a6795715fbab355ca" Fix the handling of instance signatures (Trac #9582, #9833) This finally solves the issue of instance-method signatures that are more polymorphic than the instanted class method. See Note [Instance method signatures] in TcInstDcls. A very nice fix for the two Trac tickets above. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 1 14:23:37 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Dec 2014 14:23:37 -0000 Subject: [GHC] #9833: GHCi suggestion for instance signature (InstanceSigs) is wrong In-Reply-To: <051.4f374768f35d40920f184256a5b1e2ba@haskell.org> References: <051.4f374768f35d40920f184256a5b1e2ba@haskell.org> Message-ID: <066.8d4916ae53cafab7abf6979a9dbde87f@haskell.org> #9833: GHCi suggestion for instance signature (InstanceSigs) is wrong -------------------------------------+------------------------------------- Reporter: | Owner: Iceland_jack | Status: closed Type: bug | Milestone: Priority: normal | Version: 7.8.2 Component: GHCi | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: | polykinds/T9833 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => polykinds/T9833 * resolution: => fixed Comment: Thanks for pointing this out. The original issue was that the `empty` method was ''more'' polymorphic than required. That is now legal. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 1 14:25:13 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Dec 2014 14:25:13 -0000 Subject: [GHC] #9582: Associated Type Synonyms do not unfold in InstanceSigs In-Reply-To: <051.1c38a1e6c743f17158ef37805e71fa91@haskell.org> References: <051.1c38a1e6c743f17158ef37805e71fa91@haskell.org> Message-ID: <066.f81ea38bdfeaeff2a46274a9207910a1@haskell.org> #9582: Associated Type Synonyms do not unfold in InstanceSigs -------------------------------------+------------------------------------- Reporter: | Owner: andreas.abel | Status: closed Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: InstanceSigs (Type checker) | TypeFamilies Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: indexed- | types/should_compile/T9582 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: infoneeded => closed * testcase: => indexed-types/should_compile/T9582 * resolution: => fixed Comment: I finally fixed this in a slightly different, more general way. Thank you for working on it; doing so clarified my thinking a lot. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 1 15:35:13 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Dec 2014 15:35:13 -0000 Subject: [GHC] #8721: Testsuite not reporting errors for DYN way on OS X In-Reply-To: <046.8af9e017e06f897fefadc3e624641754@haskell.org> References: <046.8af9e017e06f897fefadc3e624641754@haskell.org> Message-ID: <061.3b342a452fceb549f44b2152795dd7d0@haskell.org> #8721: Testsuite not reporting errors for DYN way on OS X -------------------------------------+------------------------------------ Reporter: darchon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.6.3 Resolution: | Keywords: dynamic linking Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------ Comment (by darchon): No, it does not mean that we can refrain from setting `DYLD_LIBRARY_PATH`. in f7be53ac9dac85b83e7fe5ecede01b98a572ba48, the rpaths are made relative to the final install location. During testing, the libraries are still in their build locations, so we still need `DYLD_LIBRARY_PATH` to find the libraries. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 1 15:42:29 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Dec 2014 15:42:29 -0000 Subject: [GHC] #618: Dependency caching in ghc --make In-Reply-To: <047.cb339f4df789645f0d246a4cb70e5f2e@haskell.org> References: <047.cb339f4df789645f0d246a4cb70e5f2e@haskell.org> Message-ID: <062.ef9292a95ee25a361317edb8caf6e442@haskell.org> #618: Dependency caching in ghc --make -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: None Resolution: None | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Moderate (less Type of failure: | than a day) None/Unknown | Blocked By: Test Case: N/A | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by rodlogic): * cc: rodlogic (added) * failure: => None/Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 1 15:43:45 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Dec 2014 15:43:45 -0000 Subject: [GHC] #8935: Obscure linker bug leads to crash in GHCi In-Reply-To: <047.8232648153a9aef6fa07ec75b847f7cb@haskell.org> References: <047.8232648153a9aef6fa07ec75b847f7cb@haskell.org> Message-ID: <062.9f32551dd82abe2653c2a0fb4d8e8d53@haskell.org> #8935: Obscure linker bug leads to crash in GHCi -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.10.1 Component: Runtime | Version: 7.8.1-rc2 System | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Rocket Science Unknown/Multiple | Blocked By: Type of failure: GHCi crash | Related Tickets: #9186, #9480 Test Case: | Blocking: | Differential Revisions: Phab:D349 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: OK, marking as fixed (crosses fingers). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 1 15:44:03 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Dec 2014 15:44:03 -0000 Subject: [GHC] #9186: GHC panic when compiling compdata In-Reply-To: <047.bd93976605e2ee52c8ffb09a3a838441@haskell.org> References: <047.bd93976605e2ee52c8ffb09a3a838441@haskell.org> Message-ID: <062.85bfc01501df56a686e55c084a12a047@haskell.org> #9186: GHC panic when compiling compdata -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8935 Test Case: | Blocking: | Differential Revisions: Phab:D349 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: OK, marking as fixed (crosses fingers). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 1 15:44:29 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Dec 2014 15:44:29 -0000 Subject: [GHC] #9480: Segfault in GHC API code using Shelly In-Reply-To: <049.0677aa1db4b4385b2175404d6ded322c@haskell.org> References: <049.0677aa1db4b4385b2175404d6ded322c@haskell.org> Message-ID: <064.d1b3949ba681436864721bc3a32b4278@haskell.org> #9480: Segfault in GHC API code using Shelly -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: GHC API | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Unknown crash | Blocked By: Test Case: | Related Tickets: #8935 Blocking: | Differential Revisions: Phab:D349 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: OK, marking as fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 1 16:17:23 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Dec 2014 16:17:23 -0000 Subject: [GHC] #9169: Add mkWeakTMVar to Control.Concurrent.STM.TMVar In-Reply-To: <049.23b37a7a3374245a7e82fd5db3c1a49c@haskell.org> References: <049.23b37a7a3374245a7e82fd5db3c1a49c@haskell.org> Message-ID: <064.301599a2dc6f8f2d8d13aaa501aaf4dc@haskell.org> #9169: Add mkWeakTMVar to Control.Concurrent.STM.TMVar -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: thoughtpolice Type: feature | Status: upstream request | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Core | Keywords: stm Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonmar): * cc: core-libraries-committee@? (added) * owner: => thoughtpolice Comment: Patch looks fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 1 17:07:14 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Dec 2014 17:07:14 -0000 Subject: [GHC] #9833: GHCi suggestion for instance signature (InstanceSigs) is wrong In-Reply-To: <051.4f374768f35d40920f184256a5b1e2ba@haskell.org> References: <051.4f374768f35d40920f184256a5b1e2ba@haskell.org> Message-ID: <066.7c33360c3c2ebe7358141af196700c9f@haskell.org> #9833: GHCi suggestion for instance signature (InstanceSigs) is wrong -------------------------------------+------------------------------------- Reporter: | Owner: Iceland_jack | Status: closed Type: bug | Milestone: Priority: normal | Version: 7.8.2 Component: GHCi | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: | polykinds/T9833 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"c34ef467429771edf0b2b18c05994c461c82df38/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c34ef467429771edf0b2b18c05994c461c82df38" Test Trac #7908 Fixed by e6a2050ebb6da316aecec66a6795715fbab355ca along with #9582, #9833 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 1 17:07:14 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Dec 2014 17:07:14 -0000 Subject: [GHC] #7908: InstanceSigs suggestion not accepted In-Reply-To: <048.16e7666fc7d089cc84c391ee087463e7@haskell.org> References: <048.16e7666fc7d089cc84c391ee087463e7@haskell.org> Message-ID: <063.64a2c5362f2f9c9760c7de1eab9c73dd@haskell.org> #7908: InstanceSigs suggestion not accepted -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"c34ef467429771edf0b2b18c05994c461c82df38/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c34ef467429771edf0b2b18c05994c461c82df38" Test Trac #7908 Fixed by e6a2050ebb6da316aecec66a6795715fbab355ca along with #9582, #9833 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 1 17:07:14 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Dec 2014 17:07:14 -0000 Subject: [GHC] #9582: Associated Type Synonyms do not unfold in InstanceSigs In-Reply-To: <051.1c38a1e6c743f17158ef37805e71fa91@haskell.org> References: <051.1c38a1e6c743f17158ef37805e71fa91@haskell.org> Message-ID: <066.d9e6883ed068b191bd07a974ac7463e4@haskell.org> #9582: Associated Type Synonyms do not unfold in InstanceSigs -------------------------------------+------------------------------------- Reporter: | Owner: andreas.abel | Status: closed Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: InstanceSigs (Type checker) | TypeFamilies Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: indexed- | types/should_compile/T9582 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"c34ef467429771edf0b2b18c05994c461c82df38/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c34ef467429771edf0b2b18c05994c461c82df38" Test Trac #7908 Fixed by e6a2050ebb6da316aecec66a6795715fbab355ca along with #9582, #9833 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 1 17:40:48 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Dec 2014 17:40:48 -0000 Subject: [GHC] #4347: Bug in unification of polymorphic and not-yet-polymorphic type In-Reply-To: <044.ff04e8084e7aca9611c332ca30665a4b@haskell.org> References: <044.ff04e8084e7aca9611c332ca30665a4b@haskell.org> Message-ID: <059.1318a72e9f8a7d9c0be7b048ec8ff55b@haskell.org> #4347: Bug in unification of polymorphic and not-yet-polymorphic type -------------------------------------+------------------------------------- Reporter: dolio | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.1 (Type checker) | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: Linux | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dolio): To be honest, I'd be fine with closing this ticket. I filed it right around the 6 -> 7 cutover, and evidently thought that the new type checker was still supposed to handle impredicative instantiation. But, the truth is, I think, that if the new algorithm does handle certain impredicative cases, it's more a happy accident than a design principle. So my const example happened to work, but id didn't at the time. I interpreted that as a bug with id rather than being happy that it worked at all for const. I'll leave it to the implementors to decide. If the id example works in 7.10, that's handy. But I've long since stopped considering 'regressions' in impredicative instantiation relative to 6.x actual regressions. It's merely the result a different set of tradeoffs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 1 17:45:33 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Dec 2014 17:45:33 -0000 Subject: [GHC] #5467: Template Haskell: support for Haddock comments In-Reply-To: <046.e4a8d15ae2317226a67b074817a4dd39@haskell.org> References: <046.e4a8d15ae2317226a67b074817a4dd39@haskell.org> Message-ID: <061.202d1e52397aae86b2a387eff0cd528b@haskell.org> #5467: Template Haskell: support for Haddock comments -------------------------------------+------------------------------------- Reporter: reinerp | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.2.1 Component: Template | Keywords: Haskell | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: bgamari@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 1 18:12:30 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Dec 2014 18:12:30 -0000 Subject: [GHC] #9497: Silent typed holes In-Reply-To: <045.44f02f56e1d82f152039c59defbcbbe5@haskell.org> References: <045.44f02f56e1d82f152039c59defbcbbe5@haskell.org> Message-ID: <060.bb4071809e3d09c53a4bef5f724048a6@haskell.org> #9497: Silent typed holes -------------------------------------+------------------------------------- Reporter: merijn | Owner: merijn Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: typed holes, Resolution: fixed | warnings Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D442 | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 1 18:36:43 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Dec 2014 18:36:43 -0000 Subject: [GHC] #4096: New primops for indexing: index*OffAddrUsing# etc In-Reply-To: <046.cbdc362b288c9555bd5a78c4f61ebf34@haskell.org> References: <046.cbdc362b288c9555bd5a78c4f61ebf34@haskell.org> Message-ID: <061.ca17fe62af5da8347c5bfb0acbe2bf39@haskell.org> #4096: New primops for indexing: index*OffAddrUsing# etc -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: low | Version: 6.12.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * difficulty: => Unknown * failure: None/Unknown => Runtime performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 1 20:07:03 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Dec 2014 20:07:03 -0000 Subject: [GHC] #9851: Hoopl library in GHC hides runWithFuel / version number clash Message-ID: <053.a80518c51ae2062a4e162a281daf017f@haskell.org> #9851: Hoopl library in GHC hides runWithFuel / version number clash -------------------------------------+------------------------------------- Reporter: AndreasVoellmy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/hoopl | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Other Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The hoopl library on hackage exposes runWithFuel in Compiler.Hoopl. This function is used in the examples distributed with the library (in the testing directory). The version of hoopl distributed in GHC does not expose runWithFuel. Further, the version number of the GHC packaged hoopl is identical to the version number of the hoopl library on hackage. This is (1) confusing, since the haddock docs on hackage for the version in use on the system by default is not accurate, and (2) annoying, since you cannot get the version on hackage by just running a cabal install. Instead, you have to download the package, update the version number, and then cabal install. The fix seems to involve one or both of the following: (1) Bump the version number of hoopl on hackage. (2) Expose runWithFuel in the version distributed with GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 1 20:12:14 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Dec 2014 20:12:14 -0000 Subject: [GHC] #9845: GHC API evaluating some Cabal code fails with SegFault if executable is compiled statically In-Reply-To: <059.4340a519aad7bd56a35fa652e2b81e6f@haskell.org> References: <059.4340a519aad7bd56a35fa652e2b81e6f@haskell.org> Message-ID: <074.03dcbb2460342c43d5c8c09877f91386@haskell.org> #9845: GHC API evaluating some Cabal code fails with SegFault if executable is compiled statically -------------------------------------+------------------------------------- Reporter: | Owner: JeanPhilippeMoresmau | Status: merge Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: GHC API | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: #9480, #8935, crash | #8376 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by trommler): * status: infoneeded => merge Comment: Any chance the fix for #8935 could still be merged into 7.8.4? A cherry pick would result in a conflict in `Linker.lhs` so you might want to try the patch attached to this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 1 20:12:37 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Dec 2014 20:12:37 -0000 Subject: [GHC] #9845: GHC API evaluating some Cabal code fails with SegFault if executable is compiled statically In-Reply-To: <059.4340a519aad7bd56a35fa652e2b81e6f@haskell.org> References: <059.4340a519aad7bd56a35fa652e2b81e6f@haskell.org> Message-ID: <074.c4f7c56c6d70a60918c1ff3b895d66ee@haskell.org> #9845: GHC API evaluating some Cabal code fails with SegFault if executable is compiled statically -------------------------------------+------------------------------------- Reporter: | Owner: JeanPhilippeMoresmau | Status: merge Type: bug | Milestone: 7.8.4 Priority: normal | Version: 7.8.3 Component: GHC API | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: #9480, #8935, crash | #8376 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by trommler): * milestone: => 7.8.4 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 1 20:44:22 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Dec 2014 20:44:22 -0000 Subject: [GHC] #4052: Two sided sections In-Reply-To: <045.b5813509600c384480a4546fa72e7427@haskell.org> References: <045.b5813509600c384480a4546fa72e7427@haskell.org> Message-ID: <060.5f3af8975f7b63a896330c28345e6464@haskell.org> #4052: Two sided sections -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: low | Version: 6.12.2 Component: Compiler | Keywords: section (Parser) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #8304 Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * difficulty: => Unknown * component: Compiler => Compiler (Parser) * related: => #8304 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 1 20:44:39 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Dec 2014 20:44:39 -0000 Subject: [GHC] #8304: more lenient operator sections (RelaxedSections extension) In-Reply-To: <045.a233eeff02b647f43f9b3be3f223f677@haskell.org> References: <045.a233eeff02b647f43f9b3be3f223f677@haskell.org> Message-ID: <060.d915be3554f9ec52356a9d158231f4f1@haskell.org> #8304: more lenient operator sections (RelaxedSections extension) -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: feature | Status: new request | Milestone: Priority: lowest | Version: 7.6.3 Component: Compiler | Keywords: (Parser) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #4052 Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * related: => #4052 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 1 20:54:52 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Dec 2014 20:54:52 -0000 Subject: [GHC] #4049: Support for ABI versioning of C libraries In-Reply-To: <049.3f873076a2c6d5edb182373037a13851@haskell.org> References: <049.3f873076a2c6d5edb182373037a13851@haskell.org> Message-ID: <064.b9cc71368aacea0220752bc294633b36@haskell.org> #4049: Support for ABI versioning of C libraries -------------------------------------+------------------------------------- Reporter: uzytkownik | Owner: Type: bug | Status: new Priority: low | Milestone: 7.10.1 Component: Package | Version: 6.12.2 system | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: result at runtime | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * difficulty: => Unknown * component: Build System => Package system -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 1 21:10:37 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Dec 2014 21:10:37 -0000 Subject: [GHC] #9852: Add missing export lists Message-ID: <045.0c137db4833268f838cfd23c79dcf251@haskell.org> #9852: Add missing export lists -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: new Priority: low | Milestone: Component: Core Libraries | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less | Type of failure: than a day) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Some large modules, including `GHC.Base`, lack export lists, implicitly exporting all top-level identifiers. This is bad for various reasons, all of them obvious. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 1 21:20:27 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Dec 2014 21:20:27 -0000 Subject: [GHC] #4019: deriving Ord can produce incorrect and inefficient instances In-Reply-To: <041.298973948e102a278f8085229cb5ae01@haskell.org> References: <041.298973948e102a278f8085229cb5ae01@haskell.org> Message-ID: <056.93451d85614c3b5a81fc0627296bd5aa@haskell.org> #4019: deriving Ord can produce incorrect and inefficient instances -------------------------------------+------------------------------------- Reporter: rl | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 6.13 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * difficulty: => Unknown * milestone: 7.10.1 => Comment: This was fixed in 2010. A regression test is missing. commit f3c7ab8dbd5a46ef5a7aeeb398a6d4bc1482e606 {{{ Author: Simon Peyton Jones <> Date: Mon May 10 13:33:33 2010 +0000 Re-engineer the derived Ord instance generation code (fix Trac #4019) As well as fixing #4019, I rejigged the way that Ord instances are generated, which should make them faster in general. See the Note [Generating Ord instances]. I tried to measure the performance difference from this change, but the #4019 fix only removes one conditional branch per iteration, and I couldn't measure a consistent improvement. But still, tihs is better than before. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 1 21:32:07 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Dec 2014 21:32:07 -0000 Subject: [GHC] #7908: InstanceSigs suggestion not accepted In-Reply-To: <048.16e7666fc7d089cc84c391ee087463e7@haskell.org> References: <048.16e7666fc7d089cc84c391ee087463e7@haskell.org> Message-ID: <063.071f54c4b31315b09a9e50edc561d186@haskell.org> #7908: InstanceSigs suggestion not accepted -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 (Type checker) | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | polykinds/T7908 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => polykinds/T7908 * resolution: => fixed Comment: The patch (pointed to from the other tickets) fixes the problem by allowing instance signatures to be more polymorphic than the instantiated class method type. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 1 21:47:21 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Dec 2014 21:47:21 -0000 Subject: [GHC] #4347: Bug in unification of polymorphic and not-yet-polymorphic type In-Reply-To: <044.ff04e8084e7aca9611c332ca30665a4b@haskell.org> References: <044.ff04e8084e7aca9611c332ca30665a4b@haskell.org> Message-ID: <059.93e621d929003821da273289eddd22b4@haskell.org> #4347: Bug in unification of polymorphic and not-yet-polymorphic type -------------------------------------+------------------------------------- Reporter: dolio | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.1 (Type checker) | Keywords: Resolution: wontfix | Architecture: x86_64 (amd64) Operating System: Linux | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => wontfix Comment: Dolio is right here. I've backed off from making ANY claims about what GHC does or does not do for impredicative polymorphism. Really the language extension flag should be deprecated because it is not supported either by proper theory about what inference should do, or by an implementation of that theory. Whatever happens right now happens by luck. I'm sure there is a route to a better story for impredicativity; but it is complex territory and there has been much else to do. So yes I'll close this ticket Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 1 22:28:24 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Dec 2014 22:28:24 -0000 Subject: [GHC] #3977: Support double-byte encodings (Chinese/Japanese/Korean) on Windows In-Reply-To: <047.c9c7d46d6c64b0fab698219a5c9e7abf@haskell.org> References: <047.c9c7d46d6c64b0fab698219a5c9e7abf@haskell.org> Message-ID: <062.650a348b44ce93f18f877e0d4358ec8b@haskell.org> #3977: Support double-byte encodings (Chinese/Japanese/Korean) on Windows -------------------------------------+------------------------------------- Reporter: shelarcy | Owner: batterseapower Type: feature | Status: closed request | Milestone: Priority: low | Version: 6.13 Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Unknown Operating System: Windows | Blocked By: Type of failure: Incorrect | Related Tickets: #5754 result at runtime | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: core-libraries-committee@? (added) * status: new => closed * resolution: => fixed * milestone: 7.10.1 => Comment: commit 2216b89740cff6fd3225eb16e354b64f988d2900 {{{ Author: Max Bolingbroke <> Date: Thu Apr 18 21:29:08 2013 +0100 Support for Windows DBCS and new SBCS with MultiByteToWideChar Because MultiByteToWideChar/WideCharToMultiByte have a rather unhelpful interface, we have to use a lot of binary searching tricks to get them to match the iconv-like interface that GHC requires. Even though the resulting encodings are slow, it does at least mean that we now support all of Window's code pages. What's more, since these codecs are basically only used for console output there probably won't be a huge volume of text to deal with in the common case, so speed is less of a worry. Note that we will still use GHC's faster table-based custom codec for supported SBCSs. }}} commit 802e99a51955bcf3ba830ec5209470ffef93581b {{{ Author: Max Bolingbroke <> Date: Tue Apr 23 19:15:02 2013 +0100 Add comprehensive test for codepage encodings+recovery for them }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 1 22:50:09 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Dec 2014 22:50:09 -0000 Subject: [GHC] #9818: Add `Natural` number type to `base` In-Reply-To: <042.8652fbefbb96a94879b1f06096e9b13e@haskell.org> References: <042.8652fbefbb96a94879b1f06096e9b13e@haskell.org> Message-ID: <057.2cff8a6d8e5f18dad80435b1ba0442a5@haskell.org> #9818: Add `Natural` number type to `base` -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: Component: Core | Keywords: base natural Libraries | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #3650 #9281 Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D473 | -------------------------------------+------------------------------------- Comment (by thomie): The comment about @Natural@ in `libraries/base/Data/Word.hs` can be deleted or changed to point to this new module. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 1 23:23:43 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Dec 2014 23:23:43 -0000 Subject: [GHC] #3859: Problems with toClockTime on NetBSD In-Reply-To: <044.b73ad5191ac77fa3291243672b7b74cf@haskell.org> References: <044.b73ad5191ac77fa3291243672b7b74cf@haskell.org> Message-ID: <059.49d7c4bb0e415974fbf5721aba794679@haskell.org> #3859: Problems with toClockTime on NetBSD -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: closed Priority: lowest | Milestone: 7.10.1 Component: Compiler | Version: 6.12.1 Resolution: invalid | Keywords: Operating System: NetBSD | Architecture: Unknown/Multiple Type of failure: | Difficulty: Unknown None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * difficulty: => Unknown * resolution: => invalid Comment: This was an issue filed against `old-time`, which is no longer used by GHC. Please see https://github.com/haskell/time/issues for the `time` issue tracker, if this problem still exists. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 00:13:09 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 00:13:09 -0000 Subject: [GHC] #3844: Undeprecate #include (in at least some circumstances) In-Reply-To: <042.5b982471a1a08813e02c6c6a28134af7@haskell.org> References: <042.5b982471a1a08813e02c6c6a28134af7@haskell.org> Message-ID: <057.09a4ba186f1bb2b571eb651fa5ee9df8@haskell.org> #3844: Undeprecate #include (in at least some circumstances) -------------------------------------+------------------------------------- Reporter: cjs | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: Compiler | Version: 6.12.1 (FFI) | Keywords: #include Resolution: fixed | deprecation Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: warning at compile-time | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * difficulty: => Unknown * resolution: => fixed * milestone: 7.10.1 => Comment: `hsc2hs` has not been emitting `INCLUDE` pragmas since ghc 7.4. http://git.haskell.org/hsc2hs.git/commit/864afb251b11b51f3c0221ec81dc575b7c7edb99 {{{ Author: Simon Marlow <> Date: Sun Aug 2 19:03:45 2009 +0000 only emit {-# INCLUDE #-} pragmas for GHC < 6.10 }}} http://git.haskell.org/hsc2hs.git/commit/f8cbf37ab28ab4512d932678c08c263aa412e008 {{{ Author: Ian Lynagh Date: Mon Aug 8 21:41:44 2011 +0100 Remove the support for old GHC versions The conditional code was all for versions < 6.10, so old enough that they can't be used to compile the HEAD. Additionally, it didn't work properly. It relied on __GLASGOW_HASKELL__ being defined when compiling the C, rather than having the C print the conditionals as part of the Haskell. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 00:25:59 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 00:25:59 -0000 Subject: [GHC] #3814: Compile to more than one (sub)-architecture In-Reply-To: <045.81dca617e2084ce61e4f3745c003b436@haskell.org> References: <045.81dca617e2084ce61e4f3745c003b436@haskell.org> Message-ID: <060.d36be71460c203b15c1af6d9df1e18be@haskell.org> #3814: Compile to more than one (sub)-architecture -------------------------------------+------------------------------------- Reporter: filcab | Owner: Type: feature | Status: closed request | Milestone: ? Priority: normal | Version: 6.12.1 Component: Compiler | Keywords: architecture, Resolution: duplicate | compiler, x86_64 Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #4163 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * difficulty: => Unknown * resolution: => duplicate * related: => #4163 Comment: See [wiki:CrossCompilation] and [wiki:Building/CrossCompiling]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 00:36:11 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 00:36:11 -0000 Subject: [GHC] #3771: haddock: internal error: evacuate: strange closure type 19269 In-Reply-To: <045.5a5990fc01611a666ea323a5f0afc325@haskell.org> References: <045.5a5990fc01611a666ea323a5f0afc325@haskell.org> Message-ID: <060.642d9dd9beee1b5af7a7d675201a9f8e@haskell.org> #3771: haddock: internal error: evacuate: strange closure type 19269 ----------------------------------------------+--------------------------- Reporter: dbueno | Owner: Type: bug | Status: closed Priority: lowest | Milestone: 7.10.1 Component: Compiler | Version: 6.12.1 Resolution: worksforme | Keywords: Operating System: MacOS X | Architecture: powerpc Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------------+--------------------------- Changes (by thomie): * status: new => closed * difficulty: => Unknown * resolution: => worksforme Comment: Judging by bug reports such as #8024 and #8909, the powerpc ''build'' worked fairly recently, so I'm closing this 5 year old "Building GHC failed" ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 00:40:38 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 00:40:38 -0000 Subject: [GHC] #3767: SpecConstr for join points In-Reply-To: <046.4ab0a63e59360e2986f5c0a1b503004f@haskell.org> References: <046.4ab0a63e59360e2986f5c0a1b503004f@haskell.org> Message-ID: <061.2d8cfc22d01e82045e22d109143ec625@haskell.org> #3767: SpecConstr for join points -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: low | Milestone: 7.10.1 Component: Compiler | Version: 6.12.1 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * difficulty: => Unknown * failure: None/Unknown => Runtime performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 00:52:20 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 00:52:20 -0000 Subject: [GHC] #3765: Rules should "look through" case binders too In-Reply-To: <046.ad386b06466c9a5e784b413a9038b207@haskell.org> References: <046.ad386b06466c9a5e784b413a9038b207@haskell.org> Message-ID: <061.9da7b600e54b77b84ea098e71afbc834@haskell.org> #3765: Rules should "look through" case binders too -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: 6.12.1 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * difficulty: => Unknown * failure: None/Unknown => Runtime performance bug Comment: Confirmed in HEAD (7.9.20141130). For reference: the following command shows `Rule fired: dec/inc` only if the bang is removed. `$ ghc -ddump-rule-firings -fforce-recomp -O T3765.hs` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 01:07:16 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 01:07:16 -0000 Subject: [GHC] #5495: simple program fails with -shared on mac In-Reply-To: <046.aeb51d939f07cb4da8bcfe42bb7b5f4a@haskell.org> References: <046.aeb51d939f07cb4da8bcfe42bb7b5f4a@haskell.org> Message-ID: <061.cde0a2d587f0bcc2335176e5b0ffee25@haskell.org> #5495: simple program fails with -shared on mac -------------------------------------+------------------------------------- Reporter: mwotton | Owner: Type: bug | Status: new Priority: low | Milestone: 7.10.1 Component: Compiler | Version: 7.2.1 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): Replying to [comment:9 rwbarton]: > I'm not sure whether this is a bug at all. You need `-dynamic` also, to produce object files that can be linked dynamically. Yes, but igloo would know about that, so we should test if the issue from comment:3 is resolved. > Granted, the way that `-shared` and `-dynamic` interact with make mode is, at best, not obvious. See #3704, #3713 and #3712 for that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 02:40:18 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 02:40:18 -0000 Subject: [GHC] #3739: ghc-cabal mishandles relative paths in arguments In-Reply-To: <048.33ad0d7b937dcb44ba82750481db301b@haskell.org> References: <048.33ad0d7b937dcb44ba82750481db301b@haskell.org> Message-ID: <063.4396070ee209adde6038fdc74fdf6daf@haskell.org> #3739: ghc-cabal mishandles relative paths in arguments -------------------------------------+------------------------------------- Reporter: asuffield | Owner: Type: bug | Status: closed Priority: low | Milestone: 7.10.1 Component: Build | Version: System | Keywords: Resolution: invalid | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * difficulty: => Unknown * resolution: => invalid Comment: `ghc-cabal` is currently only used when [wiki:Building/Architecture/Idiom/Cabal building] ghc (maybe that was different 5 years ago?), and ghc builds just fine, so I think we can close this issue. Also note that ghc's dependency on Cabal is planned to be removed altogether (#8244). The cabal user problem of `--package-db` not handling relative paths was fixed in https://github.com/haskell/cabal/pull/1307. See [https://github.com/haskell/cabal/issues/1542 cabal #1542], [https://github.com/haskell/cabal/issues/462 cabal #462] for related cabal issues. Please re-open if I'm misunderstanding the problem here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 02:41:17 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 02:41:17 -0000 Subject: [GHC] #3739: ghc-cabal mishandles relative paths in arguments In-Reply-To: <048.33ad0d7b937dcb44ba82750481db301b@haskell.org> References: <048.33ad0d7b937dcb44ba82750481db301b@haskell.org> Message-ID: <063.dfff822e046b40447dfafc3700a3f3d9@haskell.org> #3739: ghc-cabal mishandles relative paths in arguments -------------------------------------+------------------------------------- Reporter: asuffield | Owner: Type: bug | Status: closed Priority: low | Milestone: 7.10.1 Component: Build | Version: System | Keywords: Resolution: invalid | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): See also 6e998535044b9565b46d1d0d5453427c4051a7b4: {{{ Author: Ian Lynagh Date: Sun Sep 27 01:06:05 2009 +0000 Add support for relocatable builds in the new build system }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 03:11:38 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 03:11:38 -0000 Subject: [GHC] #3744: Comparisons against minBound/maxBound not optimised for (Int|Word)(8|16|32) (was: Comparisons against minBound/maxBound not optimised) In-Reply-To: <041.2169b48b8108c3b700385a622d1921fe@haskell.org> References: <041.2169b48b8108c3b700385a622d1921fe@haskell.org> Message-ID: <056.5a85b074c35c542e685f121073eb016f@haskell.org> #3744: Comparisons against minBound/maxBound not optimised for (Int|Word)(8|16|32) -------------------------------------+------------------------------------- Reporter: rl | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: low | Version: 6.13 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * difficulty: => Unknown * type: bug => feature request Comment: Status: see comment:12. Use program from comment:5 to test, and replace `Int` by `Int8` (`Int64` works since 7.4). For reference: commit d4781f3e6e8cead1cbeac5337f9f78440c8df8bc {{{ Author: Michal Terepeta <> Date: Wed Oct 27 18:40:54 2010 +0000 Optimise comparisons against min/maxBound (ticket #3744). This optimises away comparisons with minBound or maxBound that are always false or always true. }}} commit fe5821233d439c35c441cfc6c9d2029e5fd01342 {{{ Author: Ian Lynagh <> Date: Wed Sep 19 22:37:01 2012 +0100 Make some uses of minBound/maxBound use the target Int/Word sizes }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 03:51:08 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 03:51:08 -0000 Subject: [GHC] #9853: Stateful transformation causes non-termination in Hoopl analysis. Message-ID: <053.2d239df8bf190457291ca13b6378af1c@haskell.org> #9853: Stateful transformation causes non-termination in Hoopl analysis. -------------------------------------+------------------------------------- Reporter: AndreasVoellmy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/hoopl | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Incorrect Blocked By: | result at runtime Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- It seems that Hoopl's analyses may apply rewrites to nodes multiple times without invoking the `restart` function between applications. This causes havoc for code transformations that have side-effects, for example a transformation that introduces a new variable to hold some intermediate result. In such an analysis, a transformation may introduce a new variable, which leads to a changed fact. Later the transformation may be run again, leading to a new fact, and so on (when there is a loop in the control flow. The attached example illustrates this problem. This example modifies the constant propagation pass provided in the testing directory of the hoopl library. The example added a new instruction called "Funny" that gets rewritten to an unconditional branch instruction and introduces a new variable. The main program P1 performs the analysis on a particular program that has a loop in the control flow graph and causes the hoopl analysis to run forever. Is this a bug in Hoopl? Ie. should analyses that have side-effects involving checkpointed state be supported? If not, could it be changed to support these analyses? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 05:26:37 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 05:26:37 -0000 Subject: [GHC] #4505: Segmentation fault on long input (list of pairs) In-Reply-To: <046.2dc545b3c32e7b8eef61780dd9491ae5@haskell.org> References: <046.2dc545b3c32e7b8eef61780dd9491ae5@haskell.org> Message-ID: <061.9cea90636e1025d2bc51121eabe73cd3@haskell.org> #4505: Segmentation fault on long input (list of pairs) -------------------------------------+------------------------------------- Reporter: cathper | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Segmentation Operating System: Linux | fault, segfault, long input Type of failure: Runtime | Architecture: x86_64 (amd64) crash | Difficulty: Unknown Test Case: | Blocked By: 4258 Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Changes (by snoyberg): * cc: snoyberg (added) Comment: I just ran into this on our code base. Is there any chance of getting a fix for this into the 7.8 series? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 07:40:23 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 07:40:23 -0000 Subject: [GHC] #9818: Add `Natural` number type to `base` In-Reply-To: <042.8652fbefbb96a94879b1f06096e9b13e@haskell.org> References: <042.8652fbefbb96a94879b1f06096e9b13e@haskell.org> Message-ID: <057.19c150fea858023301653a70d0945571@haskell.org> #9818: Add `Natural` number type to `base` -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: Component: Core | Keywords: base natural Libraries | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #3650 #9281 Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D473 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"a29e295c6fddfb0bbd390cff8cf2e5dbe9b1aa5b/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a29e295c6fddfb0bbd390cff8cf2e5dbe9b1aa5b" Mention existence of 'Natural' in "Data.Word" This replaces the note mentioning the lack of a `Natural`-type by a note pointing to the new "Numeric.Natural" (#9818) module. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 08:46:05 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 08:46:05 -0000 Subject: [GHC] #9757: Warn about derivable instances In-Reply-To: <045.a8d7646a67a5d965d67349d97ec3ca52@haskell.org> References: <045.a8d7646a67a5d965d67349d97ec3ca52@haskell.org> Message-ID: <060.82e2abcafdf9c207749d6ca52f09e56a@haskell.org> #9757: Warn about derivable instances -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: closed request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: wontfix | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by NeilMitchell): HLint knows nothing about types, has no translation to Core and only has approximate information about name binding. Your approach seems feasible in GHC, and it might do a reasonable job, but wouldn't be suitable in HLint. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 09:13:40 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 09:13:40 -0000 Subject: [GHC] #9582: Associated Type Synonyms do not unfold in InstanceSigs In-Reply-To: <051.1c38a1e6c743f17158ef37805e71fa91@haskell.org> References: <051.1c38a1e6c743f17158ef37805e71fa91@haskell.org> Message-ID: <066.ef5b2adccc99e25cdf3d56ff4fd48c23@haskell.org> #9582: Associated Type Synonyms do not unfold in InstanceSigs -------------------------------------+------------------------------------- Reporter: | Owner: andreas.abel | Status: closed Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: InstanceSigs (Type checker) | TypeFamilies Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: indexed- | types/should_compile/T9582 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by andreas.abel): Thanks for fixing. At the point where I was stuck, I would have needed to dive much deeper into GHC, I guess, and I did not have the time. It was an interesting experience anyway. Contributing to GHC is a full- time job, as for Agda, and I cannot work two jobs. I am rather glad to work on Agda, which "only" takes 15 min for compilation + test suite---as opposed to GHC's 120 min. Cheers and thanks for your work, Andreas -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 09:29:51 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 09:29:51 -0000 Subject: [GHC] #9851: Hoopl library in GHC hides runWithFuel / version number clash In-Reply-To: <053.a80518c51ae2062a4e162a281daf017f@haskell.org> References: <053.a80518c51ae2062a4e162a281daf017f@haskell.org> Message-ID: <068.f804d221cb36acf773392f5e1ea4e920@haskell.org> #9851: Hoopl library in GHC hides runWithFuel / version number clash -------------------------------------+------------------------------------- Reporter: | Owner: AndreasVoellmy | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: | Keywords: libraries/hoopl | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: Other | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonmar): Hoopl needs a maintainer, but in the absence of one feel free to upload a new version to Hackage. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 09:47:31 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 09:47:31 -0000 Subject: [GHC] #9851: Hoopl library in GHC hides runWithFuel / version number clash In-Reply-To: <053.a80518c51ae2062a4e162a281daf017f@haskell.org> References: <053.a80518c51ae2062a4e162a281daf017f@haskell.org> Message-ID: <068.a216ed0cb90a2bb9c9be27873c677146@haskell.org> #9851: Hoopl library in GHC hides runWithFuel / version number clash -------------------------------------+------------------------------------- Reporter: | Owner: AndreasVoellmy | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: | Keywords: libraries/hoopl | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: Other | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): I think the issue is that Hoopl comes with a GHC distribution, so it's not enough to upload a new version to Hackage, alone. Andreas, we'd be happy to do whatever works best for you. * Send us a patch and we can apply it to the Hoopl repo. * Tell us if you want something to happen before the 7.10.1 release, and if so what. * Better still, you could become the maintainer. Hoopl needs love. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 09:51:44 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 09:51:44 -0000 Subject: [GHC] #9851: Hoopl library in GHC hides runWithFuel / version number clash In-Reply-To: <053.a80518c51ae2062a4e162a281daf017f@haskell.org> References: <053.a80518c51ae2062a4e162a281daf017f@haskell.org> Message-ID: <068.951c2d2b1ee950fd7e7cffa198394773@haskell.org> #9851: Hoopl library in GHC hides runWithFuel / version number clash -------------------------------------+------------------------------------- Reporter: | Owner: AndreasVoellmy | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: | Keywords: libraries/hoopl | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #8315 Type of failure: Other | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by jstolarek): * related: => #8315 Comment: This wiki page is also related: Hoopl/Cleanup -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 10:07:39 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 10:07:39 -0000 Subject: [GHC] #9851: Hoopl library in GHC hides runWithFuel / version number clash In-Reply-To: <053.a80518c51ae2062a4e162a281daf017f@haskell.org> References: <053.a80518c51ae2062a4e162a281daf017f@haskell.org> Message-ID: <068.3cbaf3fd36f9a8e850296044fddaeb1c@haskell.org> #9851: Hoopl library in GHC hides runWithFuel / version number clash -------------------------------------+------------------------------------- Reporter: | Owner: AndreasVoellmy | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: | Keywords: libraries/hoopl | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #8315 Type of failure: Other | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek): And a related ghc-devs thread: https://www.haskell.org/pipermail/ghc- devs/2013-July/001820.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 10:30:51 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 10:30:51 -0000 Subject: [GHC] #4505: Segmentation fault on long input (list of pairs) In-Reply-To: <046.2dc545b3c32e7b8eef61780dd9491ae5@haskell.org> References: <046.2dc545b3c32e7b8eef61780dd9491ae5@haskell.org> Message-ID: <061.1611056f6a5b4ba6a5bfce2def489fa5@haskell.org> #4505: Segmentation fault on long input (list of pairs) -------------------------------------+------------------------------------- Reporter: cathper | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Segmentation Operating System: Linux | fault, segfault, long input Type of failure: Runtime | Architecture: x86_64 (amd64) crash | Difficulty: Unknown Test Case: | Blocked By: 4258 Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * priority: high => highest Comment: I wish this had come up 3 weeks ago when we were triaging tickets for 7.8. The release candidate for 7.8.4 is out, so it's tough to get anything else in. Unless you say "this makes 7.8 unusable for my purposes". (This is the case for 7.8.3, which is why we went ahead with 7.8.4.) Putting it in would mean a delay of a couple of weeks while (a) Simon re- instates the previous fix, (b) Austin makes a new release candidate (c) everyone tests it. Of course, it's better to delay 7.8.4 than to have to put out 7.8.5. But if we keep doing that, we never make a release. My instinct is "too late". But is there strong user sentiment about this one? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 10:43:13 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 10:43:13 -0000 Subject: [GHC] #4505: Segmentation fault on long input (list of pairs) In-Reply-To: <046.2dc545b3c32e7b8eef61780dd9491ae5@haskell.org> References: <046.2dc545b3c32e7b8eef61780dd9491ae5@haskell.org> Message-ID: <061.49d177f157ce041ce9ad5add6f778fbf@haskell.org> #4505: Segmentation fault on long input (list of pairs) -------------------------------------+------------------------------------- Reporter: cathper | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Segmentation Operating System: Linux | fault, segfault, long input Type of failure: Runtime | Architecture: x86_64 (amd64) crash | Difficulty: Unknown Test Case: | Blocked By: 4258 Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonmar): The code that implements the runtime check is still in place, it's only the compile-time check that we lost. So you don't get a segfault, but you do get a runtime failure: {{{ barf("allocation of %ld bytes too large (GHC should have complained at compile-time)", (long)cap->r.rHpAlloc); }}} @snoyberg: do you see this? Given this, I don't think it's worth holding up 7.8.4. We wouldn't be fixing the bug, only moving the failure to compile-time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 10:45:13 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 10:45:13 -0000 Subject: [GHC] #9853: Stateful transformation causes non-termination in Hoopl analysis. In-Reply-To: <053.2d239df8bf190457291ca13b6378af1c@haskell.org> References: <053.2d239df8bf190457291ca13b6378af1c@haskell.org> Message-ID: <068.d4f438142a189031b66cb6b910a73ee6@haskell.org> #9853: Stateful transformation causes non-termination in Hoopl analysis. -------------------------------------+------------------------------------- Reporter: | Owner: AndreasVoellmy | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: | Keywords: libraries/hoopl | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: Incorrect | result at runtime | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek): I've run into identical problem in the past: https://www.haskell.org/pipermail/ghc-devs/2013-August/001954.html Some of my earlier questions about Hoopl might also be relevant: https://www.haskell.org/pipermail/ghc-devs/2013-July/001777.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 10:45:52 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 10:45:52 -0000 Subject: [GHC] #9851: Hoopl library in GHC hides runWithFuel / version number clash In-Reply-To: <053.a80518c51ae2062a4e162a281daf017f@haskell.org> References: <053.a80518c51ae2062a4e162a281daf017f@haskell.org> Message-ID: <068.be82305b16846cd859ad321c5c1404c5@haskell.org> #9851: Hoopl library in GHC hides runWithFuel / version number clash -------------------------------------+------------------------------------- Reporter: | Owner: AndreasVoellmy | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: | Keywords: libraries/hoopl | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #8315 Type of failure: Other | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek): Here's some discussion about fuel: https://www.haskell.org/pipermail/ghc- devs/2013-August/001951.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 10:56:24 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 10:56:24 -0000 Subject: [GHC] #4505: Segmentation fault on long input (list of pairs) In-Reply-To: <046.2dc545b3c32e7b8eef61780dd9491ae5@haskell.org> References: <046.2dc545b3c32e7b8eef61780dd9491ae5@haskell.org> Message-ID: <061.027dd3ca219e7722156ff513ed254a31@haskell.org> #4505: Segmentation fault on long input (list of pairs) -------------------------------------+------------------------------------- Reporter: cathper | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Segmentation Operating System: Linux | fault, segfault, long input Type of failure: Runtime | Architecture: x86_64 (amd64) crash | Difficulty: Unknown Test Case: | Blocked By: 4258 Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Comment (by snoyberg): @simonmar: Yes, that's the error message we're seeing at runtime. Moving this bug from runtime to compile time would be a *huge* advantage to me. But I agree that it's not worth holding up the release. To clarify: I would still be very happy to see a fix for this on the 7.8 branch, as we could build our own GHC binary with the patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 10:56:56 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 10:56:56 -0000 Subject: [GHC] #2182: ghc sessions (--make, --interactive, ghc api) erroneously retain instances In-Reply-To: <044.c09df8f4b72158c8c14035187a5540c9@haskell.org> References: <044.c09df8f4b72158c8c14035187a5540c9@haskell.org> Message-ID: <059.1dca79694df7fa4108e671bde88da20e@haskell.org> #2182: ghc sessions (--make, --interactive, ghc api) erroneously retain instances -------------------------------------+------------------------------------- Reporter: claus | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 6.9 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: accepts invalid program | Test Case: | Blocking: | Differential Revisions: Phab:D488 | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: ezyang => * status: closed => new * resolution: fixed => Comment: Edward, would you care to add a regression test? I'll re-open for that purpose. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 10:57:09 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 10:57:09 -0000 Subject: [GHC] #2182: ghc sessions (--make, --interactive, ghc api) erroneously retain instances In-Reply-To: <044.c09df8f4b72158c8c14035187a5540c9@haskell.org> References: <044.c09df8f4b72158c8c14035187a5540c9@haskell.org> Message-ID: <059.2394eff4962de6fa5fbeb229878a5db2@haskell.org> #2182: ghc sessions (--make, --interactive, ghc api) erroneously retain instances -------------------------------------+------------------------------------- Reporter: claus | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 6.9 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: accepts invalid program | Test Case: | Blocking: | Differential Revisions: Phab:D488 | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: => ezyang -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 11:13:57 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 11:13:57 -0000 Subject: [GHC] #2182: ghc sessions (--make, --interactive, ghc api) erroneously retain instances In-Reply-To: <044.c09df8f4b72158c8c14035187a5540c9@haskell.org> References: <044.c09df8f4b72158c8c14035187a5540c9@haskell.org> Message-ID: <059.094c635571213f19a3d8669231765643@haskell.org> #2182: ghc sessions (--make, --interactive, ghc api) erroneously retain instances -------------------------------------+------------------------------------- Reporter: claus | Owner: ezyang Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 6.9 (Type checker) | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: accepts invalid program | Test Case: T2182ghci, | T2182ghci2, T2182 | Blocking: | Differential Revisions: Phab:D488 | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * testcase: => T2182ghci, T2182ghci2, T2182 * resolution: => fixed Comment: Already did. :) T2182ghci, T2182ghci2, T2182. I'll add them to the ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 11:49:32 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 11:49:32 -0000 Subject: [GHC] #7647: UNPACK polymorphic fields In-Reply-To: <045.8091f80cf766b683cf12520609e77aee@haskell.org> References: <045.8091f80cf766b683cf12520609e77aee@haskell.org> Message-ID: <060.40906511767c1a16bb55b21ad4f3997a@haskell.org> #7647: UNPACK polymorphic fields -------------------------------------+------------------------------------- Reporter: liyang | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.6.1 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: 3990 performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: simonpj => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 11:51:57 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 11:51:57 -0000 Subject: [GHC] #4428: Local functions lose their unfoldings In-Reply-To: <041.05f579c54cae7f6ea359ae3b76daabb5@haskell.org> References: <041.05f579c54cae7f6ea359ae3b76daabb5@haskell.org> Message-ID: <056.433a88dd4ddf9ea383d5ef24f3b7ce01@haskell.org> #4428: Local functions lose their unfoldings -------------------------------------+------------------------------------- Reporter: rl | Owner: Type: bug | Status: infoneeded Priority: low | Milestone: 7.10.1 Component: Compiler | Version: 7.1 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): I believe it's fixed; or at least some things were done, and the subsequent discussion is inconclusive. I'm inclined to close it if no one objects. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 11:57:54 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 11:57:54 -0000 Subject: [GHC] #4121: Refactor the plumbing of CafInfo to make it more robust In-Reply-To: <045.e33af6968458760182e141457b350018@haskell.org> References: <045.e33af6968458760182e141457b350018@haskell.org> Message-ID: <060.4ede906df8bc3f175de0b6cc5d3021bc@haskell.org> #4121: Refactor the plumbing of CafInfo to make it more robust -------------------------------------+------------------------------------- Reporter: dterei | Owner: Type: task | Status: new Priority: low | Milestone: 7.10.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): I've added it to my list, because it does indeed need attention. I think the right thing is to extract the information during the core-to- STG pass, and back-patch it into the interface-file info. The difficulty is really just ensuring that we don't thereby make space behaviour a lot worse by, in effect, having two copies of the program in memory at once. I'd welcome help with doing this. Not hard, but needs a bit of care. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 11:57:57 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 11:57:57 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICM5MjQwOiAicmVhZCAuIHNob3cg4omhIGlkIiBu?= =?utf-8?q?ot_satisfied_by_Data=2EFixed?= In-Reply-To: <042.bb0c4150424061c49087c6a88d193db3@haskell.org> References: <042.bb0c4150424061c49087c6a88d193db3@haskell.org> Message-ID: <057.d40e773252594b97d94b51cb0acb392e@haskell.org> #9240: "read . show ? id" not satisfied by Data.Fixed -------------------------------------+------------------------------------- Reporter: hvr | Owner: ekmett Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.2.1 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #9231 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D547 | -------------------------------------+------------------------------------- Changes (by thomie): * cc: core-libraries-committee@? (added) * status: new => patch * differential: => Phab:D547 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 12:44:04 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 12:44:04 -0000 Subject: [GHC] #9812: Split `SynTyCon` into `SynonymTyCon` and `FamilyTyCon` In-Reply-To: <048.4866ee60f605f71fd09e288292fbe44d@haskell.org> References: <048.4866ee60f605f71fd09e288292fbe44d@haskell.org> Message-ID: <063.9ed383139512831b933a28dfbba50194@haskell.org> #9812: Split `SynTyCon` into `SynonymTyCon` and `FamilyTyCon` -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Moderate (less Type of failure: | than a day) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: Phab:D508 | -------------------------------------+------------------------------------- Changes (by jstolarek): * owner: jstolarek => * status: closed => new * resolution: fixed => Comment: Some documentation still refers to `SynTyCon`. Re-opening. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 13:10:46 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 13:10:46 -0000 Subject: [GHC] #9812: Split `SynTyCon` into `SynonymTyCon` and `FamilyTyCon` In-Reply-To: <048.4866ee60f605f71fd09e288292fbe44d@haskell.org> References: <048.4866ee60f605f71fd09e288292fbe44d@haskell.org> Message-ID: <063.e2e2130ae7247ab3dfb434e65ab53571@haskell.org> #9812: Split `SynTyCon` into `SynonymTyCon` and `FamilyTyCon` -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Moderate (less Type of failure: | than a day) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: Phab:D508 | -------------------------------------+------------------------------------- Comment (by Jan Stolarek ): In [changeset:"668a1379778189495679840e0151dfceed4b8ef7/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="668a1379778189495679840e0151dfceed4b8ef7" Remove references to SynTyCon. Fixes #9812 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 13:11:09 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 13:11:09 -0000 Subject: [GHC] #9812: Split `SynTyCon` into `SynonymTyCon` and `FamilyTyCon` In-Reply-To: <048.4866ee60f605f71fd09e288292fbe44d@haskell.org> References: <048.4866ee60f605f71fd09e288292fbe44d@haskell.org> Message-ID: <063.d20e98ef565b893ca1ac37bfd7eece78@haskell.org> #9812: Split `SynTyCon` into `SynonymTyCon` and `FamilyTyCon` -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: closed Priority: low | Milestone: Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Moderate (less Type of failure: | than a day) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: Phab:D508 | -------------------------------------+------------------------------------- Changes (by jstolarek): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 13:24:03 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 13:24:03 -0000 Subject: [GHC] #4896: Deriving Data does not work for attached code In-Reply-To: <044.d2e84887ce906663629df5acb6b383eb@haskell.org> References: <044.d2e84887ce906663629df5acb6b383eb@haskell.org> Message-ID: <059.a149eba01ef191e4c8fa27bf743534c1@haskell.org> #4896: Deriving Data does not work for attached code -------------------------------------+------------------------------------- Reporter: mitar | Owner: Type: bug | Status: infoneeded Priority: low | Milestone: 7.10.1 Component: Compiler | Version: 7.1 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | deriving/should_compile/T4896 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: dreixel (added) * testcase: => deriving/should_compile/T4896 Comment: The error message for mojojojo is exactly right. The error message from HEAD for the original example is actually a long- standing bug; quite a different one from the one originally reported. This code should compile. Good catch, thank you Tomie! Patch coming. Pedro, can you just check that I have done this right? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 13:27:36 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 13:27:36 -0000 Subject: [GHC] #4921: report ambiguous type variables more consistently In-Reply-To: <045.c5b1ea6508a19a0a431bf73213b97654@haskell.org> References: <045.c5b1ea6508a19a0a431bf73213b97654@haskell.org> Message-ID: <060.76d1b367f766450333bd92d3ac9347f5@haskell.org> #4921: report ambiguous type variables more consistently -------------------------------------+------------------------------------- Reporter: Saizan | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: low | Version: 7.0.1 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"30d260586d46466419b109057ec87d4f097331a1/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="30d260586d46466419b109057ec87d4f097331a1" Test Trac #4921 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 13:27:37 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 13:27:37 -0000 Subject: [GHC] #2182: ghc sessions (--make, --interactive, ghc api) erroneously retain instances In-Reply-To: <044.c09df8f4b72158c8c14035187a5540c9@haskell.org> References: <044.c09df8f4b72158c8c14035187a5540c9@haskell.org> Message-ID: <059.c61316440f403b6683ce753022b52233@haskell.org> #2182: ghc sessions (--make, --interactive, ghc api) erroneously retain instances -------------------------------------+------------------------------------- Reporter: claus | Owner: ezyang Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 6.9 (Type checker) | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: accepts invalid program | Test Case: T2182ghci, | T2182ghci2, T2182 | Blocking: | Differential Revisions: Phab:D488 | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"2a67fb3990f23391fecaec335f0d010434d2738e/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="2a67fb3990f23391fecaec335f0d010434d2738e" Minor refactoring of Edward's recent orphans patch (Trac #2182) This patch is all small stuff - Move VisibleOrphanModules from Module to InstEnv (with the other orphan stuff) - Move Notes about orphans from IfaceSyn to InstEnv (ditto) - Make use of the record field names in InstEnvs }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 13:27:37 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 13:27:37 -0000 Subject: [GHC] #4896: Deriving Data does not work for attached code In-Reply-To: <044.d2e84887ce906663629df5acb6b383eb@haskell.org> References: <044.d2e84887ce906663629df5acb6b383eb@haskell.org> Message-ID: <059.1d0bb2386d192f43897f5620a5e88cc5@haskell.org> #4896: Deriving Data does not work for attached code -------------------------------------+------------------------------------- Reporter: mitar | Owner: Type: bug | Status: infoneeded Priority: low | Milestone: 7.10.1 Component: Compiler | Version: 7.1 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | deriving/should_compile/T4896 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"863854a3a490afd9e3ecf0da6294a3b078f4a6a1/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="863854a3a490afd9e3ecf0da6294a3b078f4a6a1" Fix another bug in deriving( Data ) for data families; Trac #4896 If we have data family D a data instance D (a,b,c) = ... deriving( Data ) then we want to generate instance ... => Data (D (a,b,c)) where ... dataCast1 x = gcast1 x The "1" here comes from the kind of D. But the kind of the *representation* TyCon is data Drep a b c = .... ie Drep :: * -> * -> * -> * So we must look for the *family* TyCon in this (rather horrible) dataCast1 / dataCast2 binding. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 13:33:26 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 13:33:26 -0000 Subject: [GHC] #4896: Deriving Data does not work for attached code In-Reply-To: <044.d2e84887ce906663629df5acb6b383eb@haskell.org> References: <044.d2e84887ce906663629df5acb6b383eb@haskell.org> Message-ID: <059.2fdfdf9cc5de24a75375674312bcf65e@haskell.org> #4896: Deriving Data does not work for attached code -------------------------------------+------------------------------------- Reporter: mitar | Owner: Type: bug | Status: infoneeded Priority: low | Milestone: 7.10.1 Component: Compiler | Version: 7.1 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | deriving/should_compile/T4896 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dreixel): Looks good to me! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 13:34:38 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 13:34:38 -0000 Subject: [GHC] #4921: report ambiguous type variables more consistently In-Reply-To: <045.c5b1ea6508a19a0a431bf73213b97654@haskell.org> References: <045.c5b1ea6508a19a0a431bf73213b97654@haskell.org> Message-ID: <060.74b1633df2e42454d50bdb4031f032e0@haskell.org> #4921: report ambiguous type variables more consistently -------------------------------------+------------------------------------- Reporter: Saizan | Owner: Type: feature | Status: closed request | Milestone: 7.10.1 Priority: low | Version: 7.0.1 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | typecheck/should_fail/T4921 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => typecheck/should_fail/T4921 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 15:13:01 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 15:13:01 -0000 Subject: [GHC] #7947: Name conflict with DerivingDataTypeable, StandaloneDeriving and qualified imports In-Reply-To: <047.12b570c09cfb6a6e5d35ce562b9ab002@haskell.org> References: <047.12b570c09cfb6a6e5d35ce562b9ab002@haskell.org> Message-ID: <062.9e42c79a6601d344805dbd90a68d091f@haskell.org> #7947: Name conflict with DerivingDataTypeable, StandaloneDeriving and qualified imports -------------------------------------+------------------------------------- Reporter: a.ulrich | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"c41d214a8dd8e2fe7ae9a3446aeda1a07328b831/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c41d214a8dd8e2fe7ae9a3446aeda1a07328b831" Unique-ify the names of top-level auxiliary bindings in derived instances (Trac #7947) The problem and its solution are explained in Note [Auxiliary binders] in TcGenDeriv }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 15:14:40 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 15:14:40 -0000 Subject: [GHC] #7947: Name conflict with DerivingDataTypeable, StandaloneDeriving and qualified imports In-Reply-To: <047.12b570c09cfb6a6e5d35ce562b9ab002@haskell.org> References: <047.12b570c09cfb6a6e5d35ce562b9ab002@haskell.org> Message-ID: <062.afcf12b1a17d20c79dd8145ebf528fc1@haskell.org> #7947: Name conflict with DerivingDataTypeable, StandaloneDeriving and qualified imports -------------------------------------+------------------------------------- Reporter: a.ulrich | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 (Type checker) | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | deriving/should_compile/T7947 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => deriving/should_compile/T7947 * resolution: => fixed Comment: Great catch, fortunately quite easy to fix. Thanks for bringing it up Thomie. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 15:48:24 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 15:48:24 -0000 Subject: [GHC] #9854: Literal overflow check is too aggressive Message-ID: <044.0949ac05531a8c6732f39a917c7dcb0f@haskell.org> #9854: Literal overflow check is too aggressive -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The literal overflow check is too aggressive. Sometimes you want to give a literal as a hexadecimal value that does fit inside e.g. an `Int`, like so: {{{ Prelude> 0xdc36d1615b7400a4 :: Int :2:1: Warning: Literal 15868100553162883236 is out of the Int range -9223372036854775808..9223372036854775807 -2578643520546668380 }}} However the compiler complains because of the wrap-around. I feel this is common enough and practice (and perfectly well-defined) that the compiler shouldn't warn. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 15:58:03 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 15:58:03 -0000 Subject: [GHC] #9854: Literal overflow check is too aggressive In-Reply-To: <044.0949ac05531a8c6732f39a917c7dcb0f@haskell.org> References: <044.0949ac05531a8c6732f39a917c7dcb0f@haskell.org> Message-ID: <059.c5f3ef2067af724d58a699ba23fcbe26@haskell.org> #9854: Literal overflow check is too aggressive -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by tibbe): According to @hvr gcc allows this kind of signed/unsigned overflow with -Woverflow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 16:06:40 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 16:06:40 -0000 Subject: [GHC] #9854: Literal overflow check is too aggressive In-Reply-To: <044.0949ac05531a8c6732f39a917c7dcb0f@haskell.org> References: <044.0949ac05531a8c6732f39a917c7dcb0f@haskell.org> Message-ID: <059.649b23896b7b0b56164c08d8f76a47f3@haskell.org> #9854: Literal overflow check is too aggressive -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: warning at compile-time | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * failure: None/Unknown => Incorrect warning at compile-time Comment: For reference: `-fwarn-overflowed-literals` was added in #7895. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 16:37:13 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 16:37:13 -0000 Subject: [GHC] #3094: Some GHC.* module should export word size and heap object header size In-Reply-To: <045.907bdf02870cf9d7a457cb5fba873bca@haskell.org> References: <045.907bdf02870cf9d7a457cb5fba873bca@haskell.org> Message-ID: <060.1ecb4aa2de85e35cf9bca68890b4c465@haskell.org> #3094: Some GHC.* module should export word size and heap object header size -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: libraries | Version: 6.10.1 (other) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: closed => new * failure: => None/Unknown * resolution: fixed => Comment: GHC.Constants doesn't export anything at the moment, but there's a comment that says: {{{ -- TODO: This used to include HaskellConstants.hs, but that has now gone. -- We probably want to include the constants in platformConstants somehow -- instead. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 16:45:20 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 16:45:20 -0000 Subject: [GHC] #3701: allow existential wrapper newtypes In-Reply-To: <045.840f456f2d890bcf682319446631153e@haskell.org> References: <045.840f456f2d890bcf682319446631153e@haskell.org> Message-ID: <060.b2a78f800292f0bc452a1095e7969f15@haskell.org> #3701: allow existential wrapper newtypes -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: low | Version: 6.10.4 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * difficulty: => Unknown * component: Compiler => Compiler (Type checker) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 16:50:34 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 16:50:34 -0000 Subject: [GHC] #3699: Wildcards in type functions In-Reply-To: <060.b01af1dc1c462193a392550aa45e1d6c@haskell.org> References: <060.b01af1dc1c462193a392550aa45e1d6c@haskell.org> Message-ID: <075.1aade50c7dc5cb5c2ce90f4633c22462@haskell.org> #3699: Wildcards in type functions -------------------------------------+------------------------------------- Reporter: | Owner: MartijnVanSteenbergen | Status: new Type: feature | Milestone: 7.10.1 request | Version: 6.10.4 Priority: low | Keywords: Component: Compiler | Architecture: Unknown/Multiple (Type checker) | Difficulty: Unknown Resolution: | Blocked By: Operating System: | Related Tickets: Unknown/Multiple | Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * difficulty: => Unknown * component: Compiler => Compiler (Type checker) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 16:51:40 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 16:51:40 -0000 Subject: [GHC] #9818: Add `Natural` number type to `base` In-Reply-To: <042.8652fbefbb96a94879b1f06096e9b13e@haskell.org> References: <042.8652fbefbb96a94879b1f06096e9b13e@haskell.org> Message-ID: <057.20a87bf44244576fecd46fb31cae5fee@haskell.org> #9818: Add `Natural` number type to `base` -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: Component: Core | Keywords: base natural Libraries | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #3650 #9281 Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D473 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"6b063ef2a1f68290b51778a38e9b89b6fec5e170/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="6b063ef2a1f68290b51778a38e9b89b6fec5e170" Make Natural's (.|.) really an OR operation (#9818) Currently it's an AND when at least one of the operands is big. Reviewed By: hvr Differential Revision: https://phabricator.haskell.org/D549 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 16:54:10 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 16:54:10 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICM5MjQwOiAicmVhZCAuIHNob3cg4omhIGlkIiBu?= =?utf-8?q?ot_satisfied_by_Data=2EFixed?= In-Reply-To: <042.bb0c4150424061c49087c6a88d193db3@haskell.org> References: <042.bb0c4150424061c49087c6a88d193db3@haskell.org> Message-ID: <057.986bc45ee56d79a898946898fdddf407@haskell.org> #9240: "read . show ? id" not satisfied by Data.Fixed -------------------------------------+------------------------------------- Reporter: hvr | Owner: ekmett Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.2.1 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #9231 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D547 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"7c38e985aa211ca44039c6d1db9fa13690749c59/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="7c38e985aa211ca44039c6d1db9fa13690749c59" Make `read . show = id` for Data.Fixed (fix #9240) The QuickCheck property now succeeds: prop :: Fixed B7 -> Bool prop a = read (show a) == a This changes the Show instance for Fixed to round up, rather than down when calculating a digit. This needs to happen because Read also rounds down: data B7 instance HasResolution B7 where resolution _ = 128 1 / 128 = 0.0078125 read "0.007" = (0.000 :: Fixed B7) Here is an example of the change to Show: showFixed False (0.009 :: Fixed B7) -- Broken: "0.007" -- Fixed: "0.008" And now Read can continue to round down: read "0.008" = (0.0078125 :: Fixed B7) Reviewed By: hvr, ekmett Differential Revision: https://phabricator.haskell.org/D547 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 16:56:00 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 16:56:00 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICM5MjQwOiAicmVhZCAuIHNob3cg4omhIGlkIiBu?= =?utf-8?q?ot_satisfied_by_Data=2EFixed?= In-Reply-To: <042.bb0c4150424061c49087c6a88d193db3@haskell.org> References: <042.bb0c4150424061c49087c6a88d193db3@haskell.org> Message-ID: <057.2d78b3e3d49251cf50195c9d6ea37a05@haskell.org> #9240: "read . show ? id" not satisfied by Data.Fixed -------------------------------------+------------------------------------- Reporter: hvr | Owner: ekmett Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.2.1 Libraries | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #9231 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D547 | -------------------------------------+------------------------------------- Changes (by hvr): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 17:08:03 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 17:08:03 -0000 Subject: [GHC] #3645: Layout and pragmas In-Reply-To: <044.fddd9f8ae2f17ca6ebff5e268d132ce9@haskell.org> References: <044.fddd9f8ae2f17ca6ebff5e268d132ce9@haskell.org> Message-ID: <059.18775f367a63b0cd92612725a5c14058@haskell.org> #3645: Layout and pragmas -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: low | Version: 6.10.4 Component: Compiler | Keywords: (Parser) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): #5401 is a duplicate of this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 17:08:47 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 17:08:47 -0000 Subject: [GHC] #5401: LANGUAGE pragma parser nit In-Reply-To: <042.ae92bdd8a2d3bac0338a8b988fbf5876@haskell.org> References: <042.ae92bdd8a2d3bac0338a8b988fbf5876@haskell.org> Message-ID: <057.1ea4fd1d24e14a3fa5ab111e06e4605b@haskell.org> #5401: LANGUAGE pragma parser nit -------------------------------------+------------------------------------- Reporter: nwf | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 (Parser) | Keywords: Resolution: duplicate | Architecture: x86_64 (amd64) Operating System: Linux | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: #3645 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #3645 * milestone: 7.10.1 => Comment: This is a duplicate of #3645. That ticket has more discussion already. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 17:33:05 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 17:33:05 -0000 Subject: [GHC] #3625: GHCI doesn't work with dtrace on OS X In-Reply-To: <041.efc4099a4816c68174bfd27196e4a151@haskell.org> References: <041.efc4099a4816c68174bfd27196e4a151@haskell.org> Message-ID: <056.eb762b8f6ab78e6d5acb5137a8234775@haskell.org> #3625: GHCI doesn't work with dtrace on OS X -------------------------------------+------------------------------------- Reporter: rl | Owner: Type: bug | Status: closed Priority: low | Milestone: 7.10.1 Component: GHCi | Version: 6.10.4 Resolution: worksforme | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: | Difficulty: Unknown None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => worksforme Comment: Replying to [comment:11 lelf]: > {{{ > Betty:cbits lelf$ sudo dtrace -i 'demo- trace{printf("%s",copyinstr(arg0))}' > dtrace: description 'demo-trace' matched 1 probe > CPU ID FUNCTION:NAME > 0 2547 demo_trace:demo-trace rzzzz > 1 2547 demo_trace:demo-trace foo > 0 2547 demo_trace:demo-trace bar > 0 2547 demo_trace:demo-trace bzzzzz > }}} > > Seems to work Please re-open if there's still a problem with dtrace on OS X. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 18:01:59 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 18:01:59 -0000 Subject: [GHC] #3557: CPU Vector instructions in GHC.Prim In-Reply-To: <044.db8b087837e05fdd9a6c4304c2acd80c@haskell.org> References: <044.db8b087837e05fdd9a6c4304c2acd80c@haskell.org> Message-ID: <059.d81d001a519a7a621fc1d3cb5df647a7@haskell.org> #3557: CPU Vector instructions in GHC.Prim -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: feature | Status: new request | Milestone: ? Priority: normal | Version: 6.11 Component: Data | Keywords: Parallel Haskell | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: Runtime | performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * failure: None/Unknown => Runtime performance bug * component: Compiler (NCG) => Data Parallel Haskell -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 19:30:13 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 19:30:13 -0000 Subject: [GHC] #3533: mac installer package deletes old version of ghc In-Reply-To: <068.c01b30dc01c8d35f26692e95513280f4@haskell.org> References: <068.c01b30dc01c8d35f26692e95513280f4@haskell.org> Message-ID: <083.b3d48369833f6d690227bb499545ebed@haskell.org> #3533: mac installer package deletes old version of ghc -------------------------------------+------------------------------------- Reporter: | Owner: malcolm.wallace@? | Status: new Type: bug | Milestone: 7.10.1 Priority: lowest | Version: 6.10.4 Component: Build | Keywords: System | Architecture: x86 Resolution: | Difficulty: Unknown Operating System: MacOS X | Blocked By: Type of failure: Installing | Related Tickets: GHC failed | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * failure: => Installing GHC failed * component: Compiler => Build System -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 19:40:48 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 19:40:48 -0000 Subject: [GHC] #3517: GHC has lots of extra hidden IOErrorType values In-Reply-To: <045.81ae8140396d0673beafa7c1c19d5515@haskell.org> References: <045.81ae8140396d0673beafa7c1c19d5515@haskell.org> Message-ID: <060.3adf367cf6e523b09a94f7559146de8f@haskell.org> #3517: GHC has lots of extra hidden IOErrorType values -------------------------------------+------------------------------------- Reporter: duncan | Owner: ekmett Type: bug | Status: closed Priority: low | Milestone: Component: Core | Version: Libraries | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: core-libraries-committee@? (added) * status: new => closed * resolution: => fixed * milestone: 7.10.1 => Comment: > Ideally we would be moving to an extensible exception hierarchy, of course. This has happened. Please re-open if there's still a problem here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 19:42:38 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 19:42:38 -0000 Subject: [GHC] #3541: Allow local foreign imports In-Reply-To: <044.f182d5c0327086f8b5193630cf333bb0@haskell.org> References: <044.f182d5c0327086f8b5193630cf333bb0@haskell.org> Message-ID: <059.6574cfa367ee9db53f6ccf4392b6d724@haskell.org> #3541: Allow local foreign imports -------------------------------------+------------------------------------- Reporter: mokus | Owner: Type: feature | Status: new request | Milestone: ? Priority: normal | Version: 6.10.4 Component: Compiler | Keywords: newcomer (FFI) | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less Operating System: | than a day) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * keywords: => newcomer * failure: => None/Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 19:49:20 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 19:49:20 -0000 Subject: [GHC] #3483: Some mechanism for eliminating "absurd" patterns In-Reply-To: <044.05fb1984acc37eefec1ed6383058af74@haskell.org> References: <044.05fb1984acc37eefec1ed6383058af74@haskell.org> Message-ID: <059.26b23684469d444e62e1b8a155fc895e@haskell.org> #3483: Some mechanism for eliminating "absurd" patterns -------------------------------------+------------------------------------- Reporter: ryani | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: low | Version: 6.10.4 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: goldfire (added) * failure: => None/Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 20:00:01 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 20:00:01 -0000 Subject: [GHC] #3517: GHC has lots of extra hidden IOErrorType values In-Reply-To: <045.81ae8140396d0673beafa7c1c19d5515@haskell.org> References: <045.81ae8140396d0673beafa7c1c19d5515@haskell.org> Message-ID: <060.c15bacb04f7964917494628d16e5274b@haskell.org> #3517: GHC has lots of extra hidden IOErrorType values -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Core | Version: Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * owner: ekmett => * status: closed => new * resolution: fixed => Comment: Yuras > thomie: (re #3517) But InvalidArgument is still not exported Yuras > and there is a number of other ghc-specific types Yuras > also, http://stackoverflow.com/questions/17363277/haskell- catching-low-level-io-exceptions/17363433#17363433 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 20:08:49 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 20:08:49 -0000 Subject: [GHC] #3557: CPU Vector instructions in GHC.Prim In-Reply-To: <044.db8b087837e05fdd9a6c4304c2acd80c@haskell.org> References: <044.db8b087837e05fdd9a6c4304c2acd80c@haskell.org> Message-ID: <059.b2a58b93ecd47cf5a1dbef2091fc01a4@haskell.org> #3557: CPU Vector instructions in GHC.Prim -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: feature | Status: new request | Milestone: ? Priority: normal | Version: 6.11 Component: Data | Keywords: Parallel Haskell | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: Runtime | performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): Theres some basic simd in GHC.Prim today, but its only usable via the -fllvm backend, and the design as is, is unsuitable for supporting on the NCG. I think we'll have to rework those apis to have a sane story of supporting operations on both ncg and llvm. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 20:18:39 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 20:18:39 -0000 Subject: [GHC] #3517: GHC has lots of extra hidden IOErrorType values In-Reply-To: <045.81ae8140396d0673beafa7c1c19d5515@haskell.org> References: <045.81ae8140396d0673beafa7c1c19d5515@haskell.org> Message-ID: <060.b1114a437cc85d65582105cb0db8af99@haskell.org> #3517: GHC has lots of extra hidden IOErrorType values -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: feature | Status: new request | Milestone: Priority: low | Version: Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * type: bug => feature request -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 20:25:36 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 20:25:36 -0000 Subject: [GHC] #8984: Improve output of failed GeneralizedNewtypeDeriving coercion due to type roles In-Reply-To: <044.9146c0f21c1d5c0ac4fad078a63640bb@haskell.org> References: <044.9146c0f21c1d5c0ac4fad078a63640bb@haskell.org> Message-ID: <059.0479021f03b65d1da3a669e9544909db@haskell.org> #8984: Improve output of failed GeneralizedNewtypeDeriving coercion due to type roles -------------------------------------+------------------------------------- Reporter: haasn | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.1 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): With my update to the solver (preview available at http://github.com/goldfirere/ghc, `wip/rae-new-coercible` branch), the new error message is thus: {{{ T8984.hs:7:46: Couldn't match representation of type ?cat a (N cat a Int)? with that of ?cat a (cat a Int)? arising from the coercion of the method ?app? from type ?cat a (cat a Int)? to type ?N cat a (N cat a Int)? Relevant role signatures: type role N representational nominal nominal NB: We cannot know what roles the parameters to ?cat a? have; we must assume that the role is nominal When deriving the instance for (C (N cat a)) }}} I like it, and will close this ticket when I merge. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 20:27:14 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 20:27:14 -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.69ecdff5ff78ad57dfb8d06031764020@haskell.org> #8548: Coercible does not resolve type family application -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 (Type checker) | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #8503 None/Unknown | Test Case: | typecheck/should_run/TcCoercible | Blocking: 8503 | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by goldfire): * testcase: => typecheck/should_run/TcCoercible -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 20:29:23 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 20:29:23 -0000 Subject: [GHC] #9444: -ddump-deriv doesn't dump failed newtype-deriving In-Reply-To: <047.065b5f6e6b688bb61818111621ae3bb4@haskell.org> References: <047.065b5f6e6b688bb61818111621ae3bb4@haskell.org> Message-ID: <062.e902fbf6f228e17c7ca571f990896dc5@haskell.org> #9444: -ddump-deriv doesn't dump failed newtype-deriving -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: invalid | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => invalid Comment: Never mind -- closing this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 20:29:39 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 20:29:39 -0000 Subject: [GHC] #3462: New codegen: allocate large objects using allocateLocal() In-Reply-To: <047.2cff8925cc83a1acf5acaf53c93372b6@haskell.org> References: <047.2cff8925cc83a1acf5acaf53c93372b6@haskell.org> Message-ID: <062.62c129ac689d0788e99e61768360718c@haskell.org> #3462: New codegen: allocate large objects using allocateLocal() -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: low | Milestone: 7.10.1 Component: Runtime | Version: 6.11 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: 4258 Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: simonmar (added) * failure: None/Unknown => Runtime performance bug * component: Compiler => Runtime System * owner: => simonmar Comment: Commit 5270423a6afe69f1dc57e5e5a474812182718d40: {{{ Author: Simon Marlow <> Date: Tue Dec 1 16:03:21 2009 +0000 ... - allocateLocal() now allocates large objects into the local nursery, rather than taking a global lock and allocating then in gen 0 step 0. ... - I removed the global allocate() function, and renamed allocateLocal() to allocate(). ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 20:32:42 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 20:32:42 -0000 Subject: [GHC] #9117: Coercible constraint solver misses one In-Reply-To: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> References: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> Message-ID: <062.66b1cc14e21e417218cc16a72769d869@haskell.org> #9117: Coercible constraint solver misses one -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D546 | -------------------------------------+------------------------------------- Changes (by goldfire): * differential: => Phab:D546 Comment: I've written a new solver for `Coercible`. It is able to solve for all the cases considered in this ticket. However, this comes at the cost of essentially ditching support for pathologically recursive newtypes (like `Fix`, or `newtype Loop = Loop Loop`). I think this exchange is a solid win. Still working out the final bugs; will set to "patch" when those are done. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 20:41:08 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 20:41:08 -0000 Subject: [GHC] #9855: Harbormaster uses the wrong code sometimes Message-ID: <047.61efb9a68539ef2087ae691f0063c38a@haskell.org> #9855: Harbormaster uses the wrong code sometimes -------------------------------------+------------------------------------- Reporter: goldfire | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Harbormaster sometimes uses an inconsistent codebase for building, and then reports spurious build errors. A specific example is [https://phabricator.haskell.org/harbormaster/build/2444/ here]. The line where the error is reported is correct in the Differential view, but somehow Harbormaster is confused. Even stranger, this particular error could result only if ''part'' of a file were out-of-date. Something somewhere is trying to be awfully clever and failing. I know that sometimes I have deviated from any recommended Phab workflow. I attest that, to the best of my knowledge, I have not done so with this patch. It is based off my `origin/master`, and I have done no rebasing since posting on Phab. I have not pushed to the central GHC repo, but that doesn't appear to be necessary. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 21:11:49 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 21:11:49 -0000 Subject: [GHC] #3458: Allocation where none should happen In-Reply-To: <044.0be4f1c62ed65da810608cbf23db2085@haskell.org> References: <044.0be4f1c62ed65da810608cbf23db2085@haskell.org> Message-ID: <059.19601bac096c4551ba9de42517359861@haskell.org> #3458: Allocation where none should happen -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: lowest | Milestone: 7.10.1 Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: #1216, #5945, Test Case: | #6040 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * failure: None/Unknown => Runtime performance bug * os: Linux => Unknown/Multiple * architecture: x86_64 (amd64) => Unknown/Multiple * related: => #1216, #5945, #6040 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 21:18:39 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 21:18:39 -0000 Subject: [GHC] #3447: Class restrictions on type instances In-Reply-To: <048.c99d50265c5dd4c44f2bab6be9ab501e@haskell.org> References: <048.c99d50265c5dd4c44f2bab6be9ab501e@haskell.org> Message-ID: <063.21e2ed6390f55e7f33f111bbea3a1c29@haskell.org> #3447: Class restrictions on type instances -------------------------------------+------------------------------------- Reporter: LysikovVV | Owner: Type: feature | Status: new request | Milestone: ? Priority: normal | Version: 6.10.4 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * failure: => None/Unknown * component: Compiler => Compiler (Type checker) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 21:28:14 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 21:28:14 -0000 Subject: [GHC] #3427: control what sort of entity a deprecated pragma applies to In-Reply-To: <044.6e5c26a8435c2fcde3f9de3ab4769428@haskell.org> References: <044.6e5c26a8435c2fcde3f9de3ab4769428@haskell.org> Message-ID: <059.aa4bb2aeb3475969694be65c84e1a3fb@haskell.org> #3427: control what sort of entity a deprecated pragma applies to -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: low | Version: 6.10.4 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * failure: => None/Unknown * type: bug => feature request -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 21:33:54 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 21:33:54 -0000 Subject: [GHC] #3373: GHC API is not thread safe In-Reply-To: <049.05da201065b7c5ade7dcf13301c3e81b@haskell.org> References: <049.05da201065b7c5ade7dcf13301c3e81b@haskell.org> Message-ID: <064.543913a1ab5eb4b7190602bd16296c6f@haskell.org> #3373: GHC API is not thread safe -------------------------------------+------------------------------------- Reporter: jcpetruzza | Owner: Type: bug | Status: new Priority: low | Milestone: 7.10.1 Component: GHC API | Version: Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * type: feature request => bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 21:40:28 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 21:40:28 -0000 Subject: [GHC] #3321: -fhpc assumes original sources relative to the current directory In-Reply-To: <045.e36e70091ef09c2231ae7feacc97785c@haskell.org> References: <045.e36e70091ef09c2231ae7feacc97785c@haskell.org> Message-ID: <060.400213cc4535643ddf4e08119bb8d220@haskell.org> #3321: -fhpc assumes original sources relative to the current directory -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: lowest | Milestone: 7.10.1 Component: Code | Version: 6.10.1 Coverage | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * failure: => None/Unknown * component: Compiler => Code Coverage -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 2 23:03:10 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Dec 2014 23:03:10 -0000 Subject: [GHC] #9855: Harbormaster uses the wrong code sometimes In-Reply-To: <047.61efb9a68539ef2087ae691f0063c38a@haskell.org> References: <047.61efb9a68539ef2087ae691f0063c38a@haskell.org> Message-ID: <062.ae07d90f59189c57ddc841fb8751a327@haskell.org> #9855: Harbormaster uses the wrong code sometimes -------------------------------------+------------------------------------- Reporter: goldfire | Owner: thoughtpolice Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by hvr): * owner: hvr => thoughtpolice -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 3 00:27:38 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Dec 2014 00:27:38 -0000 Subject: [GHC] #9142: LLVM 3.5.0 rejects aliases used by LLVM codegen In-Reply-To: <046.897d054798b2596bcd97c79499f7bfeb@haskell.org> References: <046.897d054798b2596bcd97c79499f7bfeb@haskell.org> Message-ID: <061.02baf1a421f7b72c4814e4ef905ddf02@haskell.org> #9142: LLVM 3.5.0 rejects aliases used by LLVM codegen -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: 4213 | Differential Revisions: Phab:D155 | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed Comment: Replying to [comment:29 nomeata]: > Is this something that will be merged into 7.8? (I?m not sure if Debian has llvm-3.4 around for as long as we will have 7.8 around.) The commit didn't make it into the 7.8.4 release candidate, so I guess not. From skimming Phab:D155, I get the impression this issue is fixed and tested. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 3 08:30:55 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Dec 2014 08:30:55 -0000 Subject: [GHC] #9856: Test suite regressions due to integer-gmp2 Message-ID: <046.46e84cf4a8b5d1f50db00f57d7053a13@haskell.org> #9856: Test suite regressions due to integer-gmp2 -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: prof-doc- | fib linker_unload | Blocking: | Differential Revisions: Phab:D82 -------------------------------------+------------------------------------- According to my performance builders, changeset:c774b28/ghc (Phab:D82) caused prof-doc-fib and linker_unload to fail on both performance builders (Ubuntu 13.10 and Ubuntu 14.04): {{{ Wrong exit code (expected 0 , actual 2 ) Stdout: Stderr: linker_unload: /home/nomeata/logs/ghc-tmp-REV/libraries/integer-gmp2/dist- install/build/libHSinteg_21cuTlnn00eFNd4GMrxOMi.a: unknown symbol `__gmpn_rshift' linker_unload: resolveObjs failed make[3]: *** [linker_unload] Error 1 *** unexpected failure for linker_unload(normal) }}} and {{{ Actual prof output differs from expected: --- ./profiling/should_run/prof-doc-fib.prof.sample 2014-12-01 15:30:19.000000000 +0100 +++ ./profiling/should_run/prof-doc-fib.prof 2014-12-01 15:56:08.000000000 +0100 @@ -1,9 +1,9 @@ - Thu Oct 27 09:29 2011 Time and Allocation Profiling Report (Final) + Mon Dec 1 15:56 2014 Time and Allocation Profiling Report (Final) - fib +RTS -p -RTS + prof-doc-fib +RTS -hc -p -RTS - total time = 0.76 secs (38 ticks @ 20 ms) - total alloc = 247,940,020 bytes (excludes profiling overheads) + total time = 0.14 secs (135 ticks @ 1000 us, 1 processor) + total alloc = 107,829,304 bytes (excludes profiling overheads) COST CENTRE MODULE %time %alloc @@ -13,13 +13,16 @@ individual inherited COST CENTRE MODULE no. entries %time %alloc %time %alloc -MAIN MAIN 102 0 0.0 0.0 100.0 100.0 - CAF Main 203 0 0.0 0.0 100.0 100.0 - main Main 204 1 0.0 0.0 100.0 100.0 - main.g Main 207 1 0.0 0.0 0.0 0.1 - fib Main 208 1973 0.0 0.1 0.0 0.1 - main.f Main 205 1 0.0 0.0 100.0 99.9 - fib Main 206 2692537 100.0 99.9 100.0 99.9 - CAF GHC.Conc.Signal 201 0 0.0 0.0 0.0 0.0 - CAF GHC.IO.Encoding.Iconv 191 0 0.0 0.0 0.0 0.0 - CAF GHC.IO.Handle.FD 183 0 0.0 0.0 0.0 0.0 +MAIN MAIN 45 0 0.0 0.0 100.0 100.0 + main Main 91 0 0.0 0.0 0.0 0.0 + CAF Main 89 0 0.0 0.0 100.0 100.0 + main Main 90 1 0.0 0.0 100.0 100.0 + main.f Main 94 1 0.0 0.0 100.0 99.9 + fib Main 95 2692537 100.0 99.9 100.0 99.9 + main.g Main 92 1 0.0 0.0 0.0 0.1 + fib Main 93 1973 0.0 0.1 0.0 0.1 + CAF GHC.IO.Handle.Text 86 0 0.0 0.0 0.0 0.0 + CAF GHC.IO.Handle.FD 82 0 0.0 0.0 0.0 0.0 + CAF GHC.Conc.Signal 78 0 0.0 0.0 0.0 0.0 + CAF GHC.IO.Encoding 76 0 0.0 0.0 0.0 0.0 + CAF GHC.IO.Encoding.Iconv 75 0 0.0 0.0 0.0 0.0 *** unexpected failure for prof-doc-fib(profasm) }}} The former is also observed by SPJ. The latter actually looks less like a regression, and more an improvement ? maybe Herbert simply did not run a profiled version when updating test results? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 3 08:47:57 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Dec 2014 08:47:57 -0000 Subject: [GHC] #9856: Test suite regressions due to integer-gmp2 In-Reply-To: <046.46e84cf4a8b5d1f50db00f57d7053a13@haskell.org> References: <046.46e84cf4a8b5d1f50db00f57d7053a13@haskell.org> Message-ID: <061.6d405f7681cb4d9203390f55102eda34@haskell.org> #9856: Test suite regressions due to integer-gmp2 -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: prof-doc- | fib linker_unload | Blocking: | Differential Revisions: Phab:D82 | -------------------------------------+------------------------------------- Comment (by hvr): Replying to [ticket:9856 nomeata]: > maybe Herbert simply did not run a profiled version when updating test results? ...if `./validate` doesn't run a profiled version, then I probably never ran the tests w/ a profiled version... :-/ How do I perform a profiled testsuite run? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 3 09:33:48 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Dec 2014 09:33:48 -0000 Subject: [GHC] #9856: Test suite regressions due to integer-gmp2 In-Reply-To: <046.46e84cf4a8b5d1f50db00f57d7053a13@haskell.org> References: <046.46e84cf4a8b5d1f50db00f57d7053a13@haskell.org> Message-ID: <061.f408dee125c9bcb742fa2bea22d46742@haskell.org> #9856: Test suite regressions due to integer-gmp2 -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: prof-doc- | fib linker_unload | Blocking: | Differential Revisions: Phab:D82 | -------------------------------------+------------------------------------- Comment (by nomeata): I?m never sure about the zoo of possible combinations. ghcspeed, for instance, has these settings: {{{ echo 'GhcLibWays := $(filter v dyn,$(GhcLibWays))' >> mk/build.mk echo 'GhcLibHcOpts += -O -dcore-lint' >> mk/build.mk echo 'GhcStage2HcOpts += -O -dcore-lint' >> mk/build.mk }}} which tires to match the validate settings, but I notice it leaves out `p` (which `validate` does not). It also only calls `make -C testsuite fast`. This leaves me confused how it could run `prof-doc-fib` at all. Maybe it?s because I run `perl boot` before creating `mk/build.mk`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 3 11:27:03 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Dec 2014 11:27:03 -0000 Subject: [GHC] #9857: GHC 7.9 panics (simplifier ticks exhausted) on `half-0.2` Message-ID: <042.3b1974ccb36d315c778a524393b08ca5@haskell.org> #9857: GHC 7.9 panics (simplifier ticks exhausted) on `half-0.2` -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Compile- Blocked By: | time crash Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Compiling hackage:half-0.2 results in a GHC Panic: {{{ $ ghc --version && ghc --print-project-git-commit-id The Glorious Glasgow Haskell Compilation System, version 7.9.20141202 bf2d75417b5be7e8a79a26ee57a81e00682dabd4 $ cabal get half-0.2 && cd half-0.2/src/Numeric/ Unpacking to half-0.2/ $ ghc -Wall -O -fforce-recomp -c Half.hs ghc: panic! (the 'impossible' happened) (GHC version 7.9.20141202 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone lvl_s5yo To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 125160 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 3 11:39:03 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Dec 2014 11:39:03 -0000 Subject: [GHC] #7109: Inlining depends on datatype size, even with INLINE pragmas In-Reply-To: <046.d7688d63b8d11652e4d6ca8d86579926@haskell.org> References: <046.d7688d63b8d11652e4d6ca8d86579926@haskell.org> Message-ID: <061.f632c2452b811cd779ef099e323db5c5@haskell.org> #7109: Inlining depends on datatype size, even with INLINE pragmas -------------------------------------+------------------------------------- Reporter: dreixel | Owner: simonpj Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Replying to [comment:5 dreixel]: > I don't know how to tell GHC that it shouldn't be afraid of inlining stuff just because the terms are bigger. Well that's precisely what INLINE pragmas are for. But you know that, so you must mean something else. Pedro, can you be more precise/specific about how to reproduce the problem you are concerned about (perhaps `ghc -O Bug3.hs -ddump-simpl`? I assume you are going to say "I put an INLINE pragma here, but it doesn't work" or something like that. Fine! The more specific you can be, the better chance I have to understand and help. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 3 11:40:32 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Dec 2014 11:40:32 -0000 Subject: [GHC] #9857: GHC 7.9 panics (simplifier ticks exhausted) on `half-0.2` In-Reply-To: <042.3b1974ccb36d315c778a524393b08ca5@haskell.org> References: <042.3b1974ccb36d315c778a524393b08ca5@haskell.org> Message-ID: <057.ee07591b256874061a339c2dd538215a@haskell.org> #9857: GHC 7.9 panics (simplifier ticks exhausted) on `half-0.2` -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by hvr): * priority: normal => high Comment: since this is actually a regression to 7.8, I'm increasing the priority to high -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 3 11:43:52 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Dec 2014 11:43:52 -0000 Subject: [GHC] #9032: Panic with self-import In-Reply-To: <048.b2b35b617fab282b73adc84f1bdd96f5@haskell.org> References: <048.b2b35b617fab282b73adc84f1bdd96f5@haskell.org> Message-ID: <063.153de1a7d728a2bec301d371fa676f8f@haskell.org> #9032: Panic with self-import -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Template | Version: 7.8.2 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Compile- | Related Tickets: #1012 time crash | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * priority: normal => highest Comment: I think a module should simply never import itself. I propose to make this an error. Does anyone object? I'm increasing the priority to highest to make sure that we attend to this, not because it's terribly important. It's very easy to implement if we agree that it should be illegal. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 3 11:44:37 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Dec 2014 11:44:37 -0000 Subject: [GHC] #9857: GHC 7.9 panics (simplifier ticks exhausted) on `half-0.2` In-Reply-To: <042.3b1974ccb36d315c778a524393b08ca5@haskell.org> References: <042.3b1974ccb36d315c778a524393b08ca5@haskell.org> Message-ID: <057.4fbcbdc4622f5abc3c926b253f580c97@haskell.org> #9857: GHC 7.9 panics (simplifier ticks exhausted) on `half-0.2` -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): What factor works? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 3 12:07:08 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Dec 2014 12:07:08 -0000 Subject: [GHC] #9857: GHC 7.9 panics (simplifier ticks exhausted) on `half-0.2` In-Reply-To: <042.3b1974ccb36d315c778a524393b08ca5@haskell.org> References: <042.3b1974ccb36d315c778a524393b08ca5@haskell.org> Message-ID: <057.6c266cb9d1bc885c2dd913e16aefe3cf@haskell.org> #9857: GHC 7.9 panics (simplifier ticks exhausted) on `half-0.2` -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by hvr): I've tried up to `-fsimpl-tick-factor=100000` and it still fails: {{{ $ ghc -Wall -O -fforce-recomp -fsimpl-tick-factor=100000 -c Half.hs ghc: panic! (the 'impossible' happened) (GHC version 7.9.20141202 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone lvl_s5yo To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 125160000 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} does it make sense to try even higher? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 3 12:30:22 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Dec 2014 12:30:22 -0000 Subject: [GHC] #9817: signal handlers in unix are passed garbage when using the signle threaded rts In-Reply-To: <045.646b26d4129c0e58f98ff89c628f56b1@haskell.org> References: <045.646b26d4129c0e58f98ff89c628f56b1@haskell.org> Message-ID: <060.f55b7659b5f5dd2b2df11a4454f3668b@haskell.org> #9817: signal handlers in unix are passed garbage when using the signle threaded rts -------------------------------------+------------------------------------- Reporter: redneb | Owner: simonmar Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime | Version: 7.8.3 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: POSIX | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D515 | -------------------------------------+------------------------------------- Comment (by redneb): Since there is going to be a 7.8.4 release, I think it makes sense to include my patch for that release as well. It is small, non-intrusive and solves a real issue with 7.8.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 3 13:00:43 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Dec 2014 13:00:43 -0000 Subject: [GHC] #3447: Class restrictions on type instances In-Reply-To: <048.c99d50265c5dd4c44f2bab6be9ab501e@haskell.org> References: <048.c99d50265c5dd4c44f2bab6be9ab501e@haskell.org> Message-ID: <063.25ce2bb453f40a3c834c7a4626402fea@haskell.org> #3447: Class restrictions on type instances -------------------------------------+------------------------------------- Reporter: LysikovVV | Owner: Type: feature | Status: closed request | Milestone: ? Priority: normal | Version: 6.10.4 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => fixed Comment: The original poster claims that algebraic datakinds, available since 7.4, solves the original problem. Although Conor's comment:7 is still very relevant, I'm not sure what is served by keeping this ticket open. I'm planning to address the issues in comment:7 in my dependent types branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 3 13:40:37 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Dec 2014 13:40:37 -0000 Subject: [GHC] #9729: GHCi accepts invalid programs when recompiling In-Reply-To: <047.be9ff38058adb3f22c9154bf2f7b59eb@haskell.org> References: <047.be9ff38058adb3f22c9154bf2f7b59eb@haskell.org> Message-ID: <062.13153d9f2c981f9b8d8d09e244f4ac84@haskell.org> #9729: GHCi accepts invalid programs when recompiling -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: accepts invalid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Edward is this fixed by your recent oprhan changes? SImon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 3 13:59:30 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Dec 2014 13:59:30 -0000 Subject: [GHC] #8894: Clean up `Coercible` plumbing In-Reply-To: <046.4ff81593c1e79cd88b8ae53f5e67a33a@haskell.org> References: <046.4ff81593c1e79cd88b8ae53f5e67a33a@haskell.org> Message-ID: <061.1ac2c9668ce0c95478ce1275281b9e83@haskell.org> #8894: Clean up `Coercible` plumbing -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: wontfix | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8904 Test Case: | Blocking: | Differential Revisions: Phab:D300 | -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => closed * resolution: => wontfix Comment: SPJ says at https://phabricator.haskell.org/D300#15193 that we probably won?t need this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 3 16:27:56 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Dec 2014 16:27:56 -0000 Subject: [GHC] #9858: Typeable instance for datatype and its promoted constructor is the same Message-ID: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> #9858: Typeable instance for datatype and its promoted constructor is the same -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- {{{ {-# LANGUAGE DataKinds #-} {-# LANGUAGE AutoDeriveTypeable #-} import Data.Typeable data A = A main = print $ typeRep (Proxy :: Proxy A) == typeRep (Proxy :: Proxy 'A) }}} This returns `True`, but it should return `False`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 3 16:28:08 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Dec 2014 16:28:08 -0000 Subject: [GHC] #9858: Typeable instance for datatype and its promoted constructor is the same In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.f38a402ce0a05efb0b0975290abdd1fa@haskell.org> #9858: Typeable instance for datatype and its promoted constructor is the same -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dreixel): * owner: => dreixel -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 3 17:07:02 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Dec 2014 17:07:02 -0000 Subject: [GHC] #3251: split rts headers into public and private In-Reply-To: <045.c36f62f5a06285c15ad56ab2ce446706@haskell.org> References: <045.c36f62f5a06285c15ad56ab2ce446706@haskell.org> Message-ID: <060.830eeb08c22fb0ab085b254456b312db@haskell.org> #3251: split rts headers into public and private -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: task | Status: new Priority: lowest | Milestone: 7.10.1 Component: Runtime | Version: 6.10.2 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: simonmar (added) * failure: => None/Unknown * type: feature request => task -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 3 17:37:37 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Dec 2014 17:37:37 -0000 Subject: [GHC] #3085: warn about language extensions that are not used In-Reply-To: <051.bedfbd02c24cc787d0bf163c67d17d1e@haskell.org> References: <051.bedfbd02c24cc787d0bf163c67d17d1e@haskell.org> Message-ID: <066.bb65e3be15e1514efe954b816480222c@haskell.org> #3085: warn about language extensions that are not used -------------------------------------+------------------------------------- Reporter: | Owner: PVerswyvelen | Status: new Type: feature | Milestone: 7.10.1 request | Version: 6.10.1 Priority: normal | Keywords: warnings Component: Compiler | extensions language Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #9757 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * related: => #9757 Comment: To cite rwbarton from #9757: > I think the purpose of compiler warnings should be to warn about code that is probably bad, not code that is probably fine that could be written in a (potentially) better way. (After all, we don't warn about excess parentheses in code either.) That is the domain of hlint, as Richard notes. Anyone disagree with a `wontfix` here as well? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 3 17:38:41 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Dec 2014 17:38:41 -0000 Subject: [GHC] #3205: Generalized isomorphic deriving In-Reply-To: <042.5465e02313ec0c86ef0c59c5b9869960@haskell.org> References: <042.5465e02313ec0c86ef0c59c5b9869960@haskell.org> Message-ID: <057.9117a804ff815027c060a79cf95d2950@haskell.org> #3205: Generalized isomorphic deriving -------------------------------------+------------------------------------- Reporter: ajd | Owner: Type: feature | Status: new request | Milestone: ? Priority: normal | Version: 6.10.2 Component: Compiler | Keywords: language Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * keywords: => language * failure: => None/Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 3 18:07:19 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Dec 2014 18:07:19 -0000 Subject: [GHC] #3191: hpc reports spurious results with .lhs files even after processing with ghc -E In-Reply-To: <046.d0fa4dbe587b61661696f46161cde9aa@haskell.org> References: <046.d0fa4dbe587b61661696f46161cde9aa@haskell.org> Message-ID: <061.d183f3538d686c2186298a1ae11df445@haskell.org> #3191: hpc reports spurious results with .lhs files even after processing with ghc -E -------------------------------------+------------------------------------- Reporter: dominic | Owner: andy@? Type: bug | Status: infoneeded Priority: lowest | Milestone: 7.10.1 Component: Code | Version: 6.10.2 Coverage | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => infoneeded * failure: => None/Unknown Comment: I cannot reproduce your problem, or I don't understand the problem description. > Even if I run them through the pre-processor (ghc -E) they still don't work What doesn't work? Do you see an error message, or maybe nothing happens at all? What are you trying to do? Please attach a small test program + instructions that demonstrate your problem. Here are some things I tried (same result with 7.8.3 as with 6.12.3): {{{ $ cat test.lhs > main = print "ok" $ ghc -E test.lhs $ cat test.hspp # The 2 inserted lines you mention {-# LINE 1 "test.lhs" #-} #line 1 "test.lhs" main = print "ok" $ ghc -fhpc -o test test.hspp $ ./test "ok" $ hpc report test 100% expressions used (0/0) 100% boolean coverage (0/0) 100% guards (0/0) 100% 'if' conditions (0/0) 100% qualifiers (0/0) 100% alternatives used (0/0) 100% local declarations used (0/0) 100% top-level declarations used (0/0) # Looks ok to me. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 3 18:16:24 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Dec 2014 18:16:24 -0000 Subject: [GHC] #3184: package.conf.d should be under /var, not /usr (was: package.conf should be under /var, not /usr) In-Reply-To: <044.f476a4a28c9761f9c30b392c86475e98@haskell.org> References: <044.f476a4a28c9761f9c30b392c86475e98@haskell.org> Message-ID: <059.d1e814e65c1a0be7342657610f0a34aa@haskell.org> #3184: package.conf.d should be under /var, not /usr -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: low | Milestone: 7.10.1 Component: Package | Version: 6.10.2 system | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Description changed by thomie: Old description: > fhs-2.3 says: > {{{ > /usr is the second major section of the filesystem. /usr is shareable, > read-only data. That means that /usr should be shareable between various > FHS-compliant hosts and must not be written to. Any information that is > host-specific or varies with time is stored elsewhere. > }}} > `package.conf` is not shareable, as different machines may have different > packages installed, so we should put it under /var instead. New description: fhs-2.3 says: {{{ /usr is the second major section of the filesystem. /usr is shareable, read-only data. That means that /usr should be shareable between various FHS-compliant hosts and must not be written to. Any information that is host-specific or varies with time is stored elsewhere. }}} `package.conf.d` is not shareable, as different machines may have different packages installed, so we should put it under /var instead. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 3 18:25:25 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Dec 2014 18:25:25 -0000 Subject: [GHC] #3085: warn about language extensions that are not used In-Reply-To: <051.bedfbd02c24cc787d0bf163c67d17d1e@haskell.org> References: <051.bedfbd02c24cc787d0bf163c67d17d1e@haskell.org> Message-ID: <066.5aaf4e3662237fde1b00540fb22809e2@haskell.org> #3085: warn about language extensions that are not used -------------------------------------+------------------------------------- Reporter: | Owner: PVerswyvelen | Status: new Type: feature | Milestone: 7.10.1 request | Version: 6.10.1 Priority: normal | Keywords: warnings Component: Compiler | extensions language Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #9757 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Lemming): Replying to [comment:33 thomie]: > To cite rwbarton from #9757: > > I think the purpose of compiler warnings should be to warn about code that is probably bad, not code that is probably fine that could be written in a (potentially) better way. (After all, we don't warn about excess parentheses in code either.) That is the domain of hlint, as Richard notes. > > Anyone disagree with a `wontfix` here as well? GHC already warns about unused variables and unused imports. Is the warning about unused instances much different? If you think, that the warning is not essential it may not be enabled by -Wall. And there are already non-Wall warnings that pointed me to bad code, like the warning about incomplete case analysis of pattern matches in lambda expressions. (I think it's `-fwarn-incomplete-uni-patterns`.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 3 18:37:38 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Dec 2014 18:37:38 -0000 Subject: [GHC] #9032: Panic with self-import In-Reply-To: <048.b2b35b617fab282b73adc84f1bdd96f5@haskell.org> References: <048.b2b35b617fab282b73adc84f1bdd96f5@haskell.org> Message-ID: <063.8458b3daba802ba61961abbd20014ea8@haskell.org> #9032: Panic with self-import -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Template | Version: 7.8.2 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Compile- | Related Tickets: #1012 time crash | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by monoidal): It's already an error (`Module imports form a cycle: module 'X' imports itself`), but in this case the self-import somehow gives a panic. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 3 18:51:20 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Dec 2014 18:51:20 -0000 Subject: [GHC] #3123: make INLINE work for recursive definitions (generalized loop peeling/loop unrolling) In-Reply-To: <044.a125e44de5957e50d259dfbe1a2d51e0@haskell.org> References: <044.a125e44de5957e50d259dfbe1a2d51e0@haskell.org> Message-ID: <059.7fe5d08a7bcc1fd33f33ebba3de2eb19@haskell.org> #3123: make INLINE work for recursive definitions (generalized loop peeling/loop unrolling) -------------------------------------+------------------------------------- Reporter: claus | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: lowest | Version: 6.11 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * failure: => Runtime performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 3 20:00:36 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Dec 2014 20:00:36 -0000 Subject: [GHC] #5850: Greater customization of GHCi prompt In-Reply-To: <050.bf03c3e2cbefdd0fabbaa545b275f2dc@haskell.org> References: <050.bf03c3e2cbefdd0fabbaa545b275f2dc@haskell.org> Message-ID: <065.15055bc2bb27c20d7800922728db43c0@haskell.org> #5850: Greater customization of GHCi prompt -------------------------------------+------------------------------------- Reporter: | Owner: jlengyel JamesFisher | Status: new Type: feature | Milestone: 7.10.1 request | Version: 7.4.1 Priority: normal | Keywords: newcomer Component: GHCi | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by jlengyel): * owner: => jlengyel -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 3 20:12:41 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Dec 2014 20:12:41 -0000 Subject: [GHC] #3085: warn about language extensions that are not used In-Reply-To: <051.bedfbd02c24cc787d0bf163c67d17d1e@haskell.org> References: <051.bedfbd02c24cc787d0bf163c67d17d1e@haskell.org> Message-ID: <066.3bfd03c5b1d90626a74c537a0196274e@haskell.org> #3085: warn about language extensions that are not used -------------------------------------+------------------------------------- Reporter: | Owner: PVerswyvelen | Status: new Type: feature | Milestone: 7.10.1 request | Version: 6.10.1 Priority: normal | Keywords: warnings Component: Compiler | extensions language Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #9757 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): Though it seems impossible to draw an obvious boundary between this idea and the one posed in #9757, I tend to think the warning proposed here ''does'' belong within the domain of GHC. I don't have an obvious way to implement this in mind, though, and I'm struggling to explain ''why'' I feel this is something GHC should do. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 3 20:46:31 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Dec 2014 20:46:31 -0000 Subject: [GHC] #9276: audit ghc floating point support for IEEE (non)compliance In-Reply-To: <045.ad291164c8d6795bec19bab0953045e8@haskell.org> References: <045.ad291164c8d6795bec19bab0953045e8@haskell.org> Message-ID: <060.84a70ac7ba5483bee54e16bc8c57361b@haskell.org> #9276: audit ghc floating point support for IEEE (non)compliance -------------------------------------+------------------------------------- Reporter: carter | Owner: carter Type: task | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: 3070, | 8364, 9304, 9530 | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by carter): * blocking: 8364, 9304, 9530 => 3070, 8364, 9304, 9530 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 3 21:08:54 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Dec 2014 21:08:54 -0000 Subject: [GHC] #3065: Reorder tests in quot to improve code In-Reply-To: <046.819ea32d4c70bd7d14e7ef168534bbea@haskell.org> References: <046.819ea32d4c70bd7d14e7ef168534bbea@haskell.org> Message-ID: <061.422464c7da154d2c9fec4d1b0078f583@haskell.org> #3065: Reorder tests in quot to improve code -------------------------------------+------------------------------------- Reporter: simonpj | Owner: ekmett Type: bug | Status: closed Priority: lowest | Milestone: 7.10.1 Component: Core | Version: 6.10.1 Libraries | Keywords: Resolution: duplicate | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: core-libraries-committee@? (added) * status: new => closed * resolution: => duplicate Comment: This is a duplicate of #5161, which was closed by these 2 commits: * 08db4daba1fdc14ae9647beec3f5162732a9cf4d {{{ Author: Denys Rtveliashvili <> Date: Thu Apr 28 08:45:10 2011 +0100 Performance improvement for division: got rid of an unnecessary branching in cases where the second argument is a constant and is not -1. }}} * 32038d8ba4039e153f966cacd0470a07157029e5 {{{ Author: Ian Lynagh <> Date: Sat Apr 30 15:52:57 2011 +0100 Add a note about the definition of quot etc Based on Simon PJ's text in #5161. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 3 21:18:21 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Dec 2014 21:18:21 -0000 Subject: [GHC] #3055: Int / Word / IntN / WordN are unequally optimized In-Reply-To: <044.1c39597802e7cddf9bd2ebc2460d51ee@haskell.org> References: <044.1c39597802e7cddf9bd2ebc2460d51ee@haskell.org> Message-ID: <059.63bad3e414dee685562fd07f1e046626@haskell.org> #3055: Int / Word / IntN / WordN are unequally optimized -------------------------------------+------------------------------------- Reporter: claus | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 6.11 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * priority: lowest => normal -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 3 22:31:49 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Dec 2014 22:31:49 -0000 Subject: [GHC] #9859: Implement `calloc{,Bytes,Array,Array0}` allocators Message-ID: <048.c0f4fa20de1f948bcce2872a450643e7@haskell.org> #9859: Implement `calloc{,Bytes,Array,Array0}` allocators -------------------------------------+------------------------------------- Reporter: ifesdjeen | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: 7.8.3 Keywords: ffi | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: D527 -------------------------------------+------------------------------------- Add zero-initialising versions of malloc{,Bytes,Array,Array0} * Add calloc and callocBytes to Foreign.Marshal.Alloc. * Add callocArray and callocArray0 to Foreign.Marshal.Array. Implemented in revision: [https://phabricator.haskell.org/D527] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 3 22:38:47 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Dec 2014 22:38:47 -0000 Subject: [GHC] #3085: warn about language extensions that are not used In-Reply-To: <051.bedfbd02c24cc787d0bf163c67d17d1e@haskell.org> References: <051.bedfbd02c24cc787d0bf163c67d17d1e@haskell.org> Message-ID: <066.c631cc09e2e10fa047495c4070a77ebe@haskell.org> #3085: warn about language extensions that are not used -------------------------------------+------------------------------------- Reporter: | Owner: PVerswyvelen | Status: new Type: feature | Milestone: 7.10.1 request | Version: 6.10.1 Priority: normal | Keywords: warnings Component: Compiler | extensions language Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #9757 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): I think it might be difficult, or at least tiresome, to implement this. In lots of places we test the language extension flags, to say {{{ if and not extn-flag then raise error }}} To implement this feature, every such test would need to look more like {{{ if then if then record extn-flag-needed else raise error }}} Presumably the "record extn-flag-needed" is some kind of mutable state carried in the monad, accumulating which extensions are used. I'm sure it's possible, but the are ''many'' such tests, so you'd have to touch a lot of code. Simonb -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 3 22:40:04 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Dec 2014 22:40:04 -0000 Subject: [GHC] #9859: Implement `calloc{, Bytes, Array, Array0}` allocators In-Reply-To: <048.c0f4fa20de1f948bcce2872a450643e7@haskell.org> References: <048.c0f4fa20de1f948bcce2872a450643e7@haskell.org> Message-ID: <063.f72050d15e4de00008f813c7b1ce6842@haskell.org> #9859: Implement `calloc{,Bytes,Array,Array0}` allocators -------------------------------------+------------------------------------- Reporter: ifesdjeen | Owner: Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: Component: Core | Keywords: ffi Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D527 | -------------------------------------+------------------------------------- Changes (by hvr): * status: new => patch * cc: core-libraries-committee@? (added) * differential: D527 => Phab:D527 * component: libraries/base => Core Libraries * version: 7.8.3 => Old description: > Add zero-initialising versions of malloc{,Bytes,Array,Array0} > > * Add calloc and callocBytes to Foreign.Marshal.Alloc. > * Add callocArray and callocArray0 to Foreign.Marshal.Array. > > Implemented in revision: [https://phabricator.haskell.org/D527] New description: Add zero-initialising versions of malloc{,Bytes,Array,Array0} * Add calloc and callocBytes to Foreign.Marshal.Alloc. * Add callocArray and callocArray0 to Foreign.Marshal.Array. Proposal Discussion: https://www.haskell.org/pipermail/libraries/2014-November/024421.html -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 4 10:26:52 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Dec 2014 10:26:52 -0000 Subject: [GHC] #3191: hpc reports spurious results with .lhs files even after processing with ghc -E In-Reply-To: <046.d0fa4dbe587b61661696f46161cde9aa@haskell.org> References: <046.d0fa4dbe587b61661696f46161cde9aa@haskell.org> Message-ID: <061.79f64a8672c835334ace87ae0a50ea1a@haskell.org> #3191: hpc reports spurious results with .lhs files even after processing with ghc -E -------------------------------------+------------------------------------- Reporter: dominic | Owner: andy@? Type: bug | Status: closed Priority: lowest | Milestone: 7.10.1 Component: Code | Version: 6.10.2 Coverage | Keywords: Resolution: worksforme | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dominic): * status: infoneeded => closed * resolution: => worksforme Comment: Thanks for looking at this. I had completely forgotten about this not surprisingly as it is 6 years old. I no longer have access to ghc 6.12.3 and if you can't reproduce then I am going to close it. I can always open a new ticket if need be. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 4 10:59:44 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Dec 2014 10:59:44 -0000 Subject: [GHC] #9032: Panic with self-import In-Reply-To: <048.b2b35b617fab282b73adc84f1bdd96f5@haskell.org> References: <048.b2b35b617fab282b73adc84f1bdd96f5@haskell.org> Message-ID: <063.77bd6263eb4ab46f808836df00dd0c4e@haskell.org> #9032: Panic with self-import -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Template | Version: 7.8.2 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Compile- | Related Tickets: #1012 time crash | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Replying to [comment:5 monoidal]: > It's already an error (`Module imports form a cycle: module 'X' imports itself`), but in this case the self-import somehow gives a panic. Good point. So it's already an error; albeit one that is only reported with `--make`. We should get a decent error in one-shot mode too. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 4 13:55:12 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Dec 2014 13:55:12 -0000 Subject: [GHC] #9860: Package flags not command line completable in 7.8 Message-ID: <047.2ed0a58d8a149996e6a01ade6d7be83d@haskell.org> #9860: Package flags not command line completable in 7.8 -------------------------------------+------------------------------------- Reporter: kolmodin | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Incorrect Blocked By: | result at runtime Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Passing `--show-options` to ghc shows all the flags that ghc understands. Unfortunately `--show-options` does not list the package flags, `-package- db -package-id` etc. Requires a 1 line fix in `ghc/Main.hs`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 4 14:58:29 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Dec 2014 14:58:29 -0000 Subject: [GHC] #9860: Package flags not command line completable in 7.8 In-Reply-To: <047.2ed0a58d8a149996e6a01ade6d7be83d@haskell.org> References: <047.2ed0a58d8a149996e6a01ade6d7be83d@haskell.org> Message-ID: <062.ba196b24cfccdc6160dd6a66703e93c4@haskell.org> #9860: Package flags not command line completable in 7.8 -------------------------------------+------------------------------------- Reporter: kolmodin | Owner: kolmodin Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D554 | -------------------------------------+------------------------------------- Changes (by kolmodin): * owner: => kolmodin * differential: => Phab:D554 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 4 16:26:44 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Dec 2014 16:26:44 -0000 Subject: [GHC] #9861: ghc readme provides out of date git clone directions Message-ID: <045.ee10b522121d648c9ddb8fa0d461111b@haskell.org> #9861: ghc readme provides out of date git clone directions -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: phab:D555 -------------------------------------+------------------------------------- as first pass to fixing this, i've put a patch up on phab -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 4 17:39:05 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Dec 2014 17:39:05 -0000 Subject: [GHC] #2991: .tix file generation broken with -fhpc and --make flags with lhs modules (was: .mix files generation broken with -fhpc and --make flags with lhs modules) In-Reply-To: <045.fbdf830be4083dc434ba708ecd719a55@haskell.org> References: <045.fbdf830be4083dc434ba708ecd719a55@haskell.org> Message-ID: <060.37fe36082ff72262633eba662080522f@haskell.org> #2991: .tix file generation broken with -fhpc and --make flags with lhs modules -------------------------------------+------------------------------------- Reporter: ppavel | Owner: andy@? Type: bug | Status: new Priority: lowest | Milestone: 7.10.1 Component: Code | Version: 6.10.1 Coverage | Keywords: hpc make lhs Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * failure: => None/Unknown Old description: > assume the project consisting of two files: !Main.lhs and !MyModule.hs. > Main.lhs imports !MyModule via standard import. Build the project with > > ghc --make -fhpc -o main Main.lhs > > The generated .mix file contains relevant information and hpc markup > correctly shows the coverage for !MyModule. > > Now rename !MyModule.hs to !MyModule.lhs and enclose the code there in > \begin{code} / \end{code}. Build again. The compilation still succeeds > and the executable works fine. But !MyModule.mix now seems wrong and no > hpc coverage information is available for !MyModule New description: Assume the project consisting of two files: Main.lhs and MyModule.hs. Main.lhs imports MyModule via standard import. Build the project with ghc --make -fhpc -o main Main.lhs The generated .tix file contains relevant information and hpc markup correctly shows the coverage for MyModule. Now rename MyModule.hs to MyModule.lhs and enclose the code there in \begin{code} / \end{code}. Build again. The compilation still succeeds and the executable works fine. But main.tix now seems wrong and no hpc coverage information is available for MyModule -- Comment: I can reproduce this with HEAD or 7.8.3. Make sure `MyModule.lhs` is not empty. {{{ $ cat Main.lhs \begin{code} import MyModule main = return () \end{code} $ cat MyModule.lhs \begin{code} module MyModule where foo = undefined \end{code} $ ghc --make -fhpc -o main Main.lhs [1 of 2] Compiling MyModule ( MyModule.lhs, MyModule.o ) [2 of 2] Compiling Main ( Main.lhs, Main.o ) Linking main ... $ ./main $ cat main.tix Tix [ TixModule "Main" 1204325935 3 [0,1,1], TixModule "MyModule" 1288191418 0 []] }}} Notice the `0 []` for "MyModule". That should be `2 [0,0]`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 4 17:48:24 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Dec 2014 17:48:24 -0000 Subject: [GHC] #2986: :info printing instances often isn't wanted In-Reply-To: <043.cc7348275a1e64e6491d1ee94042b0a6@haskell.org> References: <043.cc7348275a1e64e6491d1ee94042b0a6@haskell.org> Message-ID: <058.8ab1e0c5e7b93dd9a582e17d3ba02f1a@haskell.org> #2986: :info printing instances often isn't wanted -------------------------------------+------------------------------------- Reporter: Remi | Owner: Remi Type: feature | Status: new request | Milestone: 7.10.1 Priority: lowest | Version: 6.10.1 Component: GHCi | Keywords: :info instances Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: hvr (added) Comment: Replying to [comment:22 Remi]: > This is probably going to be the longest standing feature request ever, but half a year after losing the previous version of my patch I got around to creating a new one. Remi: do you have a link to your patch? Maybe someone else can finish it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 4 17:55:46 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Dec 2014 17:55:46 -0000 Subject: [GHC] #2926: Foreign exported function returns wrong type In-Reply-To: <044.765c94e2fb1a6e722be183eea512a2d3@haskell.org> References: <044.765c94e2fb1a6e722be183eea512a2d3@haskell.org> Message-ID: <059.8e131d38235274ce15201565ca18f366@haskell.org> #2926: Foreign exported function returns wrong type -------------------------------------+------------------------------------- Reporter: fasta | Owner: Type: bug | Status: new Priority: low | Milestone: ? Component: Compiler | Version: 6.10.1 (FFI) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #3238 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * failure: => None/Unknown * related: => #3238 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 4 18:03:31 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Dec 2014 18:03:31 -0000 Subject: [GHC] #2896: Warning suggestion: argument not necessarily a binary operator In-Reply-To: <045.d1206251042c791ccaaa9743fd236ce8@haskell.org> References: <045.d1206251042c791ccaaa9743fd236ce8@haskell.org> Message-ID: <060.28ce7000a3de938508c144d6df5a7c75@haskell.org> #2896: Warning suggestion: argument not necessarily a binary operator -------------------------------------+------------------------------------- Reporter: porges | Owner: Type: feature | Status: new request | Milestone: ? Priority: low | Version: 6.10.1 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: warning at compile-time | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * failure: => Incorrect warning at compile-time -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 4 18:09:24 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Dec 2014 18:09:24 -0000 Subject: [GHC] #2836: Data.Typeable does not use qualified names In-Reply-To: <044.8f82fa3eeec008c76155a3a9d33ae83d@haskell.org> References: <044.8f82fa3eeec008c76155a3a9d33ae83d@haskell.org> Message-ID: <059.910ed6dd5361c47e3570b081cf0d9ff9@haskell.org> #2836: Data.Typeable does not use qualified names -------------------------------------+------------------------------------- Reporter: guest | Owner: ekmett Type: feature | Status: new request | Milestone: 7.10.1 Priority: lowest | Version: 6.10.1 Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: core-libraries-committee@? (added) * failure: => None/Unknown * component: Compiler => Core Libraries * owner: => ekmett -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 4 18:42:12 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Dec 2014 18:42:12 -0000 Subject: [GHC] #2742: The -> in ViewPatterns binds more weakly than infix data constructors. In-Reply-To: <044.60b13b19392ff3d7bf14c8ffe9299245@haskell.org> References: <044.60b13b19392ff3d7bf14c8ffe9299245@haskell.org> Message-ID: <059.738423e2ff45cf3cdbafbe10c924e46b@haskell.org> #2742: The -> in ViewPatterns binds more weakly than infix data constructors. -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: feature | Status: new request | Milestone: ? Priority: normal | Version: 6.10.1 Component: Compiler | Keywords: (Parser) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * component: Compiler => Compiler (Parser) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 4 18:49:00 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Dec 2014 18:49:00 -0000 Subject: [GHC] #2742: The -> in ViewPatterns binds more weakly than infix data constructors. In-Reply-To: <044.60b13b19392ff3d7bf14c8ffe9299245@haskell.org> References: <044.60b13b19392ff3d7bf14c8ffe9299245@haskell.org> Message-ID: <059.a5c889892dc80e8bfb6d1f1f020223e7@haskell.org> #2742: The -> in ViewPatterns binds more weakly than infix data constructors. -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: feature | Status: new request | Milestone: ? Priority: normal | Version: 6.10.1 Component: Compiler | Keywords: newcomer (Parser) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by nomeata): * keywords: => newcomer Comment: Marking as newcomer not because this is trivial, but because coming up with a solution (if there is one) should be possible without deep knowledge of GHC, and implementing it is also likely possible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 4 19:19:36 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Dec 2014 19:19:36 -0000 Subject: [GHC] #2721: Newtype deriving doesn't work with type families In-Reply-To: <041.2b37e78c0fdcc1135c0e600ca8b06d99@haskell.org> References: <041.2b37e78c0fdcc1135c0e600ca8b06d99@haskell.org> Message-ID: <056.f1162460c133bbbd3b77862a515c6a3b@haskell.org> #2721: Newtype deriving doesn't work with type families -------------------------------------+------------------------------------- Reporter: rl | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: lowest | Version: 6.10.1 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | deriving/should_fail/T2721 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * component: Compiler => Compiler (Type checker) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 4 19:26:51 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Dec 2014 19:26:51 -0000 Subject: [GHC] #2697: bad testsuite results with ghc-6.10.0.20081007 In-Reply-To: <045.c368cc178489a6d371c14b6319d3b743@haskell.org> References: <045.c368cc178489a6d371c14b6319d3b743@haskell.org> Message-ID: <060.d84a9206d6ca6acbe77e78a320bdad3b@haskell.org> #2697: bad testsuite results with ghc-6.10.0.20081007 ---------------------------------------+--------------------------- Reporter: maeder | Owner: Type: bug | Status: closed Priority: normal | Milestone: ? Component: Compiler | Version: 6.9 Resolution: wontfix | Keywords: Operating System: MacOS X | Architecture: powerpc Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ---------------------------------------+--------------------------- Changes (by thomie): * status: new => closed * failure: => None/Unknown * resolution: => wontfix Comment: Please see #9389 for the current list of testsuite failures on OS X. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 4 19:49:22 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Dec 2014 19:49:22 -0000 Subject: [GHC] #2640: Treat -X flags consistently in GHCi In-Reply-To: <046.b2636e2b36f002a0dd024f2921ea27a7@haskell.org> References: <046.b2636e2b36f002a0dd024f2921ea27a7@haskell.org> Message-ID: <061.2a543708e70487630b27fecab064444d@haskell.org> #2640: Treat -X flags consistently in GHCi -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: lowest | Version: 6.8.3 Component: GHCi | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: hvr (added) * failure: => None/Unknown * component: Compiler => GHCi -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 4 20:04:08 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Dec 2014 20:04:08 -0000 Subject: [GHC] #2836: Data.Typeable does not use qualified names In-Reply-To: <044.8f82fa3eeec008c76155a3a9d33ae83d@haskell.org> References: <044.8f82fa3eeec008c76155a3a9d33ae83d@haskell.org> Message-ID: <059.e2c7c0c486a6fc75f79e5d09ebaeefc4@haskell.org> #2836: Data.Typeable does not use qualified names -------------------------------------+------------------------------------- Reporter: guest | Owner: ekmett Type: feature | Status: closed request | Milestone: 7.10.1 Priority: lowest | Version: 6.10.1 Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => fixed Comment: Goodness knows when, but this seems fixed: `TyCon` really stores the three bits Simon suggests above. There is still one thing missing: keeping track of the type namespace vs. the data namespace. But that's another ticket (#9858), so I'm closing this one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 4 20:13:07 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Dec 2014 20:13:07 -0000 Subject: [GHC] #9389: Full Test Suite Failures In-Reply-To: <042.38f06884e0da53a793f9dd734d87a005@haskell.org> References: <042.38f06884e0da53a793f9dd734d87a005@haskell.org> Message-ID: <057.a09ed33b39d659edcfaf023e7f6d6a42@haskell.org> #9389: Full Test Suite Failures -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | #9286,#8756,#7876,#7877 -------------------------------------+------------------------------------- Comment (by jrp): Here are today's results (OS X 10.10.1): {{{ OVERALL SUMMARY for test run started at Thu Dec 4 19:00:11 2014 GMT 0:37:10 spent to go through 4338 total tests, which gave rise to 14096 test cases, of which 2691 were skipped 275 had missing libraries 10905 expected passes 145 expected failures 3 caused framework failures 0 unexpected passes 62 unexpected failures 15 unexpected stat failures Unexpected failures: ../../libraries/base/tests enum01 [exit code non-0] (normal,hpc,optasm,threaded1,threaded2,dyn) ../../libraries/base/tests enum01 [bad stdout or stderr] (ghci) ../../libraries/base/tests enum02 [exit code non-0] (normal,hpc,optasm,threaded1,threaded2,dyn) ../../libraries/base/tests enum02 [bad stdout or stderr] (ghci) ../../libraries/base/tests enum03 [exit code non-0] (normal,hpc,optasm,threaded1,threaded2,dyn) ../../libraries/base/tests enum03 [bad stdout or stderr] (ghci) ../../libraries/base/tests topHandler01 [bad exit code] (threaded1,threaded2) ../../libraries/base/tests topHandler01 [bad stdout or stderr] (ghci) ../../libraries/process/tests process011 [bad exit code] (threaded1,threaded2) ../../libraries/process/tests process011 [bad stdout or stderr] (ghci) ../../libraries/unix/tests signals002 [bad stdout] (threaded1,threaded2) ../../libraries/unix/tests signals002 [bad stdout or stderr] (ghci) cabal/cabal01 cabal01 [bad exit code] (normal) cabal/cabal06 cabal06 [bad stdout] (normal) cabal/sigcabal01 sigcabal01 [bad stderr] (normal) concurrent/should_run allocLimit4 [bad exit code] (ghci) concurrent/should_run conc012 [bad exit code] (ghci) concurrent/should_run conc059 [bad stderr] (threaded1,threaded2) deSugar/should_run dsrun014 [bad exit code] (ghci) ffi/should_run T2276_ghci [bad stdout or stderr] (ghci) ghci/prog003 prog003 [bad stderr] (ghci) ghci/scripts T8696 [bad stderr] (ghci) ghci/scripts ghci024 [bad stdout] (normal) ghci/scripts ghci058 [bad stderr] (ghci) llvm/should_run/subsections_via_symbols subsections_via_symbols [bad exit code] (normal) numeric/should_run add2 [bad exit code] (ghci) numeric/should_run mul2 [bad exit code] (ghci) numeric/should_run quotRem2 [bad exit code] (ghci) parser/should_run readRun004 [bad exit code] (ghci) rts T5435_dyn_asm [bad stdout] (normal) rts T7919 [bad exit code] (optasm,dyn) typecheck/should_compile T7891 [exit code non-0] (hpc,optasm) typecheck/should_compile tc124 [exit code non-0] (hpc,optasm) typecheck/should_run T7861 [bad exit code] (normal,hpc,optasm,ghci,threaded1,threaded2,dyn) Unexpected stat failures: perf/compiler T1969 [stat not good enough] (normal) perf/compiler T3064 [stat not good enough] (normal) perf/compiler T3294 [stat not good enough] (normal) perf/compiler T4801 [stat not good enough] (normal) perf/compiler T5030 [stat not good enough] (normal) perf/compiler T5321FD [stat not good enough] (normal) perf/compiler T5321Fun [stat not good enough] (normal) perf/compiler T5631 [stat not good enough] (normal) perf/compiler T5642 [stat not good enough] (normal) perf/compiler T5837 [stat not good enough] (normal) perf/compiler T6048 [stat not good enough] (optasm) perf/compiler T783 [stat not good enough] (normal) perf/compiler T9020 [stat not good enough] (optasm) perf/compiler T9675 [stat not good enough] (optasm) perf/compiler parsing001 [stat not good enough] (normal) }}} and {{{./validate --fast}}} gives {{{ OVERALL SUMMARY for test run started at Thu Dec 4 20:00:43 2014 GMT 0:05:17 spent to go through 4338 total tests, which gave rise to 14092 test cases, of which 10097 were skipped 53 had missing libraries 3859 expected passes 70 expected failures 0 caused framework failures 0 unexpected passes 11 unexpected failures 2 unexpected stat failures Unexpected failures: cabal/cabal01 cabal01 [bad exit code] (normal) cabal/cabal06 cabal06 [bad stdout] (normal) cabal/sigcabal01 sigcabal01 [bad stderr] (normal) ffi/should_run T2276_ghci [bad stdout or stderr] (ghci) ghci/prog003 prog003 [bad stderr] (ghci) ghci/scripts T8696 [bad stderr] (ghci) ghci/scripts ghci058 [bad stderr] (ghci) ghci/should_run T2589 [bad stdout or stderr] (ghci) ghci/should_run ghcirun004 [bad stdout or stderr] (ghci) llvm/should_run/subsections_via_symbols subsections_via_symbols [bad exit code] (normal) rts T5435_dyn_asm [bad stdout] (normal) Unexpected stat failures: perf/compiler T4801 [stat too good] (normal) perf/compiler T9675 [stat not good enough] (optasm) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 4 20:24:07 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Dec 2014 20:24:07 -0000 Subject: [GHC] #4505: Segmentation fault on long input (list of pairs) In-Reply-To: <046.2dc545b3c32e7b8eef61780dd9491ae5@haskell.org> References: <046.2dc545b3c32e7b8eef61780dd9491ae5@haskell.org> Message-ID: <061.bda0820298a4df547b2345ede15cf1ae@haskell.org> #4505: Segmentation fault on long input (list of pairs) -------------------------------------+------------------------------------- Reporter: cathper | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Segmentation Operating System: Linux | fault, segfault, long input Type of failure: Runtime | Architecture: x86_64 (amd64) crash | Difficulty: Unknown Test Case: | Blocked By: 4258 Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rafael-felix): Would it help to create a "should fail" test case inside the array directory? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 4 20:39:52 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Dec 2014 20:39:52 -0000 Subject: [GHC] #2625: Unexpected -ddump-simpl output for derived Ord instance and UNPACKed fields In-Reply-To: <047.a4131859623f35304148b8ddaa8f3bbb@haskell.org> References: <047.a4131859623f35304148b8ddaa8f3bbb@haskell.org> Message-ID: <062.1d1c13fef78ee58f1b09efe859e4866b@haskell.org> #2625: Unexpected -ddump-simpl output for derived Ord instance and UNPACKed fields -------------------------------------+------------------------------------- Reporter: aslatter | Owner: Type: bug | Status: new Priority: low | Milestone: ? Component: Compiler | Version: 6.8.3 Resolution: | Keywords: Operating System: | Architecture: x86_64 (amd64) Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * failure: => Runtime performance bug Comment: Since 7.8, setting `-fmax-worker-args=20` (higher than 16), as suggested by Simon in comment:3, doesn't have any effect on the core of the program from the description. It did in 7.6 and below. I can't tell whether the bug is fixed or not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 4 20:44:00 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Dec 2014 20:44:00 -0000 Subject: [GHC] #9862: defined but not used errors on Solaris/SPARC Message-ID: <045.7d63ce3f461ee96da7f3904fb48b75b1@haskell.org> #9862: defined but not used errors on Solaris/SPARC -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.8.2 Keywords: | Operating System: Solaris Architecture: sparc | Type of failure: Incorrect Difficulty: Unknown | warning at compile-time Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I recently tried building GHC on Solaris and I got a ton of these files when compiling the bootstrapping copy of Cabal: {{{ "/afs/sipb/user/ezyang/ghc-7.8.2/usr/bin//ghc" -H32m -O -Werror -Wall -H64m -O0 \ -optc-Werror -optc-Wall -optc-fno-stack-protector \ \ --make utils/ghc-cabal/Main.hs -o utils/ghc- cabal/dist/build/tmp/ghc-cabal \ -no-user-package-db \ -Wall -fno-warn-unused-imports -fno-warn-warnings- deprecations \ -DCABAL_VERSION=1,21,1,0 \ -DBOOTSTRAPPING \ -odir bootstrapping \ -hidir bootstrapping \ -ilibraries/Cabal/Cabal \ -ilibraries/binary/src -DGENERICS \ -ilibraries/filepath \ -ilibraries/hpc \ -w "rm" -f compiler/stage1/build/Config.hs Creating compiler/stage1/build/Config.hs ... "rm" -f utils/ghc-pkg/dist/build/Version.hs echo "module Version where" >> utils/ghc- pkg/dist/build/Version.hs echo "version, targetOS, targetARCH :: String" >> utils/ghc- pkg/dist/build/Version.hs echo "version = \"7.9.20141204\"" >> utils/ghc- pkg/dist/build/Version.hs echo "targetOS = \"solaris2\"" >> utils/ghc- pkg/dist/build/Version.hs echo "targetARCH = \"sparc\"" >> utils/ghc-pkg/dist/build/Version.hs done. [ 1 of 86] Compiling Distribution.Compat.CreatePipe ( libraries/Cabal/Cabal/Distribution/Compat/CreatePipe.hs, bootstrapping/Distribution/Compat/CreatePipe.o ) cc1: warnings being treated as errors /tmp/ghc322370_0/ghc322370_21.hc: In function ?s1xM_entry?: /tmp/ghc322370_0/ghc322370_21.hc:21:0: error: label ?_c312? defined but not used /tmp/ghc322370_0/ghc322370_21.hc: In function ?s1xK_entry?: /tmp/ghc322370_0/ghc322370_21.hc:63:0: error: label ?_c31b? defined but not used }}} Maybe the 7.8.2 codegen which I bootstrapped from is buggy in some way? It makes it mildly difficult to actually validate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 4 20:44:18 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Dec 2014 20:44:18 -0000 Subject: [GHC] #9863: Provide PowerPC 64 bit native code generator Message-ID: <047.abf3d61d6edeed38824d04625109fece@haskell.org> #9863: Provide PowerPC 64 bit native code generator -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Linux Architecture: powerpc64 | Type of failure: Difficulty: Project (more | None/Unknown than a week) | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- I have started work on a native code generator for PowerPC 64 bit by extending the 32 bit code generator. The code is hosted on github: [https://github.com/trommler/ghc/tree/native] So far I plan to support the old ELF v1.9 ABI on big endian. I might look into little endian and ELF 2.0 later. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 4 20:56:47 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Dec 2014 20:56:47 -0000 Subject: [GHC] #9389: Full Test Suite Failures In-Reply-To: <042.38f06884e0da53a793f9dd734d87a005@haskell.org> References: <042.38f06884e0da53a793f9dd734d87a005@haskell.org> Message-ID: <057.dc69f8f2cae352b6b9d2644798a0e6ac@haskell.org> #9389: Full Test Suite Failures -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | #9286,#8756,#7876,#7877 -------------------------------------+------------------------------------- Comment (by nomeata): What are the settings for the first set of results? Note that performance test results are only valid for the default validate settings, which are *not* the default or the release settings (as discussed in #9315). The others are definitely relevant, but not very helpful without full build logs. How about you create a git repo somewhere where you add your build logs, then you can link them from her, like https://github.com/nomeata/ghc-speed-logs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 4 22:07:00 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Dec 2014 22:07:00 -0000 Subject: [GHC] #9864: Need realloc/resize feature for mallocForeignPtrBytes allocated memory Message-ID: <044.d1a9096a0bbafbc8d18e8227b456d5fc@haskell.org> #9864: Need realloc/resize feature for mallocForeignPtrBytes allocated memory -------------------------------------+------------------------------------- Reporter: slomo | Owner: ekmett Type: feature request | Status: new Priority: low | Milestone: Component: Core Libraries | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Hi, it would be great if there would be something to reallocate or resize the memory allocated by - mallocPlainForeignPtrBytes or - mallocForeignPtrBytes Currently this is only possible with memory allocated via mallocBytes by using reallocBytes, but that's using the system's normal malloc()/realloc() and will not return memory in the GC heap. My proposal for a reallocForeignPtrBytes would have the same effects as reallocBytes. I.e. - if the new size is bigger than the old size, make enough free space available. This probably might result in copying the previous memory area to a newly allocated one - if the new size is smaller than the old size, mark mark the memory area as smaller. It should not result in immediate copying of the data, but it would e.g. allow the GC during a compacting phase to release the additional memory (note: I don't know how the GHC GC works internally) - if the new size is the same, do nothing One possible use case for this would be in ByteString. Currently Data.ByteString.Internal.createAndTrim will copy the completely memory if the actual size was less than the expected maximum size. This should be unnecessary and only wastes CPU cycles. It would also be useful for bindings to native libraries, e.g. for allocating the output buffer for iconv(). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 4 23:18:56 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Dec 2014 23:18:56 -0000 Subject: [GHC] #9389: Full Test Suite Failures In-Reply-To: <042.38f06884e0da53a793f9dd734d87a005@haskell.org> References: <042.38f06884e0da53a793f9dd734d87a005@haskell.org> Message-ID: <057.0d6a0efbc61d58b2fd17e16237a5c07b@haskell.org> #9389: Full Test Suite Failures -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | #9286,#8756,#7876,#7877 -------------------------------------+------------------------------------- Comment (by jrp): I am using the default build file with the recommended fast selected. I'll have a look at the links and putting up a github repo. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 4 23:58:58 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Dec 2014 23:58:58 -0000 Subject: [GHC] #5443: Errors when shutting down the event manager loop In-Reply-To: <049.c83f389d37163cb8f5f3840f51a6024e@haskell.org> References: <049.c83f389d37163cb8f5f3840f51a6024e@haskell.org> Message-ID: <064.54550b6ac1abc2f7bc31b935823b4920@haskell.org> #5443: Errors when shutting down the event manager loop -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: tibbe Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.2.1 Resolution: worksforme | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => worksforme -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 5 00:50:01 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Dec 2014 00:50:01 -0000 Subject: [GHC] #7736: Parallel array enumeration causes compiler panic (enumFromToP) In-Reply-To: <051.4008212f128c07df40f2414b51ea0564@haskell.org> References: <051.4008212f128c07df40f2414b51ea0564@haskell.org> Message-ID: <066.0fa1db69ddd5d4cf29438e4b353d1726@haskell.org> #7736: Parallel array enumeration causes compiler panic (enumFromToP) -------------------------------------+------------------------------------- Reporter: | Owner: chak amosrobinson | Status: closed Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.7 Component: Compiler | Keywords: Resolution: wontfix | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Compile- | Related Tickets: #7078 time crash | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by amosrobinson): * status: new => closed * resolution: => wontfix Comment: I don't think this is worth fixing - DPH hasn't been actively developed for a while, and the general impression is that it's too lofty a goal for now. As far as I know, this extension is only used by DPH? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 5 01:27:32 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Dec 2014 01:27:32 -0000 Subject: [GHC] #9605: Misleading error message with forgotten "do" In-Reply-To: <043.4d0a36fa55a61f7a0e16739341de4daf@haskell.org> References: <043.4d0a36fa55a61f7a0e16739341de4daf@haskell.org> Message-ID: <058.cc3c466d0e73541f2ff83b5ed5d0cfd3@haskell.org> #9605: Misleading error message with forgotten "do" -------------------------------------+------------------------------------- Reporter: owst | Owner: Yuras Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #7869 None/Unknown | Test Case: | Blocking: | Differential Revisions: D556 | -------------------------------------+------------------------------------- Changes (by Yuras): * owner: => Yuras * differential: => D556 * component: Compiler => Compiler (Type checker) * related: => #7869 Comment: I prepared a patch to skip "but its type T has only two" part here, and report only inferred type. Any ideas how to improve the error message further? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 5 01:29:28 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Dec 2014 01:29:28 -0000 Subject: [GHC] #9865: Comonads in base library Message-ID: <050.1aeed8f93bd414fa38dcb5213e8076cb@haskell.org> #9865: Comonads in base library -------------------------------------+------------------------------------- Reporter: spacekitteh | Owner: ekmett Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comonads are useful as heck, and should be in the base library. This could allow codo notation (e.g. https://www.cl.cam.ac.uk/~dao29/publ/codo- notation-orchard-ifl12.pdf ) in the future. It shouldn't be hard at all to do - just basically copy Edward's comonad package :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 5 01:32:10 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Dec 2014 01:32:10 -0000 Subject: [GHC] #9605: Misleading error message with forgotten "do" In-Reply-To: <043.4d0a36fa55a61f7a0e16739341de4daf@haskell.org> References: <043.4d0a36fa55a61f7a0e16739341de4daf@haskell.org> Message-ID: <058.3ee06c3a714185c05dd00ef75cb51a17@haskell.org> #9605: Misleading error message with forgotten "do" -------------------------------------+------------------------------------- Reporter: owst | Owner: Yuras Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #7869 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D556 | -------------------------------------+------------------------------------- Changes (by Yuras): * differential: D556 => Phab:D556 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 5 06:48:34 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Dec 2014 06:48:34 -0000 Subject: [GHC] #9257: CC_CLANG_BACKEND not reconfigured during bindist install In-Reply-To: <050.30f8cd90b97558f93f1173aa6607ce01@haskell.org> References: <050.30f8cd90b97558f93f1173aa6607ce01@haskell.org> Message-ID: <065.0a2257a64fc21e92cf287ed6c6e7811e@haskell.org> #9257: CC_CLANG_BACKEND not reconfigured during bindist install -------------------------------------+------------------------------------- Reporter: | Owner: MtnViewMark | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.2 Component: Build | Keywords: clang System | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less Operating System: MacOS X | than a day) Type of failure: Installing | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by ezyang): Here is a workaround to solve this problem, especially if you're trying to bootstrap GHC from an old buggy bindist but your GCC is the wrong version. Create a file named gcc with the following contents: {{{ #!/usr/bin/python import sys import os os.execv("/usr/bin/gcc", ["/usr/bin/gcc"] + [i for i in sys.argv[1:] if i != "-Wno-invalid-pp-token" and i != "-Wno-unicode"]) }}} Replace both instances of `/usr/bin/gcc` if your GCC is in an unusual place. Chmod it executable. Now, when configuring your bindist, pass the configure flag `--with-gcc=/path/to/your/gcc`. This will strip out the warning flags and make things work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 5 11:29:24 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Dec 2014 11:29:24 -0000 Subject: [GHC] #9866: ssh pubkey self-mgmt Message-ID: <042.33bc9e8f00bfd2c91dacfdc501f9a714@haskell.org> #9866: ssh pubkey self-mgmt -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: feature request | Status: new Priority: normal | Milestone: ? Component: Trac & Git | Version: Keywords: git | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 5 15:29:09 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Dec 2014 15:29:09 -0000 Subject: [GHC] #2598: Avoid excessive specialisation in SpecConstr In-Reply-To: <046.41dadb7ee5f62a188e8b2b903c4852f9@haskell.org> References: <046.41dadb7ee5f62a188e8b2b903c4852f9@haskell.org> Message-ID: <061.7040b18aefa2a4cdccf8d9e3a062a50f@haskell.org> #2598: Avoid excessive specialisation in SpecConstr -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: lowest | Version: 6.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): Replying to [comment:17 morabbin]: > Is this moot now? The excessive specializations still show up with `-fspec-constr-count` greater than 5. The default is 3, and was introduced in commit e5adcaf845207c73da65cb44cff4ef83b76dd4a9. I believe this ticket is about coming up with a better heuristic. {{{ Author: simonpj at microsoft.com Date: Thu Mar 6 12:00:04 2008 +0000 Improve SpecConstr for local bindings: seed specialisation from the calls ... * New flag -fspec-constr-count=N sets the maximum number of specialisations for any single function to N. -fno-spec-constr-count removes the limit. ... }}} This is the command I used to test: {{{ ghc DropComment.hs -O -fspec-constr -ddump-simpl -fspec-constr-count=6 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 5 15:30:27 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Dec 2014 15:30:27 -0000 Subject: [GHC] #2598: Avoid excessive specialisation in SpecConstr In-Reply-To: <046.41dadb7ee5f62a188e8b2b903c4852f9@haskell.org> References: <046.41dadb7ee5f62a188e8b2b903c4852f9@haskell.org> Message-ID: <061.e2281ddb852b99a4cd024ed2fb8f8f31@haskell.org> #2598: Avoid excessive specialisation in SpecConstr -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: lowest | Version: 6.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * failure: None/Unknown => Runtime performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 5 17:12:17 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Dec 2014 17:12:17 -0000 Subject: [GHC] #2551: Allow multiple modules per source file In-Reply-To: <047.3a5018e62377d0e216dd18feced12298@haskell.org> References: <047.3a5018e62377d0e216dd18feced12298@haskell.org> Message-ID: <062.2ac785ce2f7ba63dcc52e0e1b5847b36@haskell.org> #2551: Allow multiple modules per source file -------------------------------------+------------------------------------- Reporter: YitzGale | Owner: Type: feature | Status: new request | Milestone: ? Priority: normal | Version: 6.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: closed => new * resolution: wontfix => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 5 17:15:18 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Dec 2014 17:15:18 -0000 Subject: [GHC] #2550: Add an option to read file names from a file instead of the command line In-Reply-To: <047.3665f1a48a327f8421f4cc9de980373f@haskell.org> References: <047.3665f1a48a327f8421f4cc9de980373f@haskell.org> Message-ID: <062.51290f08e5f80dda32fc298b793f5d3e@haskell.org> #2550: Add an option to read file names from a file instead of the command line -------------------------------------+------------------------------------- Reporter: YitzGale | Owner: Type: feature | Status: new request | Milestone: 7.12.1 Priority: lowest | Version: 6.9 Component: Package | Keywords: system | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #2551 Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * failure: => None/Unknown * component: Compiler => Package system * related: => #2551 * milestone: 7.10.1 => 7.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 5 17:23:14 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Dec 2014 17:23:14 -0000 Subject: [GHC] #2531: Prune duplicates in ghci history In-Reply-To: <045.a0871c51adeff1456b5bd9c24f43a05b@haskell.org> References: <045.a0871c51adeff1456b5bd9c24f43a05b@haskell.org> Message-ID: <060.61e43b39358bb0d6a8f3a7ecc3dbb55e@haskell.org> #2531: Prune duplicates in ghci history -------------------------------------+------------------------------------- Reporter: venkat | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: lowest | Version: 6.8.3 Component: GHCi | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: Documentation bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: hvr (added) * failure: None/Unknown => Documentation bug Comment: Replying to [comment:7 vivian]: > You can add the following line to your `.haskeline` file: > {{{ > > historyDuplicates IgnoreConsecutive > }}} > or `AlwaysAdd` or `IgnoreAll`. This could be added to the GHCi documentation. See also: http://trac.haskell.org/haskeline/wiki/UserPrefs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 5 17:55:02 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Dec 2014 17:55:02 -0000 Subject: [GHC] #2522: Warning for missing export lists In-Reply-To: <042.bc97894bc85aa965fac36f83804d8ebb@haskell.org> References: <042.bc97894bc85aa965fac36f83804d8ebb@haskell.org> Message-ID: <057.8708102be2f49389c7bfade05c2937db@haskell.org> #2522: Warning for missing export lists -------------------------------------+------------------------------------- Reporter: tim | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: lowest | Version: 6.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: NeilMitchell (added) Comment: Neil: is this something `hlint` could do? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 5 17:57:17 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Dec 2014 17:57:17 -0000 Subject: [GHC] #2514: Add/Expose Binary API that allows dumping of any GHC Binary instance In-Reply-To: <047.57cf723e547f8e60541f4f12c39c26fa@haskell.org> References: <047.57cf723e547f8e60541f4f12c39c26fa@haskell.org> Message-ID: <062.4019c90b595b9c1ee404fc004425176d@haskell.org> #2514: Add/Expose Binary API that allows dumping of any GHC Binary instance -------------------------------------+------------------------------------- Reporter: nominolo | Owner: nominolo Type: feature | Status: infoneeded request | Milestone: 7.10.1 Priority: lowest | Version: 6.9 Component: GHC API | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => infoneeded * failure: => None/Unknown Comment: Does anyone know what the status of this is? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 5 18:03:42 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Dec 2014 18:03:42 -0000 Subject: [GHC] #2489: Registry keys are created in per-user HKCU instead of system-wide HKLM In-Reply-To: <045.8268642d688f1830bf5e7f9b3d0846d3@haskell.org> References: <045.8268642d688f1830bf5e7f9b3d0846d3@haskell.org> Message-ID: <060.f4b711fbf46bd6388b2952f1a3c94973@haskell.org> #2489: Registry keys are created in per-user HKCU instead of system-wide HKLM -------------------------------------+------------------------------------- Reporter: nimnul | Owner: Type: bug | Status: closed Priority: normal | Milestone: ? Component: None | Version: 6.8.3 Resolution: wontfix | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: | Difficulty: Unknown None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => wontfix Comment: commit 9e4e2c24d1895ae81c92e4432b91026505827c96 {{{ Author: Ian Lynagh <> Date: Sat Apr 20 13:00:21 2013 +0100 Remove the Windows installer We now leave making installers to the Haskell Platform. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 5 18:45:28 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Dec 2014 18:45:28 -0000 Subject: [GHC] #2465: Fusion of recursive functions (was: View + Pattern Match not fused sufficiently) In-Reply-To: <044.d33f6438c82e85b6cd4f00a3e01e2de0@haskell.org> References: <044.d33f6438c82e85b6cd4f00a3e01e2de0@haskell.org> Message-ID: <059.c32dc4789a50b7de855b5ff5b83a1287@haskell.org> #2465: Fusion of recursive functions -------------------------------------+------------------------------------- Reporter: ryani | Owner: Type: feature | Status: new request | Milestone: ? Priority: low | Version: 6.8.2 Component: Compiler | Keywords: Resolution: | Architecture: x86 Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: #3123 performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * type: bug => feature request * related: => #3123 Comment: > But GHC isn't going to fuse recursive functions all by itself anytime soon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 5 19:41:38 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Dec 2014 19:41:38 -0000 Subject: [GHC] #9223: Type equality makes type variable untouchable In-Reply-To: <048.6ce33f316f2e616ec0311d809cccfbe7@haskell.org> References: <048.6ce33f316f2e616ec0311d809cccfbe7@haskell.org> Message-ID: <063.c4421a9b4ebf3816a22e9ddc0b9829a0@haskell.org> #9223: Type equality makes type variable untouchable -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by tvynr): I just ran into something that seems at least related. I'm trying to use Happy in tandem with statically typing the payload I get from different functions (so I don't have to do the thing the GHC parser does with explicit calls to unwrapping functions). Eventually, I got the essence of the problem down to this MWE: {{{ {-# LANGUAGE GADTs, ExistentialQuantification #-} module Main where data Token t = forall a. Token (SomeToken t a) data SomeToken t a = SomeToken (t a) a data TokenType a where TokLitInt :: TokenType Integer TokLitPlus :: TokenType () -- Without the type signature, GHC 7.8.3 can't infer the type of this function. --foo :: Token TokenType -> Integer foo (Token (SomeToken TokLitInt x)) = x + 1 foo _ = 0 main :: IO () main = undefined }}} The above code typechecks in GHC 7.6.3 with and without the type signature. In GHC 7.8.3, it fails to typecheck (unless the type signature is present) with the following error message: {{{ Couldn't match type ?a? with ?Integer? ?a? is untouchable inside the constraints (a1 ~ Integer) bound by a pattern with constructor TokLitInt :: TokenType Integer, in an equation for ?foo? at Test.hs:15:23-31 ?a? is a rigid type variable bound by the inferred type of foo :: Num a => Token TokenType -> a at Test.hs:15:1 Expected type: a Actual type: a1 Relevant bindings include foo :: Token TokenType -> a (bound at Test.hs:15:1) In the expression: x + 1 In an equation for ?foo?: foo (Token (SomeToken TokLitInt x)) = x + 1 }}} This is unfortunate for me because Happy doesn't generate type signatures but does, in the approach I'm using, wind up generating code that behaves equivalently. Putting a type signature on the use of "x" doesn't help, either, though I'm guessing that this is unsurprising to those who understand the relevant paper better. :) If you'll forgive my naivet?, it seems pretty peculiar from the perspective of an amateur Haskell programmer that this type isn't inferred; I'd think that the type variable from the two arguments of SomeToken would be unified by the fact that they were introduced by the same pattern match. But the error message indicates two variables, "a" and "a1", and doesn't really seem to relate them. Am I missing something? That said, I need to read the paper mentioned in this thread rather thoroughly now and I understand if it sounds like I'm asking for a pony. :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 5 20:04:31 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Dec 2014 20:04:31 -0000 Subject: [GHC] #9867: PatternSynonyms + ScopedTypeVariables triggers an internal error Message-ID: <046.5cdd1cb9d606767d1869bca60906658f@haskell.org> #9867: PatternSynonyms + ScopedTypeVariables triggers an internal error -------------------------------------+------------------------------------- Reporter: antalsz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- When trying to give a type signature with a free type variable to a pattern in a pattern synonym, GHC dies with an internal error. Given the file {{{#!hs {-# LANGUAGE PatternSynonyms, ScopedTypeVariables #-} pattern Nil = [] :: [a] }}} the resulting error is {{{ Example.hs:2:22: GHC internal error: ?a? is not in scope during type checking, but it passed the renamer ? tcl_env of environment: [] In an expression type signature: [a] In the expression: [] :: [a] In an equation for ?$WNil?: $WNil = [] :: [a] Compilation failed. }}} The fix is to add `RankNTypes` and an explicit `forall`: {{{#!hs {-# LANGUAGE PatternSynonyms, ScopedTypeVariables, RankNTypes #-} pattern Nil = [] :: forall a. [a] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 5 20:05:27 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Dec 2014 20:05:27 -0000 Subject: [GHC] #2456: For higher kinds, instance declarations need quantification in the context In-Reply-To: <046.de0b35ad5d95f2dbcea756cdc13c675e@haskell.org> References: <046.de0b35ad5d95f2dbcea756cdc13c675e@haskell.org> Message-ID: <061.3ef1d10835e337d943c543600b061bff@haskell.org> #2456: For higher kinds, instance declarations need quantification in the context -------------------------------------------+--------------------------- Reporter: ronwalf | Owner: Type: feature request | Status: closed Priority: normal | Milestone: ? Component: Compiler | Version: 6.9 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #2893 Differential Revisions: | -------------------------------------------+--------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #2893 Comment: Replying to [comment:7 simonpj]: > So I'll retitle this ticket as a feature request for such a feature. Note: doing this makes it more difficult to test whether a ticket can be closed or not, because the description, attached testcases and part of the discussion are still for the original bug. Nevertheless, this feature request is covered by #2893 (Implement "Quantified contexts" proposal). Also some discussion in #5927 and #7019. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 5 20:13:23 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Dec 2014 20:13:23 -0000 Subject: [GHC] #9223: Type equality makes type variable untouchable In-Reply-To: <048.6ce33f316f2e616ec0311d809cccfbe7@haskell.org> References: <048.6ce33f316f2e616ec0311d809cccfbe7@haskell.org> Message-ID: <063.8f951ca9a60a5f5f9a135bc4789f63bf@haskell.org> #9223: Type equality makes type variable untouchable -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): Interesting example! I'm not convinced this is related to the original ticket, but it is curious. I do see why !OutsideIn refuses to type-check this, in the presence of the GADT pattern-match on `TokIntLit`. But what's interesting to me is that I can't come up with a type other than `Token TokenType -> Integer` for `foo`. As I note above, usually when we get untouchable variable errors, there is an alternate type that could be assigned... but here, that doesn't seem to be the case, because the GADT pattern-match is happening over an existentially-bound variable. I don't know what the fix is here, but it's an interesting case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 5 20:22:45 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Dec 2014 20:22:45 -0000 Subject: [GHC] #9223: Type equality makes type variable untouchable In-Reply-To: <048.6ce33f316f2e616ec0311d809cccfbe7@haskell.org> References: <048.6ce33f316f2e616ec0311d809cccfbe7@haskell.org> Message-ID: <063.90c0d9e25b4085d094acd2eb5cab2779@haskell.org> #9223: Type equality makes type variable untouchable -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by tvynr): I'm glad the example is at least somewhat useful. :) I'm unfamiliar enough with the mechanics involved that I don't know if this is related. Should I open another ticket instead or just leave this stuff here? The thing that seems especially peculiar to me is that, in the example above, GHC 7.6.3 can infer the type just fine. This suggests that the GHC 7.8.3 inference algorithm has been made more conservative in some way. I'm guessing that this difference is related to fixing a bug of some kind but, as you say, this case only seems to have the one type which could be inferred. In the meanwhile, I suppose we'll just use the workaround of an explicit unwrapper function if we need to move to GHC 7.8. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 5 20:27:20 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Dec 2014 20:27:20 -0000 Subject: [GHC] #9223: Type equality makes type variable untouchable In-Reply-To: <048.6ce33f316f2e616ec0311d809cccfbe7@haskell.org> References: <048.6ce33f316f2e616ec0311d809cccfbe7@haskell.org> Message-ID: <063.edbe10057da494ace565c976b0e82aec@haskell.org> #9223: Type equality makes type variable untouchable -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): My guess is that this ''is'' separate from the first post, but, in both cases, there is an untouchable type variable where there is a principal type. I'd wait for Simon's opinion before splitting this off. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 5 22:10:52 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Dec 2014 22:10:52 -0000 Subject: [GHC] #2346: Compilation of large source files requires a lot of RAM In-Reply-To: <046.285595109907aedbac69f385749bac00@haskell.org> References: <046.285595109907aedbac69f385749bac00@haskell.org> Message-ID: <061.6badb647f3af5450c2706ab6611e3cda@haskell.org> #2346: Compilation of large source files requires a lot of RAM -------------------------------------+------------------------------------- Reporter: choener | Owner: Type: bug | Status: new Priority: lowest | Milestone: 7.10.1 Component: Compiler | Version: 6.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * os: Linux => Unknown/Multiple * architecture: x86 => Unknown/Multiple Comment: `RF00549.hs` still fails to compile with a 2GB RAM limit on x86_64 Linux (`ulimit -v 2000000`). This ticket is listed as `desugaring let-bindings` on [wiki:Status/SLPJ- Tickets]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 5 22:37:03 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Dec 2014 22:37:03 -0000 Subject: [GHC] #2333: Emit a warning if an INLINE function is a loop breaker In-Reply-To: <046.23407b4f66367aefddc60efec387ceb9@haskell.org> References: <046.23407b4f66367aefddc60efec387ceb9@haskell.org> Message-ID: <061.0ee0dd3d2c425175f7ec7309c4f01f26@haskell.org> #2333: Emit a warning if an INLINE function is a loop breaker -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: lowest | Version: 6.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: warning at compile-time | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * failure: => Incorrect warning at compile-time -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 5 23:24:40 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Dec 2014 23:24:40 -0000 Subject: [GHC] #9868: ghc: panic! Dynamic linker not initialised Message-ID: <046.5f3f9e960e287bc6e82a07e7ce17a8b6@haskell.org> #9868: ghc: panic! Dynamic linker not initialised -------------------------------------+------------------------------------- Reporter: Jamedjo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: Compile- Difficulty: Unknown | time crash Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I was playing around and not expecting cabal build to succeed yet. If if didn't say the impossible had happened I would assumed I was missing something and used the error to drive my next action {{{ : ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-apple-darwin): Dynamic linker not initialised Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} There had been another error before: {{{ : : can't load .so/.DLL for: /Users/JamesEJ/bindings- cef3/dist/build/libHSbindings-cef3-0.1.0-ghc7.8.3.dylib (dlopen(/Users/JamesEJ/bindings-cef3/dist/build/libHSbindings- cef3-0.1.0-ghc7.8.3.dylib, 9): Symbol not found: _cef_add_cross_origin_whitelist_entry Referenced from: /Users/JamesEJ/bindings-cef3/dist/build/libHSbindings- cef3-0.1.0-ghc7.8.3.dylib Expected in: flat namespace in /Users/JamesEJ/bindings-cef3/dist/build/libHSbindings- cef3-0.1.0-ghc7.8.3.dylib) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 5 23:32:26 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Dec 2014 23:32:26 -0000 Subject: [GHC] #2273: inlining defeats seq In-Reply-To: <044.9c3223a55b4d3223b10ccf35be7e7d4f@haskell.org> References: <044.9c3223a55b4d3223b10ccf35be7e7d4f@haskell.org> Message-ID: <059.95d93400890431b1bdb7d75d57ed7346@haskell.org> #2273: inlining defeats seq -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: lowest | Milestone: 7.10.1 Component: Compiler | Version: 6.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * failure: None/Unknown => Runtime performance bug Comment: SPJ: what is the status of this ticket? You reopened it in comment:8 and comment:10, but this ticket is not on [wiki:Status/SLPJ-Tickets]. The link in comment:8 is unfortunately broken. The following tickets all link here: #2457, #3263, #5129, #9127, #9353. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 5 23:41:49 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Dec 2014 23:41:49 -0000 Subject: [GHC] #2260: Non-ideal error message for misplaced LANGUAGE pragma In-Reply-To: <044.7cbacc8885ebc555467b0dece9c1a57d@haskell.org> References: <044.7cbacc8885ebc555467b0dece9c1a57d@haskell.org> Message-ID: <059.be1fa5754a3cbefe55745cd4013e4f8a@haskell.org> #2260: Non-ideal error message for misplaced LANGUAGE pragma -------------------------------------+------------------------------------- Reporter: TomMD | Owner: Type: bug | Status: new Priority: lowest | Milestone: 7.10.1 Component: Compiler | Version: 6.8.2 (Parser) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: warning at compile-time | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * failure: None/Unknown => Incorrect warning at compile-time -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 5 23:53:03 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Dec 2014 23:53:03 -0000 Subject: [GHC] #2256: Incompleteness of type inference: must quantify over implication constraints In-Reply-To: <046.2c6c7c4440a32ff5fbe5ad1f48bf6276@haskell.org> References: <046.2c6c7c4440a32ff5fbe5ad1f48bf6276@haskell.org> Message-ID: <061.8d886f484558305222399ef3107349f5@haskell.org> #2256: Incompleteness of type inference: must quantify over implication constraints -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: lowest | Milestone: 7.10.1 Component: Compiler | Version: 6.8.2 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * failure: None/Unknown => GHC rejects valid program * component: Compiler => Compiler (Type checker) Comment: SPJ: this ticket is not listed on [wiki:Status/SLPJ-Tickets]. The error message with HEAD (ghc-7.9.20141204): {{{ Could not deduce (Eq b) arising from a use of ?sig? from the context (Eq c) bound by the type signature for h :: Eq c => c -> () at test.hs:5:26-40 Possible fix: add (Eq b) to the context of the type signature for h :: Eq c => c -> () or the inferred type of g :: b -> () In the expression: sig x y z In an equation for ?h?: h z = sig x y z In the expression: let h :: Eq c => c -> () h z = sig x y z in () }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 6 00:02:39 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Dec 2014 00:02:39 -0000 Subject: [GHC] #2224: -fhpc inteferes/prevents rewrite rules from firing In-Reply-To: <043.0a1d2cb80ab6ed909cbaaf8b919814c3@haskell.org> References: <043.0a1d2cb80ab6ed909cbaaf8b919814c3@haskell.org> Message-ID: <058.07280f2cf94bc0cd127b075118f66c97@haskell.org> #2224: -fhpc inteferes/prevents rewrite rules from firing -------------------------------------+------------------------------------- Reporter: dons | Owner: andy@? Type: bug | Status: new Priority: lowest | Milestone: 7.10.1 Component: Code | Version: 6.8.2 Coverage | Keywords: rules, hpc Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * failure: => None/Unknown Old description: > Use case: > > I'm writing tests for rewrite rules, and using HPC to determine if rules > were fired (and their code exercised). HPC is quite cool here, since it > lets us see which rules fired, without needing to explicitly export > functions to test. > > However, -fhpc seems to prevent many rules from firing (likely due to > ticks getting in the way?) > > For example: > > {{{ > import qualified Data.ByteString.Char8 as C > > main = print (C.pack "literal") > }}} > > When compiled normally, triggers a nice rewrite rule: > > {{{ > $ ghc -O2 A.hs -ddump-simpl-stats A.hs -c > > 1 ByteString pack/packAddress > }}} > > Now with -fhpc: > > {{{ > 2 RuleFired > 1 unpack > 1 unpack-list > }}} > > What's the best way to ensure the same code is exercised with and without > -fhpc here? (I'd quite like to get this working, since rewrite rules > benefit from testing.) New description: Use case: I'm writing tests for rewrite rules, and using HPC to determine if rules were fired (and their code exercised). HPC is quite cool here, since it lets us see which rules fired, without needing to explicitly export functions to test. However, -fhpc seems to prevent many rules from firing (likely due to ticks getting in the way?) For example: {{{ import qualified Data.ByteString.Char8 as C main = print (C.pack "literal") }}} When compiled normally, triggers a nice rewrite rule: {{{ $ ghc -O2 A.hs -ddump-rule-firings A.hs -c Rule fired: unpack Rule fired: Class op show Rule fired: unpack-list Rule fired: ByteString packChars/packAddress Rule fired: unpack Rule fired: Class op show Rule fired: unpack-list Rule fired: ByteString packChars/packAddres }}} Now with -fhpc: {{{ $ ghc -O2 A.hs -ddump-rule-firings A.hs -c -fhpc Rule fired: unpack Rule fired: Class op show Rule fired: unpack-list Rule fired: unpack Rule fired: Class op show Rule fired: unpack-list }}} What's the best way to ensure the same code is exercised with and without -fhpc here? (I'd quite like to get this working, since rewrite rules benefit from testing.) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 6 00:08:30 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Dec 2014 00:08:30 -0000 Subject: [GHC] #9223: Type equality makes type variable untouchable In-Reply-To: <048.6ce33f316f2e616ec0311d809cccfbe7@haskell.org> References: <048.6ce33f316f2e616ec0311d809cccfbe7@haskell.org> Message-ID: <063.4df17ff46efe27f60035173bdd516060@haskell.org> #9223: Type equality makes type variable untouchable -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Consider {{{ data T a where T1 :: T Int T2 :: T Bool T3 :: T a f T2 = True g T1 = True }}} Can we infer a type for `f`? Well we know it must be something like {{{ f :: T a -> ?? }}} just from the lambda and the pattern match. What is the `??`? Call it `beta`, a unification variable. The pattern match gives us a "given" constraint `a~Bool`, and the RHS has type `Bool`, so the wanted" constraint is `beta~Bool`. So we could unify `beta with `Bool` or with `a`; both would work. Since neither is more general than the other, we reject the program. What about `g`? Here we have "given" `a~Int`, but the same wanted constraint is `beta~Bool` is generated. Now there is only one solution, namely `beta:=Bool`, because the given `a~Int` can't help us with booleans. But you can see how delicate this is! `f` has no principal type, while `g` does, but the difference is very slight. It may be obvious to a naive programmer, but it certainly isn't obvious to GHC. GHC conservatively rejects both. Your program is another variation with an existentially bound type instead of `Int` or `Bool`. 7.6.3 simply had a bug. I have no idea how to improve on this. But that's not to say it could not be improved. Simon So yes, i -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 6 00:24:14 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Dec 2014 00:24:14 -0000 Subject: [GHC] #9223: Type equality makes type variable untouchable In-Reply-To: <048.6ce33f316f2e616ec0311d809cccfbe7@haskell.org> References: <048.6ce33f316f2e616ec0311d809cccfbe7@haskell.org> Message-ID: <063.f37f5c8aca16df110a383435d2a36a4d@haskell.org> #9223: Type equality makes type variable untouchable -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by tvynr): Ah ha! This makes perfect sense; thank you for the excellent example and explanation. In particular, this points out that whether a principled type exists is dependent upon some pretty incidental factors, like whether the output type and the input type happen to have anything in common. I can see why GHC conservatively rejects both of these, since getting it to work would result in a somewhat fragile system. I had previously supposed that the problem was somehow related to the fact that I had two data -- the `TokenType` and the payload -- and that the `a` in the first parameter of `SomeToken` (`t a`) was not being unified with the `a` in the second parameter (`a`) for the purposes of inference. I think I had gotten than impression by the names `a` and `a1` without realizing that one of them arose merely due to the use of `+` in the body. Thanks again! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 6 00:31:58 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Dec 2014 00:31:58 -0000 Subject: [GHC] #2204: Improve 'patterns not matched' warnings In-Reply-To: <047.57470c7515f5d78414f8813f455c57a5@haskell.org> References: <047.57470c7515f5d78414f8813f455c57a5@haskell.org> Message-ID: <062.a58b343876be3c33b12621ce57018bb3@haskell.org> #2204: Improve 'patterns not matched' warnings -------------------------------------+------------------------------------- Reporter: Deewiant | Owner: Type: feature | Status: closed request | Milestone: ? Priority: low | Version: 6.8.2 Component: Compiler | Keywords: Resolution: duplicate | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate Comment: Closing this as a duplicate of #8853, as that one has a more descriptive title ("Surprising mention of unboxed integers in pattern exhaustiveness warning") and a more recent error message. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 6 00:35:40 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Dec 2014 00:35:40 -0000 Subject: [GHC] #9778: Namespace collision detection for promoted types In-Reply-To: <047.2d273cde6d3a8c2e3d4c41837bafa1a1@haskell.org> References: <047.2d273cde6d3a8c2e3d4c41837bafa1a1@haskell.org> Message-ID: <062.faf1dbafb9fd1ec023960ba5621b94c2@haskell.org> #9778: Namespace collision detection for promoted types -------------------------------------+------------------------------------- Reporter: crockeea | Owner: carlostome Type: feature | Status: patch request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: newcomer Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: T9778 | Blocking: | Differential Revisions: Phab:D534 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"87160c1a5e5c742de176b29d8c3a596fba0983cf/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="87160c1a5e5c742de176b29d8c3a596fba0983cf" renamer: fix trac issue #9778 Summary: Added flag -fwarn-unticked-promoted-constructors Test Plan: test T9778 under tests/rename/should_compile Reviewers: jstolarek, simonpj, austin Reviewed By: jstolarek, simonpj, austin Subscribers: simonpj, goldfire, jstolarek, thomie, carter Differential Revision: https://phabricator.haskell.org/D534 GHC Trac Issues: #9778 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 6 00:35:40 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Dec 2014 00:35:40 -0000 Subject: [GHC] #9777: -msse flag could be handled better by the driver In-Reply-To: <048.88cd2728642e9e3324eafc4b0b8a5a49@haskell.org> References: <048.88cd2728642e9e3324eafc4b0b8a5a49@haskell.org> Message-ID: <063.fdb59828667faf96a08ba8d20dacb7aa@haskell.org> #9777: -msse flag could be handled better by the driver -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: dredozubov Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 7.9 Resolution: | Keywords: newcomer Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Moderate (less Type of failure: Other | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: #8404 Differential Revisions: Phab:D504 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"da98592026154264d529e2e235ff396dfd6e7c51/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="da98592026154264d529e2e235ff396dfd6e7c51" msse flag handling: fix trac issue #9777 Summary: Signed-off-by: Denis Redozubov SSE version handled by different dynamic flags Signed-off-by: Denis Redozubov Test Plan: validate Reviewers: austin, jstolarek Reviewed By: austin, jstolarek Subscribers: kolmodin, thomie, carter Differential Revision: https://phabricator.haskell.org/D504 GHC Trac Issues: #9777 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 6 00:35:40 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Dec 2014 00:35:40 -0000 Subject: [GHC] #9859: Implement `calloc{, Bytes, Array, Array0}` allocators In-Reply-To: <048.c0f4fa20de1f948bcce2872a450643e7@haskell.org> References: <048.c0f4fa20de1f948bcce2872a450643e7@haskell.org> Message-ID: <063.2bf548473fb60a3bd84d52157ad8d0b1@haskell.org> #9859: Implement `calloc{,Bytes,Array,Array0}` allocators -------------------------------------+------------------------------------- Reporter: ifesdjeen | Owner: Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: Component: Core | Keywords: ffi Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D527 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"08610c1fdc7816c74faed40f8a7d3c4b4758709e/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="08610c1fdc7816c74faed40f8a7d3c4b4758709e" Implement `calloc{,Bytes,Array,Array0}` allocators Summary: This adds zero-initialising versions of `malloc{,Bytes,Array,Array0}` * Add `calloc` and `callocBytes` to `Foreign.Marshal.Alloc`. * Add `callocArray` and `callocArray0` to `Foreign.Marshal.Array`. Reviewers: ekmett, duncan, austin, hvr Reviewed By: austin, hvr Subscribers: ezyang, simonmar, ekmett, duncan, thomie, carter Projects: #ghc Differential Revision: https://phabricator.haskell.org/D527 GHC Trac Issues: #9859 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 6 03:18:59 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Dec 2014 03:18:59 -0000 Subject: [GHC] #2273: inlining defeats seq In-Reply-To: <044.9c3223a55b4d3223b10ccf35be7e7d4f@haskell.org> References: <044.9c3223a55b4d3223b10ccf35be7e7d4f@haskell.org> Message-ID: <059.85aacac8ddf09188398f0031d32add66@haskell.org> #2273: inlining defeats seq -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: lowest | Milestone: 7.10.1 Component: Compiler | Version: 6.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): I've seen some remarks in the ghc source tree about having the desugaring use seq#, but I didnt see any usage of it in ghc proper as far as I could tell. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 6 03:22:44 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Dec 2014 03:22:44 -0000 Subject: [GHC] #5289: Can't use ghci with a library linked against libstdc++ In-Reply-To: <042.ca5f68f0f4907cc12990f083dfa50f2f@haskell.org> References: <042.ca5f68f0f4907cc12990f083dfa50f2f@haskell.org> Message-ID: <057.f2ce4de8ea056796b6d48509603a5582@haskell.org> #5289: Can't use ghci with a library linked against libstdc++ -------------------------------------+------------------------------------ Reporter: bos | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: GHCi | Version: 7.0.3 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------ Changes (by RyanGlScott): * cc: ryan.gl.scott@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 6 10:38:01 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Dec 2014 10:38:01 -0000 Subject: [GHC] #9777: -msse flag could be handled better by the driver In-Reply-To: <048.88cd2728642e9e3324eafc4b0b8a5a49@haskell.org> References: <048.88cd2728642e9e3324eafc4b0b8a5a49@haskell.org> Message-ID: <063.945779a946c416ba6a77519e98f4b2cc@haskell.org> #9777: -msse flag could be handled better by the driver -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: dredozubov Type: bug | Status: closed Priority: normal | Milestone: Component: Driver | Version: 7.9 Resolution: fixed | Keywords: newcomer Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Moderate (less Type of failure: Other | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: #8404 Differential Revisions: Phab:D504 | -------------------------------------+------------------------------------- Changes (by dredozubov): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 6 12:10:47 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Dec 2014 12:10:47 -0000 Subject: [GHC] #9859: Implement `calloc{, Bytes, Array, Array0}` allocators In-Reply-To: <048.c0f4fa20de1f948bcce2872a450643e7@haskell.org> References: <048.c0f4fa20de1f948bcce2872a450643e7@haskell.org> Message-ID: <063.7cc9806b7cc7294c8e8d8d6a8d2c92d8@haskell.org> #9859: Implement `calloc{,Bytes,Array,Array0}` allocators -------------------------------------+------------------------------------- Reporter: ifesdjeen | Owner: Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: Component: Core | Keywords: ffi Libraries | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D527 | -------------------------------------+------------------------------------- Changes (by hvr): * status: patch => closed * resolution: => fixed Comment: patch landed; let's close this for now -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 6 12:12:26 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Dec 2014 12:12:26 -0000 Subject: [GHC] #5966: getAppUserDataDirectory does not respect XDG specification In-Reply-To: <047.bc37781e7713df0d1b7455991f78caf3@haskell.org> References: <047.bc37781e7713df0d1b7455991f78caf3@haskell.org> Message-ID: <062.50542e718b260b9adf6f56930d6ba47c@haskell.org> #5966: getAppUserDataDirectory does not respect XDG specification -------------------------------------+------------------------------------- Reporter: ordcoder | Owner: ekmett Type: bug | Status: upstream Priority: normal | Milestone: 7.12.1 Component: Core | Version: 7.4.1 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: result at runtime | Test Case: | Blocking: 6077 | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by hvr): * milestone: 7.10.1 => 7.12.1 Comment: There's still unresolved issues on how to properly address this one. Better punt this to milestone:7.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 6 19:22:00 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Dec 2014 19:22:00 -0000 Subject: [GHC] #9869: Add new notation for negative numbers when using -XNegativeLiterals Message-ID: <042.9c0412be94a5a419d38acd055f8c8eeb@haskell.org> #9869: Add new notation for negative numbers when using -XNegativeLiterals -------------------------------------+------------------------------------- Reporter: bg_ | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I propose that when using -XNegativeLiterals ghc should also read ~123 as a negative literal. SML uses ~ as the unary minus it, so it's not completely out of the blue. The reason would be to minimize ambiguity. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 6 19:25:14 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Dec 2014 19:25:14 -0000 Subject: [GHC] #9869: Add new notation for negative numbers when using -XNegativeLiterals In-Reply-To: <042.9c0412be94a5a419d38acd055f8c8eeb@haskell.org> References: <042.9c0412be94a5a419d38acd055f8c8eeb@haskell.org> Message-ID: <057.3686f12f92c3984ac31b53c468c02313@haskell.org> #9869: Add new notation for negative numbers when using -XNegativeLiterals -------------------------------------+------------------------------------- Reporter: bg_ | Owner: Type: feature | Status: new request | Milestone: Priority: low | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Description changed by bg_: Old description: > I propose that when using -XNegativeLiterals ghc should also read ~123 as > a negative literal. SML uses ~ as the unary minus it, so it's not > completely out of the blue. The reason would be to minimize ambiguity. New description: I propose that when using -XNegativeLiterals ghc should also read ~123 as a negative literal. SML uses ~ as the unary minus, so it's not completely out of the blue. The reason would be to minimize ambiguity. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 6 19:25:27 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Dec 2014 19:25:27 -0000 Subject: [GHC] #9869: Add new notation for negative numbers when using -XNegativeLiterals In-Reply-To: <042.9c0412be94a5a419d38acd055f8c8eeb@haskell.org> References: <042.9c0412be94a5a419d38acd055f8c8eeb@haskell.org> Message-ID: <057.10cde940b5fe8e44a0c1c83ae15b6498@haskell.org> #9869: Add new notation for negative numbers when using -XNegativeLiterals -------------------------------------+------------------------------------- Reporter: bg_ | Owner: bg_ Type: feature | Status: new request | Milestone: Priority: low | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by bg_): * owner: => bg_ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 6 19:27:59 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Dec 2014 19:27:59 -0000 Subject: [GHC] #9869: Add new notation for negative numbers when using {-# LANGUAGE NegativeLiterals #-} (was: Add new notation for negative numbers when using -XNegativeLiterals) In-Reply-To: <042.9c0412be94a5a419d38acd055f8c8eeb@haskell.org> References: <042.9c0412be94a5a419d38acd055f8c8eeb@haskell.org> Message-ID: <057.bc836c00181d9aa32ffde1b895798ee7@haskell.org> #9869: Add new notation for negative numbers when using {-# LANGUAGE NegativeLiterals #-} -------------------------------------+------------------------------------- Reporter: bg_ | Owner: bg_ Type: feature | Status: new request | Milestone: Priority: low | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 6 19:28:37 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Dec 2014 19:28:37 -0000 Subject: [GHC] #9869: Add new notation for negative numbers when using {-# LANGUAGE NegativeLiterals #-} In-Reply-To: <042.9c0412be94a5a419d38acd055f8c8eeb@haskell.org> References: <042.9c0412be94a5a419d38acd055f8c8eeb@haskell.org> Message-ID: <057.b70938d39481cdefd8aae78f53263551@haskell.org> #9869: Add new notation for negative numbers when using {-# LANGUAGE NegativeLiterals #-} -------------------------------------+------------------------------------- Reporter: bg_ | Owner: bg_ Type: feature | Status: new request | Milestone: Priority: low | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Description changed by bg_: Old description: > I propose that when using -XNegativeLiterals ghc should also read ~123 as > a negative literal. SML uses ~ as the unary minus, so it's not completely > out of the blue. The reason would be to minimize ambiguity. New description: I propose that when using {-# LANGUAGE NegativeLiterals #-} ghc should also read ~123 as a negative literal. SML uses ~ as the unary minus, so it's not completely out of the blue. The reason would be to minimize ambiguity. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 6 19:58:27 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Dec 2014 19:58:27 -0000 Subject: [GHC] #9813: Error when reifying type constructor In-Reply-To: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> References: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> Message-ID: <058.fab21be2763eca71be56c4c836287853@haskell.org> #9813: Error when reifying type constructor -------------------------------------+------------------------------------- Reporter: owst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: ryan.gl.scott@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 6 20:26:16 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Dec 2014 20:26:16 -0000 Subject: [GHC] #9869: Add new notation for negative numbers when using {-# LANGUAGE NegativeLiterals #-} In-Reply-To: <042.9c0412be94a5a419d38acd055f8c8eeb@haskell.org> References: <042.9c0412be94a5a419d38acd055f8c8eeb@haskell.org> Message-ID: <057.fca41004dccc5f42f779b11e215af3e9@haskell.org> #9869: Add new notation for negative numbers when using {-# LANGUAGE NegativeLiterals #-} -------------------------------------+------------------------------------- Reporter: bg_ | Owner: bg_ Type: feature | Status: closed request | Milestone: Priority: low | Version: 7.8.3 Component: Compiler | Keywords: Resolution: invalid | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by carter): * status: new => closed * resolution: => invalid Comment: ~ is already used by haskell for type equality in constraints, eg `(size ~7 )=> SizedList size Int` so its not clear how adding a new meaning for ~ would improve matters. closing this as invalid baring discussion on libraries list, ghc-users, ghc-devs or #ghc irc channel to the contrary. (that is, some additional discussion should happen on a mailing list for this proprosal to have teeth.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 6 21:16:57 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Dec 2014 21:16:57 -0000 Subject: [GHC] #9223: Type equality makes type variable untouchable In-Reply-To: <048.6ce33f316f2e616ec0311d809cccfbe7@haskell.org> References: <048.6ce33f316f2e616ec0311d809cccfbe7@haskell.org> Message-ID: <063.751838e74747959a2d0e5a4831afbe74@haskell.org> #9223: Type equality makes type variable untouchable -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:8 simonpj]: > What about `g`? Here we have "given" `a~Int`, but the same wanted constraint is `beta~Bool` is generated. Now there is only one solution, namely `beta:=Bool`, because the given `a~Int` can't help us with booleans. I would argue that `g` does ''not'' have a principal type. It can be given the type `T a -> Bool`, but it can also be given the type `T a -> F a`, where `F Int = Bool`. If no such `F` is in scope at the time of the definition of `g`, I suppose it ''does'' have the principal type you suggest, but predicating the principality of types based on what's in scope is terribly fragile, and so my personal definition of "principal type" includes the possibility of type functions defined later. @tvynr's example is different, I think, in that it seems there is a principal type no matter what other type-level definitions are available. Without thinking about the details, I conjecture that it's possible to detect variables whose scopes are appropriate w.r.t. the available equalities such that we can declare these variables to be touchable, where universally-quantified variables would be untouchable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 7 06:51:38 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Dec 2014 06:51:38 -0000 Subject: [GHC] #5850: Greater customization of GHCi prompt In-Reply-To: <050.bf03c3e2cbefdd0fabbaa545b275f2dc@haskell.org> References: <050.bf03c3e2cbefdd0fabbaa545b275f2dc@haskell.org> Message-ID: <065.0944b077439b56aecc8cbbb2a2a2e32d@haskell.org> #5850: Greater customization of GHCi prompt -------------------------------------+------------------------------------- Reporter: | Owner: jlengyel JamesFisher | Status: patch Type: feature | Milestone: 7.10.1 request | Version: 7.4.1 Priority: normal | Keywords: newcomer Component: GHCi | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D559 | -------------------------------------+------------------------------------- Changes (by jlengyel): * status: new => patch * differential: => Phab:D559 Comment: With this change, the :set prompt command will take an expression of type [String] -> Int -> IO String, and apply it with the current list of imports and current line number to generate the GHCi prompt. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 7 10:05:40 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Dec 2014 10:05:40 -0000 Subject: [GHC] #8951: genSym uses atomic_inc but doesn't link arm_atomic_spin_lock In-Reply-To: <047.6361bb2814dd444a3dfd661ef69cb2b7@haskell.org> References: <047.6361bb2814dd444a3dfd661ef69cb2b7@haskell.org> Message-ID: <062.9a9dadd18302e598a286f697bda28395@haskell.org> #8951: genSym uses atomic_inc but doesn't link arm_atomic_spin_lock -------------------------------------+------------------------------------- Reporter: cjwatson | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: Build | Version: 7.8.1-rc1 System | Keywords: Resolution: | Architecture: arm Operating System: Linux | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by nomeata): * milestone: 7.10.1 => 7.8.4 Comment: Moving milestone back to 7.8 branch, this is worth a stable update, if a fix is available. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 7 10:27:00 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Dec 2014 10:27:00 -0000 Subject: [GHC] #2522: Warning for missing export lists In-Reply-To: <042.bc97894bc85aa965fac36f83804d8ebb@haskell.org> References: <042.bc97894bc85aa965fac36f83804d8ebb@haskell.org> Message-ID: <057.a821777a836cb92fd189abeec8466c6f@haskell.org> #2522: Warning for missing export lists -------------------------------------+------------------------------------- Reporter: tim | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: lowest | Version: 6.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by NeilMitchell): Yes, HLint could do that. The Standard Chartered Haskell compiler already warns about missing export lists, and then if you really want to omit the export list you use the module export syntax Ian suggested above. The warning also emits what the export list should be to keep exporting everything, which is a handy feature. I suspect this fits better as a GHC warning (it seems sufficiently like the other existing warnings), but I'd certainly accept an HLint patch, and then perhaps remove it if it was ever added to GHC. If GHC is likely to punt on this warning for the foreseeable future, please raise an HLint ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 7 14:29:15 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Dec 2014 14:29:15 -0000 Subject: [GHC] #9831: the 'impossible' happened : iselExpr64(powerpc) In-Reply-To: <044.1090bf2d6b74a28254c5352399819de1@haskell.org> References: <044.1090bf2d6b74a28254c5352399819de1@haskell.org> Message-ID: <059.e37d6360166ef32c659088181c543508@haskell.org> #9831: the 'impossible' happened : iselExpr64(powerpc) ----------------------------------------------+--------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.9 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: Phab:D560 | ----------------------------------------------+--------------------------- Changes (by thomie): * cc: simonmar (added) * differential: => Phab:D560 * component: Compiler => Compiler (NCG) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 7 14:51:21 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Dec 2014 14:51:21 -0000 Subject: [GHC] #9870: Document deviation of Data.List.splitAt from Report semantics Message-ID: <045.434428ec5e3302df507a7c2131cd8582@haskell.org> #9870: Document deviation of Data.List.splitAt from Report semantics -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Documentation | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | Documentation bug Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D562 -------------------------------------+------------------------------------- `Data.List.splitAt` is strict in its first argument. The Report specifies that `splitAt n xs = (take n xs, drop n xs)`. This should be noted in the user's guide. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 7 15:51:35 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Dec 2014 15:51:35 -0000 Subject: [GHC] #7015: Add support for 'static' In-Reply-To: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> References: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> Message-ID: <059.2f4b5de83ce2d68b51447fbc20713d6b@haskell.org> #7015: Add support for 'static' -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.4.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D550 | -------------------------------------+------------------------------------- Changes (by facundo.dominguez): * status: new => patch * differential: Phab:D119 => Phab:D550 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 7 18:45:03 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Dec 2014 18:45:03 -0000 Subject: [GHC] #8951: genSym uses atomic_inc but doesn't link arm_atomic_spin_lock In-Reply-To: <047.6361bb2814dd444a3dfd661ef69cb2b7@haskell.org> References: <047.6361bb2814dd444a3dfd661ef69cb2b7@haskell.org> Message-ID: <062.e54315b96e1532270bca1917838f91eb@haskell.org> #8951: genSym uses atomic_inc but doesn't link arm_atomic_spin_lock -------------------------------------+------------------------------------- Reporter: cjwatson | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: Build | Version: 7.8.1-rc1 System | Keywords: Resolution: | Architecture: arm Operating System: Linux | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: bgamari (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 7 21:50:05 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Dec 2014 21:50:05 -0000 Subject: [GHC] #8951: genSym uses atomic_inc but doesn't link arm_atomic_spin_lock In-Reply-To: <047.6361bb2814dd444a3dfd661ef69cb2b7@haskell.org> References: <047.6361bb2814dd444a3dfd661ef69cb2b7@haskell.org> Message-ID: <062.19968d3622a7daa030d1f7928726addf@haskell.org> #8951: genSym uses atomic_inc but doesn't link arm_atomic_spin_lock -------------------------------------+------------------------------------- Reporter: cjwatson | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: Build | Version: 7.8.1-rc1 System | Keywords: Resolution: | Architecture: arm Operating System: Linux | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by bgamari): Hmm, so the symbols in question are defined in `rts/OldARMAtomic.c`. These are necessary as this build occurred on an ARMv5 box. It appears `OldARMAtomic.o` is being compiled into `libRTS` so this raises the question of why it's not being found by the linker. nomeata, however, is doing his builds on ARMv7 hardware. In light of this it's likely that there are two bugs here: 1. nomeata's build is using the pre-ARMv6 fallbacks unnecessarily 2. the pre-ARMv6 fallbacks aren't compiled/linked properly -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 7 22:08:59 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Dec 2014 22:08:59 -0000 Subject: [GHC] #8951: genSym uses atomic_inc but doesn't link arm_atomic_spin_lock In-Reply-To: <047.6361bb2814dd444a3dfd661ef69cb2b7@haskell.org> References: <047.6361bb2814dd444a3dfd661ef69cb2b7@haskell.org> Message-ID: <062.83af1b2e6140bcfb5052bc843ff0845d@haskell.org> #8951: genSym uses atomic_inc but doesn't link arm_atomic_spin_lock -------------------------------------+------------------------------------- Reporter: cjwatson | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: Build | Version: 7.8.1-rc1 System | Keywords: Resolution: | Architecture: arm Operating System: Linux | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nomeata): More info: `genSym.c` is linked into libghcHS. It contains code that depends on `THREADED_RTS`, but that?s a bit fishy: There is only one `libghcHS` that needs to work with both threaded and non-threaded RTSs. This code in `compiler/ghc.mk` might be related: {{{ ifeq "$(GhcThreaded)" "YES" # We pass THREADED_RTS to the stage2 C files so that cbits/genSym.c will bring # the threaded version of atomic_inc() into scope. compiler_stage2_CONFIGURE_OPTS += --ghc-option=-optc-DTHREADED_RTS endif }}} So one thing I?m trying is to provide the stubs from `rts/OldARMAtomic.c` even in the unthreaded RTS. It will be dead code, but at least the linker will be happy. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 7 22:14:36 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Dec 2014 22:14:36 -0000 Subject: [GHC] #9552: powerpc64 little endian: dll-split: Reachable modules from DynFlags out of date In-Reply-To: <047.a5a0d83a85e9f507ac92882847117a99@haskell.org> References: <047.a5a0d83a85e9f507ac92882847117a99@haskell.org> Message-ID: <062.3eabf2cd3eb4cc9ae2674bb053db5f67@haskell.org> #9552: powerpc64 little endian: dll-split: Reachable modules from DynFlags out of date -------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Building | Difficulty: Unknown GHC failed | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: bgamari (added) Comment: Perhaps it would be a good idea to apply this in 7.8 as well? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 7 22:30:05 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Dec 2014 22:30:05 -0000 Subject: [GHC] #9871: Template Haskell declaration splice causes subsequent declarations to fall out of scope Message-ID: <050.2e1226ec0f1aa6f869cadabe53509976@haskell.org> #9871: Template Haskell declaration splice causes subsequent declarations to fall out of scope -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: GHC Blocked By: | rejects valid program Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- When using Template Haskell to splice in {{{instance}}} declarations, it is possible to cause identifiers following it to fall out of scope: {{{#!hs -- DeriveJSON.hs {-# LANGUAGE TemplateHaskell #-} module DeriveJSON where import Data.Aeson.TH data ADT = ADT instance Show ADT where show = adtFun $(deriveJSON defaultOptions ''ADT) adtFun :: ADT -> String adtFun = undefined }}} {{{ghc DeriveJSON.hs}}} gives the following error: {{{ [1 of 1] Compiling DeriveJSON ( DeriveJSON.hs, DeriveJSON.o ) DeriveJSON.hs:10:18: Not in scope: ?adtFun? }}} Since {{{deriveJSON}}} simply returns a {{{Q [Dec]}}}, I don't see why this code shouldn't compile as is. I can find two workarounds at the moment: * Move the {{{instance Show ADT}}} declaration after the {{{$(deriveJSON defaultOptions ''ADT)}}} line. * Move the {{{$(deriveJSON defaultOptions ''ADT)}}} line after the {{{adtFun}}} function declaration. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 7 22:48:32 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Dec 2014 22:48:32 -0000 Subject: [GHC] #9552: powerpc64 little endian: dll-split: Reachable modules from DynFlags out of date In-Reply-To: <047.a5a0d83a85e9f507ac92882847117a99@haskell.org> References: <047.a5a0d83a85e9f507ac92882847117a99@haskell.org> Message-ID: <062.429ca3382435decb9c1a2c327230e9db@haskell.org> #9552: powerpc64 little endian: dll-split: Reachable modules from DynFlags out of date -------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Building | Difficulty: Unknown GHC failed | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by slyfox): Yeah, it can easily be re-fixed for stable branch, but GHCi-less setup is usually our real bug :) Do you have an arch which suffers from it in ghc-7.8? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 8 03:31:46 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Dec 2014 03:31:46 -0000 Subject: [GHC] #8984: Improve output of failed GeneralizedNewtypeDeriving coercion due to type roles In-Reply-To: <044.9146c0f21c1d5c0ac4fad078a63640bb@haskell.org> References: <044.9146c0f21c1d5c0ac4fad078a63640bb@haskell.org> Message-ID: <059.6c5b74fde15eee94e1cedb2be53afd77@haskell.org> #8984: Improve output of failed GeneralizedNewtypeDeriving coercion due to type roles -------------------------------------+------------------------------------- Reporter: haasn | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.1 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): Refactoring in my branch has added a small wrinkle here: my version currently ''accepts'' the original code. Let's be concrete: {{{ {-# LANGUAGE ConstraintKinds, GeneralizedNewtypeDeriving #-} module T8984 where class C a where app :: a (a Int) newtype N cat a b = MkN (cat a b) deriving( C ) }}} yields an instance {{{ instance (Coercible (cat a (N cat a Int)) (cat a (cat a Int)), C (cat a)) => C (N cat a) }}} This is actually perfectly sound: GHC is just choosing to abstract over the unprovable `Coercible` constraint. What do we think of this behavior? Is it desired or not? This seems to be a free choice here: I don't think either option or the other would affect much else. Implementation note: This is a direct consequence of changes to `TcValidity.validDerivPred`. Previously (that is, in today's HEAD), a `Coercible` constraint looked like a class constraint, meaning it was checked to make sure that it wasn't too exotic. In my branch, (`wip/rae- new-coercible`) `Coercible` constraints are like equalities, which are allowed unchecked. Thus, the rather exotic constraint above is allowed. This has all gotten me thinking: Why ''do'' we blithely allow equality constraints to be in a derived-inferred context? This ability was added in response to #6088, where the user wanted to use GND to derive an instance based on another instance with an explicit equality in the context. Here is the example from #6088: {{{ class C a newtype A n = A Int type family Pos n data True instance (Pos n ~ True) => C (A n) newtype B n = B (A n) deriving (C) }}} This is now accepted. However, here is a very similar case: {{{ class C1 a b class C2 a instance C1 a a => C2 (Maybe a) newtype N a = MkN (Maybe a) deriving C2 }}} This second case is rejected. And yet, they're similar in that the exotic context that might be inferred is specified by the user. It seems a little odd to accept one and reject the other. So, I propose the following behavior: * Reject equality constraints to be inferred for `deriving`. * If `deriving` failed solely because of checks in `validDerivPred`, provide the full inferred context in the error message to make it easy for users to work around this restriction. This would, essentially, break the fix for #6088, and would thus be a regression, because 7.8 incorporates the #6088 fix. But, with the enhanced error message, the breakage would be easy to fix. What do folks think? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 8 11:45:08 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Dec 2014 11:45:08 -0000 Subject: [GHC] #9872: Runing type functions is too slow Message-ID: <046.39f8cd7bfe0ce27cb6afb75f2059ad40@haskell.org> #9872: Runing type functions is too slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Gergo reports, prompted by [http://stackoverflow.com/questions/26538595/more-efficient-type-level- computations-using-type-families this question on Stack Overflow]. I wrote some code today using closed type families and datakinds. Also, as a baseline, I typechecked the code using open type families from the original question. The two files are attached as slow1.hs and slow2.hs below. On GHC 7.8.3, typechecking took about 45 seconds for each. However, on a 'perf' build of GHC 7.9 d8c437b3, with ghc-stage2, the first one took 1m3s and the second one 1m12s. A 40% and 60% increase in typechecking time, respectively! Is this some known regression, something surprising, or is 'perf' simply not the right build flavour for this kind of comparison? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 8 11:47:51 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Dec 2014 11:47:51 -0000 Subject: [GHC] #9872: Runing type functions is too slow In-Reply-To: <046.39f8cd7bfe0ce27cb6afb75f2059ad40@haskell.org> References: <046.39f8cd7bfe0ce27cb6afb75f2059ad40@haskell.org> Message-ID: <061.ff76f063739dbd03ae555e881375d9a6@haskell.org> #9872: Runing type functions is too slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: goldfire, cactus, dimitris@? (added) Old description: > Gergo reports, prompted by > [http://stackoverflow.com/questions/26538595/more-efficient-type-level- > computations-using-type-families this question on Stack Overflow]. > > I wrote some code today using closed type families and datakinds. Also, > as a baseline, I typechecked the code using open type families from the > original question. > > The two files are attached as slow1.hs and slow2.hs below. > > On GHC 7.8.3, typechecking took about 45 seconds for each. However, on a > 'perf' build of GHC 7.9 d8c437b3, with ghc-stage2, the first one took > 1m3s and the second one 1m12s. A 40% and 60% increase in typechecking > time, respectively! > > Is this some known regression, something surprising, or is 'perf' simply > not the right build flavour for this kind of comparison? New description: Gergo reports, prompted by [http://stackoverflow.com/questions/26538595 /more-efficient-type-level-computations-using-type-families this question on Stack Overflow]. I wrote some code today using closed type families and datakinds. Also, as a baseline, I typechecked the code using open type families from the original question. The two files are attached as slow1.hs and slow2.hs below. On GHC 7.8.3, typechecking took about 45 seconds for each. However, on a 'perf' build of GHC 7.9 d8c437b3, with ghc-stage2, the first one took 1m3s and the second one 1m12s. A 40% and 60% increase in typechecking time, respectively! Is this some known regression, something surprising, or is 'perf' simply not the right build flavour for this kind of comparison? -- Comment: Very helpful examples. Working on them. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 8 11:59:53 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Dec 2014 11:59:53 -0000 Subject: [GHC] #9872: Runing type functions is too slow In-Reply-To: <046.39f8cd7bfe0ce27cb6afb75f2059ad40@haskell.org> References: <046.39f8cd7bfe0ce27cb6afb75f2059ad40@haskell.org> Message-ID: <061.c25d1d0ebb3e300e52d2c85e8f9636bb@haskell.org> #9872: Runing type functions is too slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Some diagnosis: * 90%+ of compile time is being spent in `TrieMap` code, called from `partitionFunEqs`, called from `kick_out` in the constraint solver. Here are the top cost centres in a profiled compiler. {{{ COST CENTRE MODULE %time %alloc fdT TrieMap 36.7 44.8 fdList TrieMap 13.4 16.8 foldTyLit TrieMap 10.9 17.2 fdVar TrieMap 8.2 11.1 foldMaybe TrieMap 3.7 1.3 foldUFM UniqFM 3.7 1.5 lm_nil TrieMap 2.3 0.0 lm_cons TrieMap 1.9 0.0 mapUnionVarSet VarSet 1.5 1.1 tlm_string TrieMap 1.2 0.0 foldTM TrieMap 1.1 0.7 }}} * The inert set has up to 150 inert `CFunEqCans`. That's absurd. I think I know how to reduce it dramatically by improving the order in which goals are solved. * Each call to `kick_out` requires us to look at each of the 150 inert items, in case it mentions the newly-assigned variable. (This is already quadratic, hence wanting to minimise the size of the inert set.)[[BR]][[BR]] But `partitionFunEqs` '''still''' should not be so expensive. Part of the reason turned out to be the use of a `TrieMap`. Suppose a `TrieMap` has exactly one item in it, with a big key, like `A (K C D E F) (K E D C F)` etc. Then the `TrieMap` will have a long string of singleton UFMs etc to represent it. That's not a very clever representation; simply to reconstruct a copy takes time proportional to the size of the key.[[BR]][[BR]] I think the solution may be to give `TrieMaps` a special case for singleton maps, which does not invert the kay. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 8 12:38:05 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Dec 2014 12:38:05 -0000 Subject: [GHC] #9872: Runing type functions is too slow In-Reply-To: <046.39f8cd7bfe0ce27cb6afb75f2059ad40@haskell.org> References: <046.39f8cd7bfe0ce27cb6afb75f2059ad40@haskell.org> Message-ID: <061.77fd84b00e9e2119143579e1c5e5a24a@haskell.org> #9872: Runing type functions is too slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): This all begs a question I've wondered several times: Flattening in the solver is great when we have bits of a type that are unknown, like `F (Int, a)`. But, it seems like an awful lot of work to do when a type is fully known, such as `F Bool`. In the latter case, is there a reason we don't use `normaliseType`? It would seem to me that this all would get more efficient if we just called `normaliseType` as an early step in the process, say in `flattenFamApp`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 8 12:44:05 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Dec 2014 12:44:05 -0000 Subject: [GHC] #9808: Add data-dir to InstalledPackageInfo In-Reply-To: <044.d7df9b805388be68f8a820b34b606910@haskell.org> References: <044.d7df9b805388be68f8a820b34b606910@haskell.org> Message-ID: <059.ed8baaa907d0b22bac7ca1f35ec30ef5@haskell.org> #9808: Add data-dir to InstalledPackageInfo -------------------------------------+------------------------------------- Reporter: luite | Owner: luite Type: task | Status: infoneeded Priority: normal | Milestone: 7.10.1 Component: Package | Version: 7.8.3 system | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D499 | -------------------------------------+------------------------------------- Comment (by luite): this can be closed for now. in ghc 7.10 i can do what i need with just the Cabal change, but it's not a terribly clean solution. might revisit this for 7.12 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 8 12:45:05 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Dec 2014 12:45:05 -0000 Subject: [GHC] #9808: Add data-dir to InstalledPackageInfo In-Reply-To: <044.d7df9b805388be68f8a820b34b606910@haskell.org> References: <044.d7df9b805388be68f8a820b34b606910@haskell.org> Message-ID: <059.4fa0de2c86ba162ee85f08a92c9e0150@haskell.org> #9808: Add data-dir to InstalledPackageInfo -------------------------------------+------------------------------------- Reporter: luite | Owner: luite Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: Package | Version: 7.8.3 system | Keywords: Resolution: wontfix | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D499 | -------------------------------------+------------------------------------- Changes (by luite): * status: infoneeded => closed * resolution: => wontfix -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 8 14:21:55 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Dec 2014 14:21:55 -0000 Subject: [GHC] #9872: Runing type functions is too slow In-Reply-To: <046.39f8cd7bfe0ce27cb6afb75f2059ad40@haskell.org> References: <046.39f8cd7bfe0ce27cb6afb75f2059ad40@haskell.org> Message-ID: <061.d02e26307fb091b256ce0b067f2cb81d@haskell.org> #9872: Runing type functions is too slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by jstolarek): * cc: jstolarek (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 8 14:41:32 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Dec 2014 14:41:32 -0000 Subject: [GHC] #9569: Tuple constraints don't work right In-Reply-To: <046.31f45b75873be125a1cc8887558fe856@haskell.org> References: <046.31f45b75873be125a1cc8887558fe856@haskell.org> Message-ID: <061.9a45697d8b89a708c8f3b26414168812@haskell.org> #9569: Tuple constraints don't work right -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | polykinds/T9569, | typecheck/should_compile/T9569a | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by luite): The commit for this changes behaviour of impredicative types, the following does not typecheck anymore: {{{#!hs {-# LANGUAGE ImpredicativeTypes #-} f :: ((forall a. a -> a) -> b) -> b f x = x id g :: ((a -> b) -> c) -> ((a -> b) -> c) g = id h :: ((forall a. a -> a) -> b) -> b h = g f }}} I get the following error: {{{ test.hs:10:7: Couldn't match expected type ?forall a. a -> a? with actual type ?a0 -> a0? In the first argument of ?g?, namely ?f? In the expression: g f Failed, modules loaded: none. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 8 15:02:02 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Dec 2014 15:02:02 -0000 Subject: [GHC] #9872: Runing type functions is too slow In-Reply-To: <046.39f8cd7bfe0ce27cb6afb75f2059ad40@haskell.org> References: <046.39f8cd7bfe0ce27cb6afb75f2059ad40@haskell.org> Message-ID: <061.e694e1afa97f3c4dd6bf35baca27d77f@haskell.org> #9872: Runing type functions is too slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"37c2ed4bc3d4ff0a4681e9d27c7f748886e413f6/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="37c2ed4bc3d4ff0a4681e9d27c7f748886e413f6" Optimise partitionFunEqs for the 'false' case In the examples from Trac #9872 we were getting a large set of inert CFunEqCans, and partitioning them was taking ages. This patch improves it somewhat by optimising the partition for the case where the predicat is false. The ticket has more info. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 8 15:20:26 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Dec 2014 15:20:26 -0000 Subject: [GHC] #9847: Remove "Difficulty" field from the Trac In-Reply-To: <048.2f318234beb94b756753871fe44a2045@haskell.org> References: <048.2f318234beb94b756753871fe44a2045@haskell.org> Message-ID: <063.21c56a146944e32032b2ce0c3c78e145@haskell.org> #9847: Remove "Difficulty" field from the Trac -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by luite): * difficulty: Unknown => Easy (less than 1 hour) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 8 15:36:32 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Dec 2014 15:36:32 -0000 Subject: [GHC] #9872: Runing type functions is too slow In-Reply-To: <046.39f8cd7bfe0ce27cb6afb75f2059ad40@haskell.org> References: <046.39f8cd7bfe0ce27cb6afb75f2059ad40@haskell.org> Message-ID: <061.40cf0774ebace15142ee9de447863a8f@haskell.org> #9872: Runing type functions is too slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Replying to [comment:3 goldfire]: > This all begs a question I've wondered several times: Flattening in the solver is great when we have bits of a type that are unknown, like `F (Int, a)`. But, it seems like an awful lot of work to do when a type is fully known, such as `F Bool`. In the latter case, is there a reason we don't use `normaliseType`? It would seem to me that this all would get more efficient if we just called `normaliseType` as an early step in the process, say in `flattenFamApp`. Reasonable question. But if we had {{{ Eq (F (P Q R) (G (H (F (G (H a Int)))))) }}} there's a risk of trying to normalise at the outer level, and then at every inner level, which would not be very clever. I'll think about this a bit more. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 8 15:49:54 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Dec 2014 15:49:54 -0000 Subject: [GHC] #9872: Runing type functions is too slow In-Reply-To: <046.39f8cd7bfe0ce27cb6afb75f2059ad40@haskell.org> References: <046.39f8cd7bfe0ce27cb6afb75f2059ad40@haskell.org> Message-ID: <061.8aa05c713d3a271ab11730bfe114cdc9@haskell.org> #9872: Runing type functions is too slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): Recall that `normaliseType` does "deep" normalisation, not just at top level -- it recursively tries to normalise all arguments. And, I don't think it would take long for it to try. If `normaliseType` doesn't remove a top-level type function, then flatten as normal, but it's still possible some good progress was made below top level. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 8 15:59:15 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Dec 2014 15:59:15 -0000 Subject: [GHC] #9871: Template Haskell declaration splice causes subsequent declarations to fall out of scope In-Reply-To: <050.2e1226ec0f1aa6f869cadabe53509976@haskell.org> References: <050.2e1226ec0f1aa6f869cadabe53509976@haskell.org> Message-ID: <065.1d4479dffc96cae76132f7d9d636d8d4@haskell.org> #9871: Template Haskell declaration splice causes subsequent declarations to fall out of scope -------------------------------------+------------------------------------- Reporter: | Owner: RyanGlScott | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Template | Keywords: Haskell | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: GHC | rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"b06908b5a120ed56df5416019c38576aadcd21e2/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="b06908b5a120ed56df5416019c38576aadcd21e2" Fix #9871 by clarifying documentation. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 8 16:02:18 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Dec 2014 16:02:18 -0000 Subject: [GHC] #9871: Template Haskell declaration splice causes subsequent declarations to fall out of scope In-Reply-To: <050.2e1226ec0f1aa6f869cadabe53509976@haskell.org> References: <050.2e1226ec0f1aa6f869cadabe53509976@haskell.org> Message-ID: <065.eef46746f4e4927b0b5a99d72375871f@haskell.org> #9871: Template Haskell declaration splice causes subsequent declarations to fall out of scope -------------------------------------+------------------------------------- Reporter: | Owner: RyanGlScott | Status: closed Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: | Keywords: Documentation | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: GHC | rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => fixed * component: Template Haskell => Documentation Comment: This is by design, but I've tweaked the TH documentation to make this more apparent. A top-level declaration splice (your `$(deriveJSON ... )`) breaks up the mutual recursion among all top-level declarations. Code above the splice can't see code below it. This allows code within the splice to see some definitions in your file, and code after the splice to see the definitions in the splice itself. Thanks for reporting! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 8 16:11:08 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Dec 2014 16:11:08 -0000 Subject: [GHC] #5850: Greater customization of GHCi prompt In-Reply-To: <050.bf03c3e2cbefdd0fabbaa545b275f2dc@haskell.org> References: <050.bf03c3e2cbefdd0fabbaa545b275f2dc@haskell.org> Message-ID: <065.fea44e0d2470d5853f49338679659040@haskell.org> #5850: Greater customization of GHCi prompt -------------------------------------+------------------------------------- Reporter: | Owner: jlengyel JamesFisher | Status: patch Type: feature | Milestone: 7.12.1 request | Version: 7.4.1 Priority: normal | Keywords: newcomer Component: GHCi | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D559 | -------------------------------------+------------------------------------- Changes (by hvr): * milestone: 7.10.1 => 7.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 8 16:12:44 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Dec 2014 16:12:44 -0000 Subject: [GHC] #9766: Use TypeLits in the meta-data encoding of GHC.Generics In-Reply-To: <046.ac6e9deb0e3faceb7991565f7ad6b80b@haskell.org> References: <046.ac6e9deb0e3faceb7991565f7ad6b80b@haskell.org> Message-ID: <061.7040fc37525a942f46ddadb6539a74cc@haskell.org> #9766: Use TypeLits in the meta-data encoding of GHC.Generics -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: task | Status: patch Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #9043 Test Case: | Blocking: 9043 | Differential Revisions: Phab:D493 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: 7.10.1 => 7.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 8 16:13:32 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Dec 2014 16:13:32 -0000 Subject: [GHC] #9393: execvpe should handle ENOTDIR In-Reply-To: <044.de71ccdfac1cf39975dbc19d1eedf841@haskell.org> References: <044.de71ccdfac1cf39975dbc19d1eedf841@haskell.org> Message-ID: <059.6d2d2022c318f3cc54b2923ba120622a@haskell.org> #9393: execvpe should handle ENOTDIR -------------------------------------+------------------------------------- Reporter: iquiw | Owner: Type: bug | Status: upstream Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.8.2 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by hvr): * cc: core-libraries-committee@? (added) Comment: (already fixed in upstream Git) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 8 17:00:38 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Dec 2014 17:00:38 -0000 Subject: [GHC] #9871: Template Haskell declaration splice causes subsequent declarations to fall out of scope In-Reply-To: <050.2e1226ec0f1aa6f869cadabe53509976@haskell.org> References: <050.2e1226ec0f1aa6f869cadabe53509976@haskell.org> Message-ID: <065.a2e3fc0d3d1b20b70aa4affc2c05831b@haskell.org> #9871: Template Haskell declaration splice causes subsequent declarations to fall out of scope -------------------------------------+------------------------------------- Reporter: | Owner: RyanGlScott | Status: closed Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: | Keywords: Documentation | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: GHC | rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Just to clarify, which of the above workarounds would you recommend? Should I move all TH declaration splices to the top or bottom of the module? Something else? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 8 17:02:41 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Dec 2014 17:02:41 -0000 Subject: [GHC] #9871: Template Haskell declaration splice causes subsequent declarations to fall out of scope In-Reply-To: <050.2e1226ec0f1aa6f869cadabe53509976@haskell.org> References: <050.2e1226ec0f1aa6f869cadabe53509976@haskell.org> Message-ID: <065.78f4ce6746f98442ee9e31631645aa6d@haskell.org> #9871: Template Haskell declaration splice causes subsequent declarations to fall out of scope -------------------------------------+------------------------------------- Reporter: | Owner: RyanGlScott | Status: closed Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: | Keywords: Documentation | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: GHC | rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): It's up to you and what works with your coding style. I can't really recommend one ordering over another. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 8 17:16:00 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Dec 2014 17:16:00 -0000 Subject: [GHC] #2986: :info printing instances often isn't wanted In-Reply-To: <043.cc7348275a1e64e6491d1ee94042b0a6@haskell.org> References: <043.cc7348275a1e64e6491d1ee94042b0a6@haskell.org> Message-ID: <058.d60c4b397771de1b05eb9e167fa3476d@haskell.org> #2986: :info printing instances often isn't wanted -------------------------------------+------------------------------------- Reporter: Remi | Owner: Remi Type: feature | Status: new request | Milestone: 7.10.1 Priority: lowest | Version: 6.10.1 Component: GHCi | Keywords: :info instances Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Remi): Thanks for reminding that I want this feature, hvr :) I had an unexpected day off work and decided to finally dig up and work a bit on that patch: {{{ Prelude> :info Maybe Monad data Maybe a = Nothing | Just a -- Defined in ?GHC.Base? Use `:instances Maybe' to see its 10 instance(s) class Applicative m => Monad (m :: * -> *) where (>>=) :: m a -> (a -> m b) -> m b (>>) :: m a -> m b -> m b return :: a -> m a fail :: String -> m a -- Defined in ?GHC.Base? Use `:instances Monad' to see its 5 instance(s) }}} And for instances: {{{ Prelude> :instances Maybe Monad instance Eq a => Eq (Maybe a) -- Defined in ?GHC.Base? instance Monad Maybe -- Defined in ?GHC.Base? instance Functor Maybe -- Defined in ?GHC.Base? instance Ord a => Ord (Maybe a) -- Defined in ?GHC.Base? instance Read a => Read (Maybe a) -- Defined in ?GHC.Read? instance Show a => Show (Maybe a) -- Defined in ?GHC.Show? instance Applicative Maybe -- Defined in ?GHC.Base? instance Foldable Maybe -- Defined in ?Data.Foldable? instance Traversable Maybe -- Defined in ?Data.Traversable? instance Monoid a => Monoid (Maybe a) -- Defined in ?GHC.Base? instance Monad (Either e) -- Defined in ?Data.Either? instance Monad [] -- Defined in ?GHC.Base? instance Monad Maybe -- Defined in ?GHC.Base? instance Monad IO -- Defined in ?GHC.Base? instance Monad ((->) r) -- Defined in ?GHC.Base? }}} {{{ Prelude> :instances! Monad instance Monad Data.Functor.Identity.Identity -- Defined in ?Data.Functor.Identity? instance Monad Data.Monoid.Last -- Defined in ?Data.Monoid? instance Monad Data.Monoid.First -- Defined in ?Data.Monoid? instance Monad f => Monad (Data.Monoid.Alt f) -- Defined in ?Data.Monoid? instance Monad Text.ParserCombinators.ReadPrec.ReadPrec -- Defined in ?Text.ParserCombinators.ReadPrec? instance Monad (GHC.ST.ST s) -- Defined in ?GHC.ST? instance Control.Arrow.ArrowApply a => Monad (Control.Arrow.ArrowMonad a) -- Defined in ?Control.Arrow? instance Monad m => Monad (Control.Applicative.WrappedMonad m) -- Defined in ?Control.Applicative? instance Monad Data.Proxy.Proxy -- Defined in ?Data.Proxy? instance Monad Text.ParserCombinators.ReadP.ReadP -- Defined in ?Text.ParserCombinators.ReadP? instance Monad Text.ParserCombinators.ReadP.P -- Defined in ?Text.ParserCombinators.ReadP? instance Monad (Either e) -- Defined in ?Data.Either? instance Monad [] -- Defined in ?GHC.Base? instance Monad Maybe -- Defined in ?GHC.Base? instance Monad IO -- Defined in ?GHC.Base? instance Monad ((->) r) -- Defined in ?GHC.Base? instance Data.Typeable.Internal.Typeable Monad -- Defined in ?Data.Typeable.Internal? }}} What it doesn't support is at least: {{{ Prelude> :set -XDataKinds Prelude> :instances Just `Just' is not a type or class Prelude> :instances 'Just :1:1: parse error on input ?'? Prelude> :k 'Just 'Just :: k -> Maybe k Prelude> :k Just Just :: k -> Maybe k }}} However, :info doesn't support it either, so I don't think that's that much of an issue right now: {{{ Prelude> :info 'Just :1:1: parse error on input ?'? }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 8 17:42:23 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Dec 2014 17:42:23 -0000 Subject: [GHC] #8951: genSym uses atomic_inc but doesn't link arm_atomic_spin_lock In-Reply-To: <047.6361bb2814dd444a3dfd661ef69cb2b7@haskell.org> References: <047.6361bb2814dd444a3dfd661ef69cb2b7@haskell.org> Message-ID: <062.e15fbd87cd03121158395d823a37af12@haskell.org> #8951: genSym uses atomic_inc but doesn't link arm_atomic_spin_lock -------------------------------------+------------------------------------- Reporter: cjwatson | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.4 Component: Build | Version: 7.8.1-rc1 System | Keywords: Resolution: | Architecture: arm Operating System: Linux | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => patch Comment: > So one thing I?m trying is to provide the stubs from rts/OldARMAtomic.c even in the unthreaded RTS. It will be dead code, but at least the linker will be happy. This helped, and seems to be the right thing to do. Patch at Phab:D564. I?m not committing it myself, as this is not my area of expertise... It would also be nice to get this into 7.8.4, as the Debian package will have to carry that anyways.... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 8 17:47:11 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Dec 2014 17:47:11 -0000 Subject: [GHC] #8988: Documentation build fails if GHCi is unavailable In-Reply-To: <047.4e32c2ffd98d48e7ad6de5d06c23433e@haskell.org> References: <047.4e32c2ffd98d48e7ad6de5d06c23433e@haskell.org> Message-ID: <062.8e91de1594083dcd0aa2d47ab38bd0de@haskell.org> #8988: Documentation build fails if GHCi is unavailable -------------------------------------+------------------------------------- Reporter: cjwatson | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.1 (Type checker) | Keywords: Resolution: fixed | Architecture: arm Operating System: Linux | Difficulty: Easy (less than 1 Type of failure: Building | hour) GHC failed | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: closed => merge * milestone: 7.10.1 => 7.8.4 Comment: This patch is required to get 7.8.4 compile on arm in Debian; I hope this makes this eligible for merging into 7.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 8 17:49:49 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Dec 2014 17:49:49 -0000 Subject: [GHC] #9336: binutils gold linker detection does not work when called via gcc and selected by commandline parameters In-Reply-To: <044.1f99437dfb37404e6cbefdee11591c8a@haskell.org> References: <044.1f99437dfb37404e6cbefdee11591c8a@haskell.org> Message-ID: <059.72640612175d7589351efaaee06a2c10@haskell.org> #9336: binutils gold linker detection does not work when called via gcc and selected by commandline parameters -------------------------------------+------------------------------------- Reporter: slomo | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.4 Component: Driver | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8976 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: closed => merge * milestone: 7.10.1 => 7.8.4 Comment: This patch is required to get 7.8.4 compile on arm in Debian; I hope this makes this eligible for merging into 7.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 8 17:50:21 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Dec 2014 17:50:21 -0000 Subject: [GHC] #9552: powerpc64 little endian: dll-split: Reachable modules from DynFlags out of date In-Reply-To: <047.a5a0d83a85e9f507ac92882847117a99@haskell.org> References: <047.a5a0d83a85e9f507ac92882847117a99@haskell.org> Message-ID: <062.04fe557b0d1bc126b92ef75380c94fdc@haskell.org> #9552: powerpc64 little endian: dll-split: Reachable modules from DynFlags out of date -------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Building | Difficulty: Unknown GHC failed | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: closed => merge * milestone: 7.10.1 => 7.8.4 Comment: This patch is required to get 7.8.4 compile on arm in Debian; I hope this makes this eligible for merging into 7.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 8 19:32:22 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Dec 2014 19:32:22 -0000 Subject: [GHC] #9873: Use CONF_GCC_LINKER_OPTS_STAGE2 only in stage2 Message-ID: <046.77f53bab4b42e7b7f0531b045d80ca9c@haskell.org> #9873: Use CONF_GCC_LINKER_OPTS_STAGE2 only in stage2 -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- On ARM, we want to make sure that GHC uses the gold linker. In order to achieve that, we need to get `-fuse-ld=gold` into SettingsCCompilerLinkFlags in the settings. This field is filled with only CONF_GCC_LINKER_OPTS_STAGE2. So we want that flag to show up there. But this variable is used in other places as well. For example, the configuration of tinfo fails: {{{ $ make libraries/terminfo/dist-boot/package-data.mk ===--- building phase 0 make -r --no-print-directory -f ghc.mk phase=0 phase_0_builds libraries/terminfo/ghc.mk:3: libraries/terminfo/dist-boot/package-data.mk: Datei oder Verzeichnis nicht gefunden "inplace/bin/ghc-cabal" configure libraries/terminfo dist-boot "" --with- ghc="/usr/bin/ghc" --with-ghc-pkg="/usr/bin/ghc-pkg" --package- db=/home/jojo/build/haskell/ghc/libraries/bootstrapping.conf --disable- library-for-ghci --enable-library-vanilla --disable-library-profiling --disable-shared --with-hscolour="/usr/bin/HsColour" --configure- option=CFLAGS=" -fno-stack-protector " --configure-option=LDFLAGS=" -fuse-ld=gold " --configure-option=CPPFLAGS=" " --gcc-options=" -fno- stack-protector -fuse-ld=gold " --constraint "binary == 0.7.1.0" --constraint "Cabal == 1.21.1.0" --constraint "hpc == 0.6.0.2" --constraint "bin-package-db == 0.0.0.0" --constraint "hoopl == 3.10.0.2" --constraint "transformers == 0.4.2.0" --constraint "terminfo == 0.4.0.0" --with-gcc="/usr/bin/gcc" --configure-option=--with- cc="/usr/bin/gcc" --with-ar="/usr/bin/ar" --with-alex="/usr/bin/alex" --with-happy="/usr/bin/happy" Configuring terminfo-0.4.0.0... configure: WARNING: unrecognized options: --with-compiler, --with-gcc checking for gcc... /usr/bin/gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether /usr/bin/gcc accepts -g... yes checking for /usr/bin/gcc option to accept ISO C89... none needed checking how to run the C preprocessor... /usr/bin/gcc -E checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking ncurses.h usability... yes checking ncurses.h presence... yes checking for ncurses.h... yes checking for setupterm in -ltinfo... yes configure: creating ./config.status config.status: creating terminfo.buildinfo configure: WARNING: unrecognized options: --with-compiler, --with-gcc ghc-cabal: Missing dependency on a foreign library: * Missing C library: tinfo This problem can usually be solved by installing the system package that provides this library (you may need the "-dev" version). If the library is already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where it is. libraries/terminfo/ghc.mk:3: recipe for target 'libraries/terminfo/dist- boot/package-data.mk' failed make[1]: *** [libraries/terminfo/dist-boot/package-data.mk] Error 1 Makefile:71: recipe for target 'libraries/terminfo/dist-boot/package- data.mk' failed make: *** [libraries/terminfo/dist-boot/package-data.mk] Error 2 }}} The problem (unfortunately, not very visible) is that `ghc-cabal` calls `gcc` to test if the C libaries are available. It uses the linker flags that it?s being told to use from the host GHC (here: 7.6.3), which contains the usual: {{{ $ ghc --info |fgrep 'C compiler flags' ,("C compiler flags"," -fno-stack-protector -Wl,--hash-size=31 -Wl ,--reduce-memory-overheads") }}} But to that it adds `-fuse-ld-gold` because `ghc-cabal` is gets `" --gcc- options=" -fno-stack-protector -fuse-ld=gold "` passed. So the build system should not pass flags from `CONF_GCC_LINKER_OPTS_STAGE2` anywhere besides gcc when used *by the stage 2 ghc* during linking. The chain of variables leading to this can be seen here: {{{ $ git grep CONFIGURE_LDFLAGS rules/build-package-data.mk:$1_$2_CONFIGURE_LDFLAGS = $$(SRC_LD_OPTS) $$(CONF_GCC_LINKER_OPTS_STAGE$3) $$($1_LD_OPTS) $$($1_$2_LD_OPTS) rules/build-package-data.mk:$1_$2_CONFIGURE_OPTS += --configure- option=LDFLAGS="$$($1_$2_CONFIGURE_LDFLAGS)" rules/build-package-data.mk:$1_$2_CONFIGURE_OPTS += --gcc- options="$$($1_$2_CONFIGURE_CFLAGS) $$($1_$2_CONFIGURE_LDFLAGS)" }}} I?m currently experimenting with a patch that simply does not use `CONF_GCC_LINKER_OPTS_STAGE` anywhere besides when defining `SettingsCCompilerLinkFlags`, but I?m afraid that this might introduce new unwanted behaviour. But since `ghc-cabal` reads gcc-flags from `ghc --info`, maybe that channel of information is sufficient. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 8 21:57:56 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Dec 2014 21:57:56 -0000 Subject: [GHC] #9857: GHC 7.9 panics (simplifier ticks exhausted) on `half-0.2` In-Reply-To: <042.3b1974ccb36d315c778a524393b08ca5@haskell.org> References: <042.3b1974ccb36d315c778a524393b08ca5@haskell.org> Message-ID: <057.b333f4748c59db65af1b700271fbf0d2@haskell.org> #9857: GHC 7.9 panics (simplifier ticks exhausted) on `half-0.2` -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by hvr): * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 9 07:39:46 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Dec 2014 07:39:46 -0000 Subject: [GHC] #9872: Runing type functions is too slow In-Reply-To: <046.39f8cd7bfe0ce27cb6afb75f2059ad40@haskell.org> References: <046.39f8cd7bfe0ce27cb6afb75f2059ad40@haskell.org> Message-ID: <061.4e44600009a5eeeec3e33e43f1b13bed@haskell.org> #9872: Runing type functions is too slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by cactus): With the latest changes I am seeing some further performance regression, to put it mildly. I've only tested `slow1.hs`, but as of 2515686ff695169238b673423f01768f5aaa9750, I am getting this on a perf build on Windows: {{{ real 54m45.347s user 0m0.000s sys 0m0.062s }}} Now, granted, it's not the same machine as the one I originally reported this from, but... 55 '''minutes'''! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 9 10:04:28 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Dec 2014 10:04:28 -0000 Subject: [GHC] #9873: Use CONF_GCC_LINKER_OPTS_STAGE2 only in stage2 In-Reply-To: <046.77f53bab4b42e7b7f0531b045d80ca9c@haskell.org> References: <046.77f53bab4b42e7b7f0531b045d80ca9c@haskell.org> Message-ID: <061.8cc91d01a43a82fe92cd762e0f3fb0cf@haskell.org> #9873: Use CONF_GCC_LINKER_OPTS_STAGE2 only in stage2 -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.9 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nomeata): This is the patch I use in the Debian package for now. Maybe it is good enough already? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 9 10:57:50 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Dec 2014 10:57:50 -0000 Subject: [GHC] #8624: -ddump-splices-file In-Reply-To: <048.f5eead94409241401357105f8bb65a4f@haskell.org> References: <048.f5eead94409241401357105f8bb65a4f@haskell.org> Message-ID: <063.ad9eb103171d45bf54a74a7c0cbf99a1@haskell.org> #8624: -ddump-splices-file -------------------------------------+------------------------------------- Reporter: GregWeber | Owner: Type: feature | Status: patch request | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | https://phabricator.haskell.org/D518| -------------------------------------+------------------------------------- Comment (by thomie): In the code review, the flag is called `-dth-file`. Why not include the word `dump`? How about: || `ddump-th` || dump to stdout || || `ddump-th -ddump-to-file` || dump to a `.th.hs` file || This would be more consistent with for example `-ddump-hi` and `-ddump-hi -ddump-to-file` (which dumps to a `.dump-hi` file). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 9 13:09:08 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Dec 2014 13:09:08 -0000 Subject: [GHC] #3085: warn about language extensions that are not used In-Reply-To: <051.bedfbd02c24cc787d0bf163c67d17d1e@haskell.org> References: <051.bedfbd02c24cc787d0bf163c67d17d1e@haskell.org> Message-ID: <066.f9d48179832c04d4887e7d329bc9eedc@haskell.org> #3085: warn about language extensions that are not used -------------------------------------+------------------------------------- Reporter: | Owner: PVerswyvelen | Status: new Type: feature | Milestone: 7.10.1 request | Version: 6.10.1 Priority: normal | Keywords: warnings Component: Compiler | extensions language Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #9757 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonmar): Replying to [comment:33 thomie]: > To cite rwbarton from #9757: > > I think the purpose of compiler warnings should be to warn about code that is probably bad, not code that is probably fine that could be written in a (potentially) better way. (After all, we don't warn about excess parentheses in code either.) That is the domain of hlint, as Richard notes. > > Anyone disagree with a `wontfix` here as well? This is an argument that the warning shouldn't be on by default, or perhaps that it shouldn't be in `-Wall`, but not an argument that we shouldn't implement it at all. We have several warnings that are not part of `-Wall` and fall into the category of "a matter of taste". (FWIW, HLint already does this for a subset of extensions). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 9 13:16:22 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Dec 2014 13:16:22 -0000 Subject: [GHC] #9831: the 'impossible' happened : iselExpr64(powerpc) In-Reply-To: <044.1090bf2d6b74a28254c5352399819de1@haskell.org> References: <044.1090bf2d6b74a28254c5352399819de1@haskell.org> Message-ID: <059.41e5f620800669b20d3ca289bc4203a5@haskell.org> #9831: the 'impossible' happened : iselExpr64(powerpc) ----------------------------------------------+--------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.9 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: Phab:D560 | ----------------------------------------------+--------------------------- Comment (by simonmar): Yeah, sorry about this, as you probably realised you need to support a few more 64-bit ops in the NCG. Hopefully it shouldn't be too hard by looking at the x86 versions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 9 13:41:00 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Dec 2014 13:41:00 -0000 Subject: [GHC] #8624: -ddump-splices-file In-Reply-To: <048.f5eead94409241401357105f8bb65a4f@haskell.org> References: <048.f5eead94409241401357105f8bb65a4f@haskell.org> Message-ID: <063.ae01b9c0e7be562a3557da6bbf640664@haskell.org> #8624: -ddump-splices-file -------------------------------------+------------------------------------- Reporter: GregWeber | Owner: Type: feature | Status: patch request | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | https://phabricator.haskell.org/D518| -------------------------------------+------------------------------------- Comment (by GregWeber): A big problem here is that `-ddump-to-file` is a global flag. I assume dumping to stdout is the default because users want that ephemeral behavior. The design for this ticket is that a user always wants to save it to a file, and that should not have to make all other dumps go to a file. If someone wants to ephemerally dump splices to stdout `-ddump- splices` is already there, well known, and better suited to the job. Additionally, I want a `.hs` file to signify that the output is valid Haskell, not just a dump in an ad-hoc format, whereas with dumping the convention is `dump-FLAG`. So I did intentionally want to get away from dumping but I am definitely open to ideas for better naming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 9 18:11:00 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Dec 2014 18:11:00 -0000 Subject: [GHC] #9874: Unhandled exception in Phab Message-ID: <047.1109ac3947d54912be92b848b61adae5@haskell.org> #9874: Unhandled exception in Phab -------------------------------------+------------------------------------- Reporter: goldfire | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Several times over the past few days, loading Phab:D546 has given me a window with Unhandled Exception ("InvalidArgumentException") Argument 2 passed to DifferentialTransactionComment::sortAndGroupInlines() must be of the type array, null given, called in /opt/phabricator/src/applications/differential/view/DifferentialTransactionView.php on line 118 and defined -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 10 01:57:29 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Dec 2014 01:57:29 -0000 Subject: [GHC] #9875: ld -l:filename.dylib does not appear to be portable Message-ID: <045.5761a7e104bd5de24e048bce5dd70a34@haskell.org> #9875: ld -l:filename.dylib does not appear to be portable ------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: GHCi | Version: 7.9 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: GHCi crash Difficulty: Unknown | Test Case: T2276_ghci Blocked By: | Blocking: Related Tickets: | Differential Revisions: ------------------------------------+------------------------------------- In GHCi, we seem to use `-l:` to ask the linker to link a specific filename, instead of munging the filename. Unfortunately, this does not appear to be universally supported by all versions of `ld`. Here is the manpage `ld` that comes with Mac OS X 10.10.1: {{{ Options that control libraries -lx This option tells the linker to search for libx.dylib or libx.a in the library search path. If string x is of the form y.o, then that file is searched for in the same places, but without prepending `lib' or appending `.a' or `.dylib' to the filename. }}} It causes T2276_ghci to fail: {{{ --- /dev/null 2014-12-09 20:57:29.000000000 -0500 +++ ./T2276_ghci.run.stderr 2014-12-09 20:57:30.000000000 -0500 @@ -0,0 +1,3 @@ +ld: library not found for -l:ghc75404_1.dylib +clang: error: linker command failed with exit code 1 (use -v to see invocation) +phase `Linker' failed (exitcode = 1) *** unexpected failure for T2276_ghci(ghci }}} Regression seems to have been introduced by: {{{ commit 383733b9191a36e2d3f757700842dbc3855911d9 Author: Peter Trommler Date: Sun Nov 30 12:00:39 2014 -0600 Fix obscure problem with using the system linker (#8935) }}} Probably we can fix it by not using colon and making sure the libraries we generate have the right file format. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 10 01:58:30 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Dec 2014 01:58:30 -0000 Subject: [GHC] #7015: Add support for 'static' In-Reply-To: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> References: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> Message-ID: <059.8a09b1c825860fc5bc6c6e4c59d2b163@haskell.org> #7015: Add support for 'static' -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.4.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D550 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"fc45f32491313d2a44e72d8d59cdf95b1660189d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="fc45f32491313d2a44e72d8d59cdf95b1660189d" Implement -XStaticValues Summary: As proposed in [1], this extension introduces a new syntactic form `static e`, where `e :: a` can be any closed expression. The static form produces a value of type `StaticPtr a`, which works as a reference that programs can "dereference" to get the value of `e` back. References are like `Ptr`s, except that they are stable across invocations of a program. The relevant wiki pages are [2, 3], which describe the motivation/ideas and implementation plan respectively. [1] Jeff Epstein, Andrew P. Black, and Simon Peyton-Jones. Towards Haskell in the cloud. SIGPLAN Not., 46(12):118?129, September 2011. ISSN 0362-1340. [2] https://ghc.haskell.org/trac/ghc/wiki/StaticPointers [3] https://ghc.haskell.org/trac/ghc/wiki/StaticPointers/ImplementationPlan Authored-by: Facundo Dom?nguez Authored-by: Mathieu Boespflug Authored-by: Alexander Vershilov Test Plan: `./validate` Reviewers: hvr, simonmar, simonpj, austin Reviewed By: simonpj, austin Subscribers: qnikst, bgamari, mboes, carter, thomie, goldfire Differential Revision: https://phabricator.haskell.org/D550 GHC Trac Issues: #7015 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 10 01:58:31 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Dec 2014 01:58:31 -0000 Subject: [GHC] #9605: Misleading error message with forgotten "do" In-Reply-To: <043.4d0a36fa55a61f7a0e16739341de4daf@haskell.org> References: <043.4d0a36fa55a61f7a0e16739341de4daf@haskell.org> Message-ID: <058.176744a89633816f147fc04d5735ec43@haskell.org> #9605: Misleading error message with forgotten "do" -------------------------------------+------------------------------------- Reporter: owst | Owner: Yuras Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #7869 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D556 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"09b7943321f89b945d10f8a914f4c2cbf73dff91/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="09b7943321f89b945d10f8a914f4c2cbf73dff91" fix misleading error message regarding function arity Summary: The error reports something like: The function ?f? is applied to three arguments, but its type ?Int -> Float -> Char -> Bool? has only three The original type was "Monad m => Int -> Float -> m Bool", but "m" was unified with "-> Char". Now it looks better: The function ?f? is applied to three arguments, its type is ?Int -> Float -> m0 Bool?, it is specialized to ?Int -> Float -> Char -> Bool? Test Plan: T9605 Reviewers: simonpj, austin Reviewed By: austin Subscribers: carter, thomie Differential Revision: https://phabricator.haskell.org/D556 GHC Trac Issues: #9605 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 10 01:58:31 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Dec 2014 01:58:31 -0000 Subject: [GHC] #9870: Document deviation of Data.List.splitAt from Report semantics In-Reply-To: <045.434428ec5e3302df507a7c2131cd8582@haskell.org> References: <045.434428ec5e3302df507a7c2131cd8582@haskell.org> Message-ID: <060.64e826e4c9531ded2fff3c03ffeba040@haskell.org> #9870: Document deviation of Data.List.splitAt from Report semantics -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: 7.9 Documentation | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: Documentation bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D562 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"8b480d3192e6eff6183934d7bbcc2054611c3651/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="8b480d3192e6eff6183934d7bbcc2054611c3651" Document splitAt deviation from the Report Summary: `splitAt` is stricter than the Report specifies, so we should say so. Reviewers: hvr, austin Reviewed By: austin Subscribers: carter, thomie Projects: #ghc Differential Revision: https://phabricator.haskell.org/D562 GHC Trac Issues: #9870 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 10 01:58:31 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Dec 2014 01:58:31 -0000 Subject: [GHC] #8951: genSym uses atomic_inc but doesn't link arm_atomic_spin_lock In-Reply-To: <047.6361bb2814dd444a3dfd661ef69cb2b7@haskell.org> References: <047.6361bb2814dd444a3dfd661ef69cb2b7@haskell.org> Message-ID: <062.ec6df2ae2c5a3cd31ba3a7fb2d86a89a@haskell.org> #8951: genSym uses atomic_inc but doesn't link arm_atomic_spin_lock -------------------------------------+------------------------------------- Reporter: cjwatson | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.4 Component: Build | Version: 7.8.1-rc1 System | Keywords: Resolution: | Architecture: arm Operating System: Linux | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"df1307f079ae69dcd735e0973de987b141d509da/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="df1307f079ae69dcd735e0973de987b141d509da" Link pre-ARMv6 spinlocks into all RTS variants Summary: For compatibility with ARM machines from pre v6, the RTS provides implementations of certain atomic operations. Previously, these were only included in the threaded RTS. But ghc (the library) contains the code in compiler/cbits/genSym.c, which uses these operations if there is more than one capability. But there is only one libHSghc, so the linker wants to resolve these symbols in every case. By providing these operations in all RTSs, the linker is happy. The only downside is a small amount of dead code in the non-threaded RTS on old ARM machines. Test Plan: It helped here. Reviewers: bgamari, austin Reviewed By: bgamari, austin Subscribers: carter, thomie Differential Revision: https://phabricator.haskell.org/D564 GHC Trac Issues: #8951 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 10 02:00:13 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Dec 2014 02:00:13 -0000 Subject: [GHC] #9875: ld -l:filename.dylib does not appear to be portable In-Reply-To: <045.5761a7e104bd5de24e048bce5dd70a34@haskell.org> References: <045.5761a7e104bd5de24e048bce5dd70a34@haskell.org> Message-ID: <060.f4489c0331f788ab38763bf56abfd93c@haskell.org> #9875: ld -l:filename.dylib does not appear to be portable -------------------------------------+------------------------------------ Reporter: ezyang | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: GHCi | Version: 7.9 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Unknown Test Case: T2276_ghci | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------ Description changed by ezyang: Old description: > In GHCi, we seem to use `-l:` to ask the linker to link a specific > filename, instead of munging the filename. Unfortunately, this does not > appear to be universally supported by all versions of `ld`. Here is the > manpage `ld` that comes with Mac OS X 10.10.1: > > {{{ > Options that control libraries > -lx This option tells the linker to search for libx.dylib or > libx.a in > the library search path. If string x is of the form > y.o, then that > file is searched for in the same places, but without > prepending > `lib' or appending `.a' or `.dylib' to the filename. > }}} > > It causes T2276_ghci to fail: > > {{{ > --- /dev/null 2014-12-09 20:57:29.000000000 -0500 > +++ ./T2276_ghci.run.stderr 2014-12-09 20:57:30.000000000 -0500 > @@ -0,0 +1,3 @@ > +ld: library not found for -l:ghc75404_1.dylib > +clang: error: linker command failed with exit code 1 (use -v to see > invocation) > +phase `Linker' failed (exitcode = 1) > *** unexpected failure for T2276_ghci(ghci > }}} > > Regression seems to have been introduced by: > > {{{ > commit 383733b9191a36e2d3f757700842dbc3855911d9 > Author: Peter Trommler > Date: Sun Nov 30 12:00:39 2014 -0600 > > Fix obscure problem with using the system linker (#8935) > }}} > > Probably we can fix it by not using colon and making sure the libraries > we generate have the right file format. New description: In GHCi, we seem to use `-l:` to ask the linker to link a specific filename, instead of munging the filename. Unfortunately, this does not appear to be universally supported by all versions of `ld`. Here is the manpage `ld` that comes with Mac OS X 10.10.1: {{{ Options that control libraries -lx This option tells the linker to search for libx.dylib or libx.a in the library search path. If string x is of the form y.o, then that file is searched for in the same places, but without prepending `lib' or appending `.a' or `.dylib' to the filename. }}} It causes T2276_ghci, prog003, T8696 and ghci058 to fail: {{{ --- /dev/null 2014-12-09 20:57:29.000000000 -0500 +++ ./T2276_ghci.run.stderr 2014-12-09 20:57:30.000000000 -0500 @@ -0,0 +1,3 @@ +ld: library not found for -l:ghc75404_1.dylib +clang: error: linker command failed with exit code 1 (use -v to see invocation) +phase `Linker' failed (exitcode = 1) *** unexpected failure for T2276_ghci(ghci }}} Regression seems to have been introduced by: {{{ commit 383733b9191a36e2d3f757700842dbc3855911d9 Author: Peter Trommler Date: Sun Nov 30 12:00:39 2014 -0600 Fix obscure problem with using the system linker (#8935) }}} Probably we can fix it by not using colon and making sure the libraries we generate have the right file format. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 10 02:00:23 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Dec 2014 02:00:23 -0000 Subject: [GHC] #9870: Document deviation of Data.List.splitAt from Report semantics In-Reply-To: <045.434428ec5e3302df507a7c2131cd8582@haskell.org> References: <045.434428ec5e3302df507a7c2131cd8582@haskell.org> Message-ID: <060.1b1539e5b10447c2f36d614583566582@haskell.org> #9870: Document deviation of Data.List.splitAt from Report semantics -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: | Version: 7.9 Documentation | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: Documentation bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D562 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 10 02:01:01 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Dec 2014 02:01:01 -0000 Subject: [GHC] #9605: Misleading error message with forgotten "do" In-Reply-To: <043.4d0a36fa55a61f7a0e16739341de4daf@haskell.org> References: <043.4d0a36fa55a61f7a0e16739341de4daf@haskell.org> Message-ID: <058.740e332b0b40edf6cca233b217453b37@haskell.org> #9605: Misleading error message with forgotten "do" -------------------------------------+------------------------------------- Reporter: owst | Owner: Yuras Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #7869 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D556 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => fixed * milestone: => 7.10.1 Comment: I think the pushed revision is fine, so this is done. Thanks Yuras! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 10 02:03:44 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Dec 2014 02:03:44 -0000 Subject: [GHC] #7015: Add support for 'static' In-Reply-To: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> References: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> Message-ID: <059.529ec381fff2ff12471ed5c83e7845f9@haskell.org> #7015: Add support for 'static' -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature | Status: new request | Milestone: 7.12.1 Priority: normal | Version: 7.4.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D119, | Phab:D550 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => new * differential: Phab:D550 => Phab:D119, Phab:D550 * milestone: 7.10.1 => 7.12.1 Comment: The first draft has landed, awesome! OK, I'm now punting the version on this to 7.12 since there's some future work to do. Alternatively, we can milestone this to 7.10.1 and close it, and track future improvements through separate tickets. What do you think, Facundo? (Note, adding the old Phab:D119 to the revision list still, mostly to keep track of historical attempts. Feel free to undo again.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 10 07:30:21 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Dec 2014 07:30:21 -0000 Subject: [GHC] #9876: mkdir errors when running `make sdist` Message-ID: <048.4e2ab1a0df62a578daea8b81b25fe988@haskell.org> #9876: mkdir errors when running `make sdist` -------------------------------------+------------------------------------- Reporter: joehillen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Hi. Newcomer here. I was taking a look at #9095 and I get the following errors when running `make sdist`. {{{ "rm" -f sdistprep/ghc-7.9.20141208-windows-extra-src.tar.bz2 mkdir sdistprep mkdir: cannot create directory ?sdistprep?: File exists make[1]: [sdist-windows-tarballs-prep] Error 1 (ignored) mkdir sdistprep/windows-tarballs mkdir sdistprep/windows-tarballs/ghc-7.9.20141208 mkdir sdistprep/windows-tarballs/ghc-7.9.20141208/ghc-tarballs cd sdistprep/windows-tarballs/ghc-7.9.20141208/ghc-tarballs && lndir /home/joe/src/ghc/ghc-tarballs "rm" -rf sdistprep/windows-tarballs/ghc-7.9.20141208/ghc-tarballs/.git cd sdistprep/windows-tarballs && "/bin/tar" chf - ghc-7.9.20141208 2> windows_extra_src_ghc_log | bzip2 -c > /home/joe/src/ghc/sdistprep/ghc-7.9.20141208-windows-extra-src.tar.bz2 "rm" -rf sdistprep/testsuite-ghc "rm" -f sdistprep/ghc-7.9.20141208-testsuite.tar.bz2 mkdir sdistprep mkdir: cannot create directory ?sdistprep?: File exists make[1]: [sdist-testsuite-prep] Error 1 (ignored) mkdir sdistprep/testsuite-ghc mkdir sdistprep/testsuite-ghc/ghc-7.9.20141208 mkdir sdistprep/testsuite-ghc/ghc-7.9.20141208/testsuite cd sdistprep/testsuite-ghc/ghc-7.9.20141208/testsuite && lndir /home/joe/src/ghc/testsuite /home/joe/src/ghc/testsuite: No such file or directory make[1]: *** [sdist-testsuite-prep] Error 1 make: *** [sdist] Error 2 }}} Generally when using 'mkdir' in a Makefile I've found it best to always use 'mkdir -p' just like you should how you should always use 'rm -f'. It's a simple fix. I'm submitting a patch for it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 10 07:30:48 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Dec 2014 07:30:48 -0000 Subject: [GHC] #9876: mkdir errors when running `make sdist` In-Reply-To: <048.4e2ab1a0df62a578daea8b81b25fe988@haskell.org> References: <048.4e2ab1a0df62a578daea8b81b25fe988@haskell.org> Message-ID: <063.2e84104c310f18bfe12d3bf52bf94745@haskell.org> #9876: mkdir errors when running `make sdist` -------------------------------------+------------------------------------- Reporter: joehillen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Description changed by joehillen: Old description: > Hi. Newcomer here. I was taking a look at #9095 and I get the following > errors when running `make sdist`. > > {{{ > "rm" -f sdistprep/ghc-7.9.20141208-windows-extra-src.tar.bz2 > mkdir sdistprep > mkdir: cannot create directory ?sdistprep?: File exists > make[1]: [sdist-windows-tarballs-prep] Error 1 (ignored) > mkdir sdistprep/windows-tarballs > mkdir sdistprep/windows-tarballs/ghc-7.9.20141208 > mkdir sdistprep/windows-tarballs/ghc-7.9.20141208/ghc-tarballs > cd sdistprep/windows-tarballs/ghc-7.9.20141208/ghc-tarballs && lndir > /home/joe/src/ghc/ghc-tarballs > "rm" -rf sdistprep/windows-tarballs/ghc-7.9.20141208/ghc-tarballs/.git > cd sdistprep/windows-tarballs && "/bin/tar" chf - ghc-7.9.20141208 2> > windows_extra_src_ghc_log | bzip2 -c > > /home/joe/src/ghc/sdistprep/ghc-7.9.20141208-windows-extra-src.tar.bz2 > "rm" -rf sdistprep/testsuite-ghc > "rm" -f sdistprep/ghc-7.9.20141208-testsuite.tar.bz2 > mkdir sdistprep > mkdir: cannot create directory ?sdistprep?: File exists > make[1]: [sdist-testsuite-prep] Error 1 (ignored) > mkdir sdistprep/testsuite-ghc > mkdir sdistprep/testsuite-ghc/ghc-7.9.20141208 > mkdir sdistprep/testsuite-ghc/ghc-7.9.20141208/testsuite > cd sdistprep/testsuite-ghc/ghc-7.9.20141208/testsuite && lndir > /home/joe/src/ghc/testsuite > /home/joe/src/ghc/testsuite: No such file or directory > make[1]: *** [sdist-testsuite-prep] Error 1 > make: *** [sdist] Error 2 > }}} > > Generally when using 'mkdir' in a Makefile I've found it best to always > use 'mkdir -p' just like you should how you should always use 'rm -f'. > > It's a simple fix. I'm submitting a patch for it. New description: Hi. Newcomer here. I was taking a look at #9095 and I get the following errors when running `make sdist`. {{{ "rm" -f sdistprep/ghc-7.9.20141208-windows-extra-src.tar.bz2 mkdir sdistprep mkdir: cannot create directory ?sdistprep?: File exists make[1]: [sdist-windows-tarballs-prep] Error 1 (ignored) mkdir sdistprep/windows-tarballs mkdir sdistprep/windows-tarballs/ghc-7.9.20141208 mkdir sdistprep/windows-tarballs/ghc-7.9.20141208/ghc-tarballs cd sdistprep/windows-tarballs/ghc-7.9.20141208/ghc-tarballs && lndir /home/joe/src/ghc/ghc-tarballs "rm" -rf sdistprep/windows-tarballs/ghc-7.9.20141208/ghc-tarballs/.git cd sdistprep/windows-tarballs && "/bin/tar" chf - ghc-7.9.20141208 2> windows_extra_src_ghc_log | bzip2 -c > /home/joe/src/ghc/sdistprep/ghc-7.9.20141208-windows-extra-src.tar.bz2 "rm" -rf sdistprep/testsuite-ghc "rm" -f sdistprep/ghc-7.9.20141208-testsuite.tar.bz2 mkdir sdistprep mkdir: cannot create directory ?sdistprep?: File exists make[1]: [sdist-testsuite-prep] Error 1 (ignored) mkdir sdistprep/testsuite-ghc mkdir sdistprep/testsuite-ghc/ghc-7.9.20141208 mkdir sdistprep/testsuite-ghc/ghc-7.9.20141208/testsuite cd sdistprep/testsuite-ghc/ghc-7.9.20141208/testsuite && lndir /home/joe/src/ghc/testsuite /home/joe/src/ghc/testsuite: No such file or directory make[1]: *** [sdist-testsuite-prep] Error 1 make: *** [sdist] Error 2 }}} Generally when using `mkdir` in a Makefile I've found it best to always use `mkdir -p` just like you should how you should always use `rm -f`. It's a simple fix. I'm submitting a patch for it. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 10 07:31:10 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Dec 2014 07:31:10 -0000 Subject: [GHC] #9876: mkdir errors when running `make sdist` In-Reply-To: <048.4e2ab1a0df62a578daea8b81b25fe988@haskell.org> References: <048.4e2ab1a0df62a578daea8b81b25fe988@haskell.org> Message-ID: <063.9e6fe044312e7020318cc33177451f3b@haskell.org> #9876: mkdir errors when running `make sdist` -------------------------------------+------------------------------------- Reporter: joehillen | Owner: joehillen Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by joehillen): * owner: => joehillen -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 10 07:46:30 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Dec 2014 07:46:30 -0000 Subject: [GHC] #9876: mkdir errors when running `make sdist` In-Reply-To: <048.4e2ab1a0df62a578daea8b81b25fe988@haskell.org> References: <048.4e2ab1a0df62a578daea8b81b25fe988@haskell.org> Message-ID: <063.30e08c59f1990098f7c6ccf3938e8128@haskell.org> #9876: mkdir errors when running `make sdist` -------------------------------------+------------------------------------- Reporter: joehillen | Owner: joehillen Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: Phab:D566 | -------------------------------------+------------------------------------- Changes (by joehillen): * status: new => patch * differential: => Phab:D566 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 10 07:47:18 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Dec 2014 07:47:18 -0000 Subject: [GHC] #9876: mkdir errors when running `make sdist` In-Reply-To: <048.4e2ab1a0df62a578daea8b81b25fe988@haskell.org> References: <048.4e2ab1a0df62a578daea8b81b25fe988@haskell.org> Message-ID: <063.4f3cee46d51b6c877d6e64cf9acef7b2@haskell.org> #9876: mkdir errors when running `make sdist` -------------------------------------+------------------------------------- Reporter: joehillen | Owner: joehillen Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: Phab:D566 | -------------------------------------+------------------------------------- Description changed by joehillen: Old description: > Hi. Newcomer here. I was taking a look at #9095 and I get the following > errors when running `make sdist`. > > {{{ > "rm" -f sdistprep/ghc-7.9.20141208-windows-extra-src.tar.bz2 > mkdir sdistprep > mkdir: cannot create directory ?sdistprep?: File exists > make[1]: [sdist-windows-tarballs-prep] Error 1 (ignored) > mkdir sdistprep/windows-tarballs > mkdir sdistprep/windows-tarballs/ghc-7.9.20141208 > mkdir sdistprep/windows-tarballs/ghc-7.9.20141208/ghc-tarballs > cd sdistprep/windows-tarballs/ghc-7.9.20141208/ghc-tarballs && lndir > /home/joe/src/ghc/ghc-tarballs > "rm" -rf sdistprep/windows-tarballs/ghc-7.9.20141208/ghc-tarballs/.git > cd sdistprep/windows-tarballs && "/bin/tar" chf - ghc-7.9.20141208 2> > windows_extra_src_ghc_log | bzip2 -c > > /home/joe/src/ghc/sdistprep/ghc-7.9.20141208-windows-extra-src.tar.bz2 > "rm" -rf sdistprep/testsuite-ghc > "rm" -f sdistprep/ghc-7.9.20141208-testsuite.tar.bz2 > mkdir sdistprep > mkdir: cannot create directory ?sdistprep?: File exists > make[1]: [sdist-testsuite-prep] Error 1 (ignored) > mkdir sdistprep/testsuite-ghc > mkdir sdistprep/testsuite-ghc/ghc-7.9.20141208 > mkdir sdistprep/testsuite-ghc/ghc-7.9.20141208/testsuite > cd sdistprep/testsuite-ghc/ghc-7.9.20141208/testsuite && lndir > /home/joe/src/ghc/testsuite > /home/joe/src/ghc/testsuite: No such file or directory > make[1]: *** [sdist-testsuite-prep] Error 1 > make: *** [sdist] Error 2 > }}} > > Generally when using `mkdir` in a Makefile I've found it best to always > use `mkdir -p` just like you should how you should always use `rm -f`. > > It's a simple fix. I'm submitting a patch for it. New description: Hi. Newcomer here. I was taking a look at #9095 and I get the following errors when running `make sdist`. {{{ "rm" -f sdistprep/ghc-7.9.20141208-windows-extra-src.tar.bz2 mkdir sdistprep mkdir: cannot create directory ?sdistprep?: File exists make[1]: [sdist-windows-tarballs-prep] Error 1 (ignored) mkdir sdistprep/windows-tarballs mkdir sdistprep/windows-tarballs/ghc-7.9.20141208 mkdir sdistprep/windows-tarballs/ghc-7.9.20141208/ghc-tarballs cd sdistprep/windows-tarballs/ghc-7.9.20141208/ghc-tarballs && lndir /home/joe/src/ghc/ghc-tarballs "rm" -rf sdistprep/windows-tarballs/ghc-7.9.20141208/ghc-tarballs/.git cd sdistprep/windows-tarballs && "/bin/tar" chf - ghc-7.9.20141208 2> windows_extra_src_ghc_log | bzip2 -c > /home/joe/src/ghc/sdistprep/ghc-7.9.20141208-windows-extra-src.tar.bz2 "rm" -rf sdistprep/testsuite-ghc "rm" -f sdistprep/ghc-7.9.20141208-testsuite.tar.bz2 mkdir sdistprep mkdir: cannot create directory ?sdistprep?: File exists make[1]: [sdist-testsuite-prep] Error 1 (ignored) mkdir sdistprep/testsuite-ghc mkdir sdistprep/testsuite-ghc/ghc-7.9.20141208 mkdir sdistprep/testsuite-ghc/ghc-7.9.20141208/testsuite cd sdistprep/testsuite-ghc/ghc-7.9.20141208/testsuite && lndir /home/joe/src/ghc/testsuite /home/joe/src/ghc/testsuite: No such file or directory make[1]: *** [sdist-testsuite-prep] Error 1 make: *** [sdist] Error 2 }}} Generally when using `mkdir` in a Makefile I've found it best to always use `mkdir -p` just like how you should always use `rm -f`. It's a simple fix. I'm submitting a patch for it. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 10 09:19:39 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Dec 2014 09:19:39 -0000 Subject: [GHC] #9831: the 'impossible' happened : iselExpr64(powerpc) In-Reply-To: <044.1090bf2d6b74a28254c5352399819de1@haskell.org> References: <044.1090bf2d6b74a28254c5352399819de1@haskell.org> Message-ID: <059.0a61f12d0dcca8a119ae6832899850d8@haskell.org> #9831: the 'impossible' happened : iselExpr64(powerpc) ----------------------------------------------+--------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.9 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: Phab:D560 | ----------------------------------------------+--------------------------- Comment (by erikd): Seems Sergei Trofimovich has already fixed this as part of his #D560 patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 10 10:06:32 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Dec 2014 10:06:32 -0000 Subject: [GHC] #7015: Add support for 'static' In-Reply-To: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> References: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> Message-ID: <059.927942cfd809b3249fee891e0acf08e0@haskell.org> #7015: Add support for 'static' -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature | Status: new request | Milestone: 7.12.1 Priority: normal | Version: 7.4.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D119, | Phab:D550 | -------------------------------------+------------------------------------- Comment (by mboes): Thanks for landing this! As far as I know all features that were requested as part of the GHC 7.10 milestone according to [wiki:StaticPointers/ImplementationPlan] have been implemented and all issues raised by the reviewers addressed. Seeing as this has been merged by now, perhaps it would make sense to go for the latter option, namely track future improvements through separate tickets? The major future improvement I see is this: * Store (higher-order) `TypeRep`s in the SPT and check them upon pointer lookups, in order to reduce the size of trusted base that guarantees type safety. That improvement is not really possible without switching to a new API for `Data.Typeable`, as outlined by Simon PJ [wiki:Typeable here], which is a potentially high impact change to `base`. I think it means two separate new tickets to track: implement type indexed `Data.Typeable`, add type representation checking to the SPT. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 10 10:19:13 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Dec 2014 10:19:13 -0000 Subject: [GHC] #9817: signal handlers in unix are passed garbage when using the signle threaded rts In-Reply-To: <045.646b26d4129c0e58f98ff89c628f56b1@haskell.org> References: <045.646b26d4129c0e58f98ff89c628f56b1@haskell.org> Message-ID: <060.64c28a84ce532f3a8bd66474a09f42dc@haskell.org> #9817: signal handlers in unix are passed garbage when using the signle threaded rts -------------------------------------+------------------------------------- Reporter: redneb | Owner: simonmar Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime | Version: 7.8.3 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: POSIX | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D515 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"7ca5bb090ff78141fbe275b058a9e35ee496bd58/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="7ca5bb090ff78141fbe275b058a9e35ee496bd58" compiler: fix trac issue #9817 Summary: When we call runHandlers, we must pass it a ForeignPtr. To ensure that this happens, we introduce a wrapper that receives a plain Ptr and converts it into a ForeignPtr. Then we adjust startSignalHandlers in rts/posix/Signals.c to call the wrapper instead of calling runHandlers directly. Reviewers: hvr, austin, rwbarton, simonmar Reviewed By: austin, simonmar Subscribers: simonmar, thomie, carter Differential Revision: https://phabricator.haskell.org/D515 GHC Trac Issues: #9817 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 10 10:21:45 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Dec 2014 10:21:45 -0000 Subject: [GHC] #7015: Add support for 'static' In-Reply-To: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> References: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> Message-ID: <059.0e34432b4d9408a747cba44882e8aafe@haskell.org> #7015: Add support for 'static' -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature | Status: new request | Milestone: 7.12.1 Priority: normal | Version: 7.4.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D119, | Phab:D550 | -------------------------------------+------------------------------------- Comment (by facundo.dominguez): > Alternatively, we can milestone this to 7.10.1 and close it, and track future improvements through separate tickets. What do you think, Facundo? I think this is best to give its own space to the discussions arising from further work. > (Note, adding the old ?Phab:D119 to the revision list still, mostly to keep track of historical attempts. ...) Quite appropriate. Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 10 10:50:57 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Dec 2014 10:50:57 -0000 Subject: [GHC] #8624: -ddump-splices-file In-Reply-To: <048.f5eead94409241401357105f8bb65a4f@haskell.org> References: <048.f5eead94409241401357105f8bb65a4f@haskell.org> Message-ID: <063.7fe160f712c0c2af4c5370c51b0159da@haskell.org> #8624: -ddump-splices-file -------------------------------------+------------------------------------- Reporter: GregWeber | Owner: Type: feature | Status: patch request | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | https://phabricator.haskell.org/D518| -------------------------------------+------------------------------------- Comment (by thomie): Replying to [comment:20 GregWeber]: > The design for this ticket is that a user always wants to save it to a file, and that should not have to make all other dumps go to a file. So this allows `-dth-file` and another dump flag to be used at the same time. Why is that useful? > Additionally, I want a `.hs` file to signify that the output is valid Haskell, not just a dump in an ad-hoc format, whereas with dumping the convention is `dump-FLAG`. This convention could be changed, `-ddump-th -ddump-to-file` would dump to a `.th.hs` file. A better name than `-dth-file` or `-dth-dec-file` could be `-dth-to-file`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 10 11:04:07 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Dec 2014 11:04:07 -0000 Subject: [GHC] #9569: Tuple constraints don't work right In-Reply-To: <046.31f45b75873be125a1cc8887558fe856@haskell.org> References: <046.31f45b75873be125a1cc8887558fe856@haskell.org> Message-ID: <061.3a41a4bfb860eeeb7f39c5f4bd91c150@haskell.org> #9569: Tuple constraints don't work right -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | polykinds/T9569, | typecheck/should_compile/T9569a | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): GHC's behaviour for `-XImpredicativeTypes` is wildly unpredicatable; it's really not a supported feature at all. Does it matter to you? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 10 15:21:54 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Dec 2014 15:21:54 -0000 Subject: [GHC] #7015: Add support for 'static' In-Reply-To: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> References: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> Message-ID: <059.85f66e7da3388b438b3a32c66a2076bd@haskell.org> #7015: Add support for 'static' -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature | Status: new request | Milestone: 7.12.1 Priority: normal | Version: 7.4.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D119, | Phab:D550 | -------------------------------------+------------------------------------- Comment (by goldfire): Quick note: there is nothing in the release notes about this significant feature. Please add. Thanks for doing all of this! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 10 15:38:07 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Dec 2014 15:38:07 -0000 Subject: [GHC] #8624: -ddump-splices-file In-Reply-To: <048.f5eead94409241401357105f8bb65a4f@haskell.org> References: <048.f5eead94409241401357105f8bb65a4f@haskell.org> Message-ID: <063.a741892bea856b766dd4e7cb066e9060@haskell.org> #8624: -ddump-splices-file -------------------------------------+------------------------------------- Reporter: GregWeber | Owner: Type: feature | Status: patch request | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | https://phabricator.haskell.org/D518| -------------------------------------+------------------------------------- Comment (by GregWeber): It seems like you are thinking of this as another debugging dump flag? It isn't at all, it just uses the existing dump system for implementation convenience. It is designed to be always turned on (if desired) and produce output that can be checked into source control. This should not effect whether actual dump flags are sent to stdout or to a file. I think `-to-` was supposed to help distinguish between dumping to stdout or to a file, so it doesn't seem necessary for something that always creates a file. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 10 15:58:59 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Dec 2014 15:58:59 -0000 Subject: [GHC] #8624: -ddump-splices-file In-Reply-To: <048.f5eead94409241401357105f8bb65a4f@haskell.org> References: <048.f5eead94409241401357105f8bb65a4f@haskell.org> Message-ID: <063.6e6480e5ab2a824e9c740f83a4218657@haskell.org> #8624: -ddump-splices-file -------------------------------------+------------------------------------- Reporter: GregWeber | Owner: Type: feature | Status: patch request | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | https://phabricator.haskell.org/D518| -------------------------------------+------------------------------------- Comment (by thomie): Thank you, that clears things up for me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 10 16:00:22 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Dec 2014 16:00:22 -0000 Subject: [GHC] #9872: Runing type functions is too slow In-Reply-To: <046.39f8cd7bfe0ce27cb6afb75f2059ad40@haskell.org> References: <046.39f8cd7bfe0ce27cb6afb75f2059ad40@haskell.org> Message-ID: <061.d3314c7dfe00550baf963ccac111350f@haskell.org> #9872: Runing type functions is too slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"13b0b460d365828c7d41b39d2ce7d5bbe4c69f98/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="13b0b460d365828c7d41b39d2ce7d5bbe4c69f98" Reorganise the work list, so that flattening goals are treated in the right order Trac #9872 showed the importance of processing goals in depth-first, so that we do not build up a huge pool of suspended function calls, waiting for their children to fire. There is a detailed explanation in Note [The flattening work list] in TcFlatten The effect for Trac #9872 (slow1.hs) is dramatic. We go from too long to wait down to 28Gbyte allocation. GHC 7.8.3 did 116Gbyte allocation! }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 10 16:00:22 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Dec 2014 16:00:22 -0000 Subject: [GHC] #9872: Runing type functions is too slow In-Reply-To: <046.39f8cd7bfe0ce27cb6afb75f2059ad40@haskell.org> References: <046.39f8cd7bfe0ce27cb6afb75f2059ad40@haskell.org> Message-ID: <061.209e36241b8cfbe9d7580d0e1f00672b@haskell.org> #9872: Runing type functions is too slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"fca85c9b1617417a6170f3591a29d1fe36d35da5/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="fca85c9b1617417a6170f3591a29d1fe36d35da5" Tests for Trac #9872 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 10 17:01:48 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Dec 2014 17:01:48 -0000 Subject: [GHC] #9874: Unhandled exception in Phab In-Reply-To: <047.1109ac3947d54912be92b848b61adae5@haskell.org> References: <047.1109ac3947d54912be92b848b61adae5@haskell.org> Message-ID: <062.20a418e7a6ec13bf703692cef3fa16e3@haskell.org> #9874: Unhandled exception in Phab -------------------------------------+------------------------------------- Reporter: goldfire | Owner: hvr Type: bug | Status: closed Priority: normal | Milestone: Component: Trac & Git | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: thoughtpolice (added) * status: new => closed * resolution: => fixed Comment: This should have been fixed in upstream [https://secure.phabricator.com/T6720 Phabricator], and already deployed by thoughtpolice. From `#haskell-infrastructure` irc: {{{ 14-12-10T01:33:26 < thoughtpolice > phaskell: log "upgrade done; filed upstream bug https://secure.phabricator.com/T6720" 14-12-10T01:50:12 < thoughtpolice > phaskell: log "one more upgrade; fixed upstream https://secure.phabricator.com/T6720" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 10 17:10:09 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Dec 2014 17:10:09 -0000 Subject: [GHC] #9872: Runing type functions is too slow In-Reply-To: <046.39f8cd7bfe0ce27cb6afb75f2059ad40@haskell.org> References: <046.39f8cd7bfe0ce27cb6afb75f2059ad40@haskell.org> Message-ID: <061.efbb3e58556d9d6aa7d387331fba6db1@haskell.org> #9872: Runing type functions is too slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: Actually with the other changes I've made in the last day or two, allocation in HEAD for T9872a is down to 5.5Gbytes. Thanks for these examples, Gergo. I claim victory. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 10 18:16:29 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Dec 2014 18:16:29 -0000 Subject: [GHC] #9876: mkdir errors when running `make sdist` In-Reply-To: <048.4e2ab1a0df62a578daea8b81b25fe988@haskell.org> References: <048.4e2ab1a0df62a578daea8b81b25fe988@haskell.org> Message-ID: <063.cc4961d465e82ef916a70ac9d29e3d6f@haskell.org> #9876: mkdir errors when running `make sdist` -------------------------------------+------------------------------------- Reporter: joehillen | Owner: joehillen Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: Phab:D566 | -------------------------------------+------------------------------------- Description changed by joehillen: Old description: > Hi. Newcomer here. I was taking a look at #9095 and I get the following > errors when running `make sdist`. > > {{{ > "rm" -f sdistprep/ghc-7.9.20141208-windows-extra-src.tar.bz2 > mkdir sdistprep > mkdir: cannot create directory ?sdistprep?: File exists > make[1]: [sdist-windows-tarballs-prep] Error 1 (ignored) > mkdir sdistprep/windows-tarballs > mkdir sdistprep/windows-tarballs/ghc-7.9.20141208 > mkdir sdistprep/windows-tarballs/ghc-7.9.20141208/ghc-tarballs > cd sdistprep/windows-tarballs/ghc-7.9.20141208/ghc-tarballs && lndir > /home/joe/src/ghc/ghc-tarballs > "rm" -rf sdistprep/windows-tarballs/ghc-7.9.20141208/ghc-tarballs/.git > cd sdistprep/windows-tarballs && "/bin/tar" chf - ghc-7.9.20141208 2> > windows_extra_src_ghc_log | bzip2 -c > > /home/joe/src/ghc/sdistprep/ghc-7.9.20141208-windows-extra-src.tar.bz2 > "rm" -rf sdistprep/testsuite-ghc > "rm" -f sdistprep/ghc-7.9.20141208-testsuite.tar.bz2 > mkdir sdistprep > mkdir: cannot create directory ?sdistprep?: File exists > make[1]: [sdist-testsuite-prep] Error 1 (ignored) > mkdir sdistprep/testsuite-ghc > mkdir sdistprep/testsuite-ghc/ghc-7.9.20141208 > mkdir sdistprep/testsuite-ghc/ghc-7.9.20141208/testsuite > cd sdistprep/testsuite-ghc/ghc-7.9.20141208/testsuite && lndir > /home/joe/src/ghc/testsuite > /home/joe/src/ghc/testsuite: No such file or directory > make[1]: *** [sdist-testsuite-prep] Error 1 > make: *** [sdist] Error 2 > }}} > > Generally when using `mkdir` in a Makefile I've found it best to always > use `mkdir -p` just like how you should always use `rm -f`. > > It's a simple fix. I'm submitting a patch for it. New description: Hi. Newcomer here. I was taking a look at #9095 and I get the following errors when running `make sdist`. {{{ "rm" -f sdistprep/ghc-7.9.20141208-windows-extra-src.tar.bz2 mkdir sdistprep mkdir: cannot create directory ?sdistprep?: File exists make[1]: [sdist-windows-tarballs-prep] Error 1 (ignored) mkdir sdistprep/windows-tarballs mkdir sdistprep/windows-tarballs/ghc-7.9.20141208 mkdir sdistprep/windows-tarballs/ghc-7.9.20141208/ghc-tarballs cd sdistprep/windows-tarballs/ghc-7.9.20141208/ghc-tarballs && lndir /home/joe/src/ghc/ghc-tarballs "rm" -rf sdistprep/windows-tarballs/ghc-7.9.20141208/ghc-tarballs/.git cd sdistprep/windows-tarballs && "/bin/tar" chf - ghc-7.9.20141208 2> windows_extra_src_ghc_log | bzip2 -c > /home/joe/src/ghc/sdistprep/ghc-7.9.20141208-windows-extra-src.tar.bz2 "rm" -rf sdistprep/testsuite-ghc "rm" -f sdistprep/ghc-7.9.20141208-testsuite.tar.bz2 mkdir sdistprep mkdir: cannot create directory ?sdistprep?: File exists make[1]: [sdist-testsuite-prep] Error 1 (ignored) }}} Generally when using `mkdir` in a Makefile I've found it best to always use `mkdir -p` just like how you should always use `rm -f`. It's a simple fix. I'm submitting a patch for it. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 10 20:12:26 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Dec 2014 20:12:26 -0000 Subject: [GHC] #3927: Incomplete/overlapped pattern warnings + GADTs = inadequate In-Reply-To: <046.0473c92f4a34c84959f5237ada18226b@haskell.org> References: <046.0473c92f4a34c84959f5237ada18226b@haskell.org> Message-ID: <061.c48db956a16863039941854eaeee9ff0@haskell.org> #3927: Incomplete/overlapped pattern warnings + GADTs = inadequate -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 6.12.1 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #4139 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by vlopez): Instead of fixing the exhaustiveness checker, we could have some way to tell the compiler that a particular branch in a case expression (or function definition) is inaccessible. A possible syntax for this would be an "empty guard" (a vertical bar immediately followed by a semicolon). {{{ data T a where T1 :: T Int T2 :: T Bool f1 :: T a -> T a -> Bool f1 T1 T1 = True f1 T2 T2 = False f1 T1 T2 |; -- absurd branch f1 T2 T1 |; -- another absurd branch f2 :: T a -> T a -> Bool f2 a b = case (a,b) of (T1, T1) -> True (T2, T2) -> False (T1, T2) |; (T2, T1) |; }}} * In GHC 7.8.3, it results in an immediate parser error at the `;`, so it shouldn't conflict with other features. * It works well with the indentation heuristics in emacs haskell-mode (and hopefully with other editors too). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 10 22:07:37 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Dec 2014 22:07:37 -0000 Subject: [GHC] #9569: Tuple constraints don't work right In-Reply-To: <046.31f45b75873be125a1cc8887558fe856@haskell.org> References: <046.31f45b75873be125a1cc8887558fe856@haskell.org> Message-ID: <061.82058b7739f9be1de53d9b134883cce9@haskell.org> #9569: Tuple constraints don't work right -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | polykinds/T9569, | typecheck/should_compile/T9569a | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by luite): I just wanted to check if this is not an unexpected side effect of the patch, since I didn't see any mention of this. I avoid `-XImpredicativeTypes` in my own code, but GHCJS indirectly depends on the `monad-control` and `lifted-base` packages, which fail to build now because they do use it, so I can't test GHCJS anymore on the latest head. I haven't found a workaround yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 10 22:17:54 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Dec 2014 22:17:54 -0000 Subject: [GHC] #9569: Tuple constraints don't work right In-Reply-To: <046.31f45b75873be125a1cc8887558fe856@haskell.org> References: <046.31f45b75873be125a1cc8887558fe856@haskell.org> Message-ID: <061.7c762b8947e2162c6aa80ca602c15b8b@haskell.org> #9569: Tuple constraints don't work right -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | polykinds/T9569, | typecheck/should_compile/T9569a | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): OK, well `monad-control` and `lifted-base` are living (very) dangerously. I make no claims whatever about GHC's support for impredicativity. Might be worth talking to the maintainers about fixing that; it's usually a question of adding some newtype wrappers. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 10 22:42:17 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Dec 2014 22:42:17 -0000 Subject: [GHC] #9569: Tuple constraints don't work right In-Reply-To: <046.31f45b75873be125a1cc8887558fe856@haskell.org> References: <046.31f45b75873be125a1cc8887558fe856@haskell.org> Message-ID: <061.ab3482e9ad5bb9b276fcee99b4078b02@haskell.org> #9569: Tuple constraints don't work right -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | polykinds/T9569, | typecheck/should_compile/T9569a | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by luite): I'll let them know, but I might first do some quick and dirty patching of the dependencies to get my stuff working again. I've been working on a new code generator with much reduced (dangerous) dependencies (and other improvements like a typed intermediate rep) to avoid problems like this, but unfortunately didn't have it ready in time for 7.10. I've been increasingly unhappy with current approach of developing against the stable GHC API, porting everything to the next version at the end of the cycle, so I'll announce/discuss some changes on `ghc-devs` for the next iteration. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 10 22:47:26 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Dec 2014 22:47:26 -0000 Subject: [GHC] #9877: ForeignImport coercion evaluated before typechecking Message-ID: <045.98c4bf8afa11b5771190e9909bffe695@haskell.org> #9877: ForeignImport coercion evaluated before typechecking -------------------------------------+------------------------------------- Reporter: varosi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: Compile- Difficulty: Unknown | time crash Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Under Windows 8.1 x64 with Haskell Platform 2014.02 and EclipseFP I got: buildwrapper.exe: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-unknown-mingw32): ForeignImport coercion evaluated before typechecking on the first line of file that has: {{{ #!div style="font-size: 80%" Code highlighting: {{{#!haskell {-# LANGUAGE ForeignFunctionInterface, RankNTypes, OverloadedStrings, ScopedTypeVariables #-} module Persist( persistWrite, persistRead ) where import System.Win32.Types import Graphics.Win32.GDI.Types import Foreign.C.String import Foreign.Marshal.Array import Control.Exception foreign import ccall unsafe "SHGetFolderPathW" cSHGetFolderPathW :: HWND -> INT -> HANDLE -> DWORD -> CWString -> IO LONG }}} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 10 22:48:25 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Dec 2014 22:48:25 -0000 Subject: [GHC] #9877: ForeignImport coercion evaluated before typechecking In-Reply-To: <045.98c4bf8afa11b5771190e9909bffe695@haskell.org> References: <045.98c4bf8afa11b5771190e9909bffe695@haskell.org> Message-ID: <060.e1895784f2f6d895d625a0e93da6aa42@haskell.org> #9877: ForeignImport coercion evaluated before typechecking -------------------------------------+------------------------------------- Reporter: varosi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Compile- | Difficulty: Unknown time crash | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Description changed by varosi: Old description: > Under Windows 8.1 x64 with Haskell Platform 2014.02 and EclipseFP I got: > buildwrapper.exe: panic! (the 'impossible' happened) > (GHC version 7.8.3 for x86_64-unknown-mingw32): > ForeignImport coercion evaluated before typechecking > on the first line of file that has: > {{{ > #!div style="font-size: 80%" > Code highlighting: > {{{#!haskell > {-# LANGUAGE ForeignFunctionInterface, RankNTypes, OverloadedStrings, > ScopedTypeVariables #-} > module Persist( persistWrite, persistRead ) where > > import System.Win32.Types > import Graphics.Win32.GDI.Types > import Foreign.C.String > import Foreign.Marshal.Array > import Control.Exception > > foreign import ccall unsafe "SHGetFolderPathW" > cSHGetFolderPathW :: HWND -> INT -> HANDLE -> DWORD -> CWString -> IO > LONG > }}} > }}} New description: Under Windows 8.1 x64 with Haskell Platform 2014.02 and EclipseFP I got: {{{ buildwrapper.exe: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-unknown-mingw32): ForeignImport coercion evaluated before typechecking }}} on the first line of file that has: {{{ #!div style="font-size: 80%" Code highlighting: {{{#!haskell {-# LANGUAGE ForeignFunctionInterface, RankNTypes, OverloadedStrings, ScopedTypeVariables #-} module Persist( persistWrite, persistRead ) where import System.Win32.Types import Graphics.Win32.GDI.Types import Foreign.C.String import Foreign.Marshal.Array import Control.Exception foreign import ccall unsafe "SHGetFolderPathW" cSHGetFolderPathW :: HWND -> INT -> HANDLE -> DWORD -> CWString -> IO LONG }}} }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 11 00:56:13 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Dec 2014 00:56:13 -0000 Subject: [GHC] #9569: Tuple constraints don't work right In-Reply-To: <046.31f45b75873be125a1cc8887558fe856@haskell.org> References: <046.31f45b75873be125a1cc8887558fe856@haskell.org> Message-ID: <061.8dd1c353dcc9e5b7d2e039a1847f61d3@haskell.org> #9569: Tuple constraints don't work right -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | polykinds/T9569, | typecheck/should_compile/T9569a | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by basvandijk): Maintainer of `monad-control` here. Do I get the following right (I haven't looked at this in detail yet): To work around not having to use the unstable `ImpredicativeTypes` I should turn the [https://github.com/basvandijk/monad- control/blob/master/Control/Monad/Trans/Control.hs#L143 Run] type synonym into a `newtype`. Then at every call site of [https://github.com/basvandijk/monad- control/blob/master/Control/Monad/Trans/Control.hs#L127 liftWith] I need to unwrap the `newtype` to be able to apply the inner function. ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 11 00:57:11 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Dec 2014 00:57:11 -0000 Subject: [GHC] #9569: Tuple constraints don't work right In-Reply-To: <046.31f45b75873be125a1cc8887558fe856@haskell.org> References: <046.31f45b75873be125a1cc8887558fe856@haskell.org> Message-ID: <061.1123f8289f99b4f086dec554df4dabaa@haskell.org> #9569: Tuple constraints don't work right -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | polykinds/T9569, | typecheck/should_compile/T9569a | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by basvandijk): * cc: basvandijk (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 11 02:50:24 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Dec 2014 02:50:24 -0000 Subject: [GHC] #9872: Runing type functions is too slow In-Reply-To: <046.39f8cd7bfe0ce27cb6afb75f2059ad40@haskell.org> References: <046.39f8cd7bfe0ce27cb6afb75f2059ad40@haskell.org> Message-ID: <061.9a27bd02c872dbf6d239c012647e76a8@haskell.org> #9872: Runing type functions is too slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by cactus): You might want to also add, as a test, the version that uses closed type families without datakinds: https://gist.github.com/gergoerdi/c5f3522d41e603559dfc -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 11 09:32:58 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Dec 2014 09:32:58 -0000 Subject: [GHC] #9872: Runing type functions is too slow In-Reply-To: <046.39f8cd7bfe0ce27cb6afb75f2059ad40@haskell.org> References: <046.39f8cd7bfe0ce27cb6afb75f2059ad40@haskell.org> Message-ID: <061.7bd3b8a16dacf31c4e97e75d64ee4cef@haskell.org> #9872: Runing type functions is too slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): yes, both tests are in commit fca85c9b1617417a6170f3591a29d1fe36d35da5/ghc -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 11 09:43:10 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Dec 2014 09:43:10 -0000 Subject: [GHC] #9569: Tuple constraints don't work right In-Reply-To: <046.31f45b75873be125a1cc8887558fe856@haskell.org> References: <046.31f45b75873be125a1cc8887558fe856@haskell.org> Message-ID: <061.cf649e0c65e8f19021b44c6d4f863851@haskell.org> #9569: Tuple constraints don't work right -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | polykinds/T9569, | typecheck/should_compile/T9569a | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Bas, I'm not sure. I don't see anything impredicative about `Run`, just higher rank. Moreover, I see no mention of `-XImpredicativeTypes` in the LANGUAGE extensions or cabal file. So I'm confused. What's the problem here? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 11 09:51:57 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Dec 2014 09:51:57 -0000 Subject: [GHC] #9872: Runing type functions is too slow In-Reply-To: <046.39f8cd7bfe0ce27cb6afb75f2059ad40@haskell.org> References: <046.39f8cd7bfe0ce27cb6afb75f2059ad40@haskell.org> Message-ID: <061.51f4db05fb89f92ba9c129f51676e06d@haskell.org> #9872: Runing type functions is too slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by cactus): but the one I linked to in my latest comment is a third version: closed type families, but everything is on `*`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 11 09:58:37 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Dec 2014 09:58:37 -0000 Subject: [GHC] #9872: Runing type functions is too slow In-Reply-To: <046.39f8cd7bfe0ce27cb6afb75f2059ad40@haskell.org> References: <046.39f8cd7bfe0ce27cb6afb75f2059ad40@haskell.org> Message-ID: <061.e4281a366292c0dc7d9227fdb88126bd@haskell.org> #9872: Runing type functions is too slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Oh ok. Do you think it's significantly different? Or just different? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 11 10:04:41 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Dec 2014 10:04:41 -0000 Subject: [GHC] #9872: Runing type functions is too slow In-Reply-To: <046.39f8cd7bfe0ce27cb6afb75f2059ad40@haskell.org> References: <046.39f8cd7bfe0ce27cb6afb75f2059ad40@haskell.org> Message-ID: <061.5ec800b79962e9aee8ed1205ae48e6de@haskell.org> #9872: Runing type functions is too slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by cactus): I don't know enough about the internals of the type family normalizer to know if it makes a difference or not; but since the datakinds one is closed-world and this is open-world, it might. Although now that I think about it, since the type families in question are closed, it's not ''really'' open-world anyway... I don't know. Your call. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 11 10:11:03 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Dec 2014 10:11:03 -0000 Subject: [GHC] #9872: Runing type functions is too slow In-Reply-To: <046.39f8cd7bfe0ce27cb6afb75f2059ad40@haskell.org> References: <046.39f8cd7bfe0ce27cb6afb75f2059ad40@haskell.org> Message-ID: <061.9a193d57a16064fd4078920b6a587b49@haskell.org> #9872: Runing type functions is too slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"7256213843b80d75a86f033be77516a62d56044a/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="7256213843b80d75a86f033be77516a62d56044a" Add a third test variant to Trac #9872 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 11 10:17:03 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Dec 2014 10:17:03 -0000 Subject: [GHC] #1168: Optimisation sometimes decreases sharing in IO code In-Reply-To: <047.1e9bce153303809272446b6c0aede02d@haskell.org> References: <047.1e9bce153303809272446b6c0aede02d@haskell.org> Message-ID: <062.f18a596d212244b460772ae20d42d16f@haskell.org> #1168: Optimisation sometimes decreases sharing in IO code -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: 6.6 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | nofib/spectral/calendar | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): David, it's be very helpful if you could * Specify the exact steps to reproduce the performance changes you see, with and without `-fno-state-hack`. * Say which version of GHC you are using Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 11 10:19:14 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Dec 2014 10:19:14 -0000 Subject: [GHC] #2986: :info printing instances often isn't wanted In-Reply-To: <043.cc7348275a1e64e6491d1ee94042b0a6@haskell.org> References: <043.cc7348275a1e64e6491d1ee94042b0a6@haskell.org> Message-ID: <058.2d5a9318cd935629ae3131febea09547@haskell.org> #2986: :info printing instances often isn't wanted -------------------------------------+------------------------------------- Reporter: Remi | Owner: Remi Type: feature | Status: new request | Milestone: 7.10.1 Priority: lowest | Version: 6.10.1 Component: GHCi | Keywords: :info instances Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Maybe put up a patch on Phab for review, if you think you are done? Don't forget tests, user manual... Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 11 10:21:43 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Dec 2014 10:21:43 -0000 Subject: [GHC] #9877: ForeignImport coercion evaluated before typechecking In-Reply-To: <045.98c4bf8afa11b5771190e9909bffe695@haskell.org> References: <045.98c4bf8afa11b5771190e9909bffe695@haskell.org> Message-ID: <060.a42716ee4e196d74449915d2920fcb40@haskell.org> #9877: ForeignImport coercion evaluated before typechecking -------------------------------------+------------------------------------- Reporter: varosi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Compile- | Difficulty: Unknown time crash | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Can you give exact steps to reproduce? Does it have to depend on `Graphics.Win32`? Does the compiler crash, or does it crash when you run the program? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 11 10:22:08 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Dec 2014 10:22:08 -0000 Subject: [GHC] #9569: Tuple constraints don't work right In-Reply-To: <046.31f45b75873be125a1cc8887558fe856@haskell.org> References: <046.31f45b75873be125a1cc8887558fe856@haskell.org> Message-ID: <061.2eb206f31910fe8902de8cbf8476d801@haskell.org> #9569: Tuple constraints don't work right -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | polykinds/T9569, | typecheck/should_compile/T9569a | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by basvandijk): I think I was confused. The problem is not in `monad-control` but in `lifted-base` (which depends on `monad-control`). If I remove the `{-# LANGUAGE ImpredicativeTypes #-}` from `Control.Exception.Lifted` I get the following error on [https://github.com/basvandijk/lifted- base/blob/master/Control/Exception/Lifted.hs#L268 mask]: {{{ Control/Exception/Lifted.hs:268:8: Cannot instantiate unification variable ?a2? with a type involving foralls: (forall a. m a -> m a) -> m b Perhaps you want ImpredicativeTypes In the expression: liftBaseOp E.mask . liftRestore In an equation for ?mask?: mask = liftBaseOp E.mask . liftRestore }}} Is this easy solvable (preferably without changing the API)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 11 10:33:59 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Dec 2014 10:33:59 -0000 Subject: [GHC] #9569: Tuple constraints don't work right In-Reply-To: <046.31f45b75873be125a1cc8887558fe856@haskell.org> References: <046.31f45b75873be125a1cc8887558fe856@haskell.org> Message-ID: <061.98749044d19617b956ddd74f8c4ee51a@haskell.org> #9569: Tuple constraints don't work right -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | polykinds/T9569, | typecheck/should_compile/T9569a | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): I'd eta-expand `mask`. Using `(.)` on higher rank types ''does'' require impredicativity. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 11 10:35:52 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Dec 2014 10:35:52 -0000 Subject: [GHC] #8984: Improve output of failed GeneralizedNewtypeDeriving coercion due to type roles In-Reply-To: <044.9146c0f21c1d5c0ac4fad078a63640bb@haskell.org> References: <044.9146c0f21c1d5c0ac4fad078a63640bb@haskell.org> Message-ID: <059.2e2e2235711824d1c85c642b60e1faf2@haskell.org> #8984: Improve output of failed GeneralizedNewtypeDeriving coercion due to type roles -------------------------------------+------------------------------------- Reporter: haasn | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.1 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes, I agree with your proposal. We should not blithely accept random (and perhaps unsatisfiable) equality constraints in `deriving` contexts. You can always specify the context with standalone-deriving if you want. Weill you execute on this? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 11 10:38:53 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Dec 2014 10:38:53 -0000 Subject: [GHC] #9867: PatternSynonyms + ScopedTypeVariables triggers an internal error In-Reply-To: <046.5cdd1cb9d606767d1869bca60906658f@haskell.org> References: <046.5cdd1cb9d606767d1869bca60906658f@haskell.org> Message-ID: <061.5e52eebe3a5b6d7e7c6e3e4e4551c5c6@haskell.org> #9867: PatternSynonyms + ScopedTypeVariables triggers an internal error -------------------------------------+------------------------------------- Reporter: antalsz | Owner: cactus Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: => cactus Comment: Gergo, would you like to look at this? I think we should write down the rules for scoped type variables in pattern synonym definitions! Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 11 10:44:12 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Dec 2014 10:44:12 -0000 Subject: [GHC] #9090: Untouchable higher-kinded type variable in connection with RankNTypes, ConstraintKinds and TypeFamilies In-Reply-To: <047.6b2af23e852e3dacdefeac6524bf6813@haskell.org> References: <047.6b2af23e852e3dacdefeac6524bf6813@haskell.org> Message-ID: <062.646f7258bdd97ee0cfcd4b1d83ad09de@haskell.org> #9090: Untouchable higher-kinded type variable in connection with RankNTypes, ConstraintKinds and TypeFamilies -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): This is indeed fixed! Test added. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 11 10:44:40 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Dec 2014 10:44:40 -0000 Subject: [GHC] #9090: Untouchable higher-kinded type variable in connection with RankNTypes, ConstraintKinds and TypeFamilies In-Reply-To: <047.6b2af23e852e3dacdefeac6524bf6813@haskell.org> References: <047.6b2af23e852e3dacdefeac6524bf6813@haskell.org> Message-ID: <062.453b8e2a662b3916e1731f0e939e6ba5@haskell.org> #9090: Untouchable higher-kinded type variable in connection with RankNTypes, ConstraintKinds and TypeFamilies -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"8c825633135e24f6a0bbcc2c4097afada6ad6167/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="8c825633135e24f6a0bbcc2c4097afada6ad6167" Test Trac #9090 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 11 10:45:33 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Dec 2014 10:45:33 -0000 Subject: [GHC] #9090: Untouchable higher-kinded type variable in connection with RankNTypes, ConstraintKinds and TypeFamilies In-Reply-To: <047.6b2af23e852e3dacdefeac6524bf6813@haskell.org> References: <047.6b2af23e852e3dacdefeac6524bf6813@haskell.org> Message-ID: <062.efb5b3fb70ba96f7a58192108979e916@haskell.org> #9090: Untouchable higher-kinded type variable in connection with RankNTypes, ConstraintKinds and TypeFamilies -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 (Type checker) | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: indexed- | types/should_compile/T9090 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => indexed-types/should_compile/T9090 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 11 10:48:05 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Dec 2014 10:48:05 -0000 Subject: [GHC] #9404: tcInferRho muddies the waters In-Reply-To: <047.891f32808c0ce61dfe70309b4843a6ab@haskell.org> References: <047.891f32808c0ce61dfe70309b4843a6ab@haskell.org> Message-ID: <062.f6fc595d73e2a9451b436ef0018df230@haskell.org> #9404: tcInferRho muddies the waters -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D469 | -------------------------------------+------------------------------------- Changes (by simonpj): * status: patch => closed * resolution: => fixed Comment: Yes I agree. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 11 11:01:43 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Dec 2014 11:01:43 -0000 Subject: [GHC] #9878: Static pointers in GHCi cause panic Message-ID: <047.a0b4c5e0dee3f65cf24b644a915474ce@haskell.org> #9878: Static pointers in GHCi cause panic -------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: GHCi crash Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I load this module into ghci {{{#!hs {-# LANGUAGE StaticPointers #-} module Static where import GHC.StaticPtr f = deRefStaticPtr (static True) }}} and get a panic upon evaluating `f` {{{ > f ghc: panic! (the 'impossible' happened) (GHC version 7.9.20141210 for x86_64-unknown-linux): Loading temp shared object failed: /tmp/ghc30486_0/ghc30486_5.so: undefined symbol: Static_sptEntryZC0_closure Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Am I doing static pointers right? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 11 11:06:37 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Dec 2014 11:06:37 -0000 Subject: [GHC] #9878: Static pointers in GHCi cause panic In-Reply-To: <047.a0b4c5e0dee3f65cf24b644a915474ce@haskell.org> References: <047.a0b4c5e0dee3f65cf24b644a915474ce@haskell.org> Message-ID: <062.f8769e04e7e490f0a7280b82bc5a158b@haskell.org> #9878: Static pointers in GHCi cause panic -------------------------------------+------------------------------------- Reporter: monoidal | Owner: facundo.dominguez Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHCi crash | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: => facundo.dominguez -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 11 11:12:48 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Dec 2014 11:12:48 -0000 Subject: [GHC] #9878: Static pointers in GHCi cause panic In-Reply-To: <047.a0b4c5e0dee3f65cf24b644a915474ce@haskell.org> References: <047.a0b4c5e0dee3f65cf24b644a915474ce@haskell.org> Message-ID: <062.531217324093cfa714d8df62ae889370@haskell.org> #9878: Static pointers in GHCi cause panic -------------------------------------+------------------------------------- Reporter: monoidal | Owner: facundo.dominguez Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHCi crash | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by facundo.dominguez): The current `StaticPointers` implementation is not intended to be supported in GHCi. I recognize this is not documented anywhere and this should be addressed. Now, is the ability to use `StaticPointers` in GHCi essential to you? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 11 11:14:03 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Dec 2014 11:14:03 -0000 Subject: [GHC] #9878: Static pointers in GHCi cause panic In-Reply-To: <047.a0b4c5e0dee3f65cf24b644a915474ce@haskell.org> References: <047.a0b4c5e0dee3f65cf24b644a915474ce@haskell.org> Message-ID: <062.f2b2778b317fbb9cb1982017a2948986@haskell.org> #9878: Static pointers in GHCi cause panic -------------------------------------+------------------------------------- Reporter: monoidal | Owner: facundo.dominguez Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHCi crash | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by facundo.dominguez): * cc: m@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 11 11:16:44 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Dec 2014 11:16:44 -0000 Subject: [GHC] #9878: Static pointers in GHCi cause panic In-Reply-To: <047.a0b4c5e0dee3f65cf24b644a915474ce@haskell.org> References: <047.a0b4c5e0dee3f65cf24b644a915474ce@haskell.org> Message-ID: <062.171c4d30a9c52a63492d1f988f3d9b65@haskell.org> #9878: Static pointers in GHCi cause panic -------------------------------------+------------------------------------- Reporter: monoidal | Owner: facundo.dominguez Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHCi crash | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): If it doesn't work in GHCi, then yes it should be documented. And what is "it"? I think it's the `static` construct itself. Calling `deRefStaticPtr` is fine. But also it should be checked! The renamer or typechecker should produce a civilised error message when they encounter `static` in GHCi. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 11 11:28:14 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Dec 2014 11:28:14 -0000 Subject: [GHC] #9878: Static pointers in GHCi cause panic In-Reply-To: <047.a0b4c5e0dee3f65cf24b644a915474ce@haskell.org> References: <047.a0b4c5e0dee3f65cf24b644a915474ce@haskell.org> Message-ID: <062.c23c5a1a14cbaf603c110949854481e9@haskell.org> #9878: Static pointers in GHCi cause panic -------------------------------------+------------------------------------- Reporter: monoidal | Owner: facundo.dominguez Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHCi crash | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by monoidal): Support for `StaticPointers` in GHCi is not essential for me, but I agree we should give a better error message. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 11 12:21:41 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Dec 2014 12:21:41 -0000 Subject: [GHC] #9569: Tuple constraints don't work right In-Reply-To: <046.31f45b75873be125a1cc8887558fe856@haskell.org> References: <046.31f45b75873be125a1cc8887558fe856@haskell.org> Message-ID: <061.757d7ad827c7d3947df9db8dc9821e17@haskell.org> #9569: Tuple constraints don't work right -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | polykinds/T9569, | typecheck/should_compile/T9569a | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by basvandijk): Thanks for the advice. I'm now using: {{{ mask :: MonadBaseControl IO m => ((forall a. m a -> m a) -> m b) -> m b mask f = control $ \runInBase -> E.mask $ \g -> runInBase $ f $ liftBaseOp_ g }}} without using `ImpredicativeTypes`. @luite I will make a point release of `lifted-base` with this fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 11 14:05:31 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Dec 2014 14:05:31 -0000 Subject: [GHC] #9879: Panic with partial type signatures Message-ID: <047.e5c88bd3f1ae8bc6f7d19321ba46479c@haskell.org> #9879: Panic with partial type signatures -------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.9 checker) | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Attempting to check kind of type hole `_` in GHCi or putting it in a TH quotation causes a panic `rnHsTyKi HsWildcardTy`: {{{ :kind _ let x = [t|_|] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 11 17:01:02 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Dec 2014 17:01:02 -0000 Subject: [GHC] #8240: Better error messages for type family constraints In-Reply-To: <046.40d29d251117f16b01fc92ed85abde32@haskell.org> References: <046.40d29d251117f16b01fc92ed85abde32@haskell.org> Message-ID: <061.1c158db849752ebb236bd70f61aefc41@haskell.org> #8240: Better error messages for type family constraints -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: This is a dup of #9318, which is fixed Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 11 17:12:04 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Dec 2014 17:12:04 -0000 Subject: [GHC] #9567: tc124 fails as '*** Core Lint errors : in result of Simplifier ***' in WAY=optasm In-Reply-To: <045.3ecedf0980b076ccd1110fcb386f8214@haskell.org> References: <045.3ecedf0980b076ccd1110fcb386f8214@haskell.org> Message-ID: <060.4075a8d424d439eb26f22b5e747c453b@haskell.org> #9567: tc124 fails as '*** Core Lint errors : in result of Simplifier ***' in WAY=optasm -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: x86_64 (amd64) Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: tc124 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"b8392ae76a6d39c57be94b5ba041c450ab479e2b/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="b8392ae76a6d39c57be94b5ba041c450ab479e2b" Fix an obscure but terrible bug in the simplifier (Trac #9567) The issue was that contInputType simply gave the wrong answer for type applications. There was no way to fix contInputType; it just didn't have enough information. So I did this: * Split the ApplyTo constructor of SimplUtils.SimplCont into ApplyToVal ApplyToTy I used record syntax for them; we should do this for some of the other constructors too. * The latter carries a sc_hole_ty, which is the type of the continuation's "hole" * Maintaining this type meant that I had do to something similar for SimplUtils.ArgSpec. * I renamed contInputType to contHoleType for consistency. * I did a bit of refactoring around the call to tryRules in Simplify, which was jolly confusing before. The resulting code is quite nice now. And it has the additional merit that it works. The tests are simply tc124 and T7891 with -O enabled. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 11 17:14:11 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Dec 2014 17:14:11 -0000 Subject: [GHC] #9567: tc124 fails as '*** Core Lint errors : in result of Simplifier ***' in WAY=optasm In-Reply-To: <045.3ecedf0980b076ccd1110fcb386f8214@haskell.org> References: <045.3ecedf0980b076ccd1110fcb386f8214@haskell.org> Message-ID: <060.f3248e452314a567510aec53a39f7fe1@haskell.org> #9567: tc124 fails as '*** Core Lint errors : in result of Simplifier ***' in WAY=optasm -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: Operating System: | Architecture: x86_64 (amd64) Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: | typecheck/should_compile/tc124, | T7891 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: tc124 => typecheck/should_compile/tc124, T7891 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 11 17:15:07 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Dec 2014 17:15:07 -0000 Subject: [GHC] #9566: T7891 fails as '*** Core Lint errors : in result of Simplifier ***' in WAY=optasm In-Reply-To: <045.3cb2ff90fbfcc512737c7e9a31a0031c@haskell.org> References: <045.3cb2ff90fbfcc512737c7e9a31a0031c@haskell.org> Message-ID: <060.65102e47c70f39a8742affc4281a80d2@haskell.org> #9566: T7891 fails as '*** Core Lint errors : in result of Simplifier ***' in WAY=optasm -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: Operating System: | Architecture: x86_64 (amd64) Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: T7891 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: Dup of #9567, fixed now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 11 17:16:39 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Dec 2014 17:16:39 -0000 Subject: [GHC] #9583: Simplifier ticks exhausted while compiling Cabal HEAD In-Reply-To: <045.789be2e4a91baa2c96bbb2b3ee282b27@haskell.org> References: <045.789be2e4a91baa2c96bbb2b3ee282b27@haskell.org> Message-ID: <060.e5ff9e1cd7f3d339afaba71debf3b323@haskell.org> #9583: Simplifier ticks exhausted while compiling Cabal HEAD -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: closed Priority: highest | Milestone: Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: #9630 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: In which case we can close this one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 11 17:30:45 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Dec 2014 17:30:45 -0000 Subject: [GHC] #9878: Static pointers in GHCi cause panic In-Reply-To: <047.a0b4c5e0dee3f65cf24b644a915474ce@haskell.org> References: <047.a0b4c5e0dee3f65cf24b644a915474ce@haskell.org> Message-ID: <062.77d971f35239777b0240076118010f9b@haskell.org> #9878: Static pointers in GHCi cause panic -------------------------------------+------------------------------------- Reporter: monoidal | Owner: facundo.dominguez Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHCi crash | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by facundo.dominguez): For the record, this fails for me when GHCi interprets the code. Compiling the code seems to work. {{{ Prelude> :set -fobject-code Prelude> :l Static [1 of 1] Compiling Static ( Static.hs, Static.o ) Ok, modules loaded: Static. Prelude Static> f True }}} Trying to access `GHC.StaticPtr.staticPtrKeys` segfaults: {{{ Prelude Static> GHC.StaticPtr.staticPtrKeys Segmentation fault }}} But entering GHCi again so the preexisting .o is used allows to use `staticPtrKeys`: {{{ Prelude> :l Static Ok, modules loaded: Static. Prelude Static> f True Prelude Static> GHC.StaticPtr.staticPtrKeys [df8d46d69bf517c3ca5f48d44485169a] }}} ... and if the call to `f` is omitted `staticPtrkeys` does not show the pointer: {{{ Prelude> :l Static Ok, modules loaded: Static. Prelude Static> GHC.StaticPtr.staticPtrKeys [] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 11 17:32:45 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Dec 2014 17:32:45 -0000 Subject: [GHC] #9878: Static pointers in GHCi cause panic In-Reply-To: <047.a0b4c5e0dee3f65cf24b644a915474ce@haskell.org> References: <047.a0b4c5e0dee3f65cf24b644a915474ce@haskell.org> Message-ID: <062.4aadbb1553fa723bfda5903633eafbb2@haskell.org> #9878: Static pointers in GHCi cause panic -------------------------------------+------------------------------------- Reporter: monoidal | Owner: facundo.dominguez Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHCi crash | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by facundo.dominguez): * cc: alexander.vershilov@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 11 18:48:51 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Dec 2014 18:48:51 -0000 Subject: [GHC] #9877: ForeignImport coercion evaluated before typechecking In-Reply-To: <045.98c4bf8afa11b5771190e9909bffe695@haskell.org> References: <045.98c4bf8afa11b5771190e9909bffe695@haskell.org> Message-ID: <060.7e7520e4c9346afa175da83cc4ecb48d@haskell.org> #9877: ForeignImport coercion evaluated before typechecking -------------------------------------+------------------------------------- Reporter: varosi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Compile- | Difficulty: Unknown time crash | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by varosi): Compiler is crashing I think. I have not written buildwrapper project. But it is happening during code writting and not during run-time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 11 18:52:34 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Dec 2014 18:52:34 -0000 Subject: [GHC] #9877: ForeignImport coercion evaluated before typechecking In-Reply-To: <045.98c4bf8afa11b5771190e9909bffe695@haskell.org> References: <045.98c4bf8afa11b5771190e9909bffe695@haskell.org> Message-ID: <060.9b3b441e7c5e2588ed1ce403b419ab02@haskell.org> #9877: ForeignImport coercion evaluated before typechecking -------------------------------------+------------------------------------- Reporter: varosi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Compile- | Difficulty: Unknown time crash | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by varosi): If I comment "import Graphics.Win32...." line it gives another error that is normal, because of missing import. So it is not crashing then. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 11 20:16:46 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Dec 2014 20:16:46 -0000 Subject: [GHC] #9877: ForeignImport coercion evaluated before typechecking In-Reply-To: <045.98c4bf8afa11b5771190e9909bffe695@haskell.org> References: <045.98c4bf8afa11b5771190e9909bffe695@haskell.org> Message-ID: <060.1d075a0b5337c3dfcf68e72aa9a83a6d@haskell.org> #9877: ForeignImport coercion evaluated before typechecking -------------------------------------+------------------------------------- Reporter: varosi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Compile- | Difficulty: Unknown time crash | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Can I ask once more that you give the ''precise steps'' required to produce the crash? Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 11 22:08:23 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Dec 2014 22:08:23 -0000 Subject: [GHC] #9389: Full Test Suite Failures In-Reply-To: <042.38f06884e0da53a793f9dd734d87a005@haskell.org> References: <042.38f06884e0da53a793f9dd734d87a005@haskell.org> Message-ID: <057.762f2910c4431a99ae40e03554d279d6@haskell.org> #9389: Full Test Suite Failures -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | #9286,#8756,#7876,#7877 -------------------------------------+------------------------------------- Comment (by jrp): Today, quick build gives (sorry, no github repo yet): {{{ OVERALL SUMMARY for test run started at Thu Dec 11 20:47:57 2014 GMT 0:41:48 spent to go through 4359 total tests, which gave rise to 14160 test cases, of which 2699 were skipped 275 had missing libraries 10958 expected passes 145 expected failures 3 caused framework failures 0 unexpected passes 62 unexpected failures 18 unexpected stat failures Unexpected failures: ../../libraries/base/tests enum01 [exit code non-0] (normal,hpc,optasm,threaded1,threaded2,dyn) ../../libraries/base/tests enum01 [bad stdout or stderr] (ghci) ../../libraries/base/tests enum02 [exit code non-0] (normal,hpc,optasm,threaded1,threaded2,dyn) ../../libraries/base/tests enum02 [bad stdout or stderr] (ghci) ../../libraries/base/tests enum03 [exit code non-0] (normal,hpc,optasm,threaded1,threaded2,dyn) ../../libraries/base/tests enum03 [bad stdout or stderr] (ghci) ../../libraries/base/tests topHandler01 [bad exit code] (threaded1) ../../libraries/base/tests topHandler01 [bad stdout or stderr] (ghci) ../../libraries/process/tests process011 [bad exit code] (threaded1,threaded2) ../../libraries/process/tests process011 [bad stdout or stderr] (ghci) ../../libraries/unix/tests forkprocess01 [bad exit code] (ghci) ../../libraries/unix/tests signals002 [bad stdout] (threaded1,threaded2) ../../libraries/unix/tests signals002 [bad stdout or stderr] (ghci) cabal/cabal01 cabal01 [bad exit code] (normal) cabal/sigcabal01 sigcabal01 [bad stderr] (normal) codeGen/should_run CgStaticPointers [bad stdout or stderr] (ghci) concurrent/should_run allocLimit4 [bad exit code] (ghci) concurrent/should_run conc012 [bad exit code] (ghci) concurrent/should_run conc059 [bad stderr] (threaded1,threaded2) deSugar/should_run DsStaticPointers [bad stdout or stderr] (ghci) deSugar/should_run dsrun014 [bad exit code] (ghci) ffi/should_run T2276_ghci [bad stdout or stderr] (ghci) ghci.debugger/scripts print021 [bad exit code] (ghci) ghci/prog003 prog003 [bad stderr] (ghci) ghci/scripts T8696 [bad stderr] (ghci) ghci/scripts ghci024 [bad stdout] (normal) ghci/scripts ghci058 [bad stderr] (ghci) numeric/should_run add2 [bad exit code] (ghci) numeric/should_run mul2 [bad exit code] (ghci) numeric/should_run quotRem2 [bad exit code] (ghci) parser/should_run readRun004 [bad exit code] (ghci) rts GcStaticPointers [bad stdout or stderr] (ghci) rts ListStaticPointers [bad stdout or stderr] (ghci) rts T7919 [bad exit code] (optasm,threaded2,dyn) th TH_StaticPointers [bad stdout or stderr] (ghci) typecheck/should_run T7861 [bad exit code] (normal,hpc,optasm,ghci,threaded1,threaded2,dyn) }}} An unadorned {{{validate}}} gives: {{{ OVERALL SUMMARY for test run started at Thu Dec 11 22:03:04 2014 GMT 0:05:02 spent to go through 4359 total tests, which gave rise to 14156 test cases, of which 10141 were skipped 53 had missing libraries 3884 expected passes 70 expected failures 0 caused framework failures 0 unexpected passes 6 unexpected failures 2 unexpected stat failures Unexpected failures: cabal/cabal01 cabal01 [bad exit code] (normal) cabal/sigcabal01 sigcabal01 [bad stderr] (normal) ffi/should_run T2276_ghci [bad stdout or stderr] (ghci) ghci/prog003 prog003 [bad stderr] (ghci) ghci/scripts T8696 [bad stderr] (ghci) ghci/scripts ghci058 [bad stderr] (ghci) Unexpected stat failures: perf/compiler T4801 [stat too good] (normal) perf/haddock haddock.base [stat not good enough] (normal) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 11 22:28:23 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Dec 2014 22:28:23 -0000 Subject: [GHC] #8279: bad alignment in code gen yields substantial perf issue In-Reply-To: <045.3fa2c6fed8a76bf664b09b6a4e78beae@haskell.org> References: <045.3fa2c6fed8a76bf664b09b6a4e78beae@haskell.org> Message-ID: <060.c4f4fa01019905e69764e75545b9f5c7@haskell.org> #8279: bad alignment in code gen yields substantial perf issue -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: #8082 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by archblob): * cc: archblob (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 12 01:27:17 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Dec 2014 01:27:17 -0000 Subject: [GHC] #9872: Runing type functions is too slow In-Reply-To: <046.39f8cd7bfe0ce27cb6afb75f2059ad40@haskell.org> References: <046.39f8cd7bfe0ce27cb6afb75f2059ad40@haskell.org> Message-ID: <061.d5deb68b55b5f65dca41544407a25a07@haskell.org> #9872: Runing type functions is too slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by cactus): Just to put some numbers on the improvement processing time-wise, here's an unscientific test run of all three tests, using GHC 7.8.3 and GHC a225c70e00586e2f38a0e27fae698324ae81b006 built in `perf` mode (rounded to tenth of seconds because the whole thing is unscientific anyway, just a single run of `ghc --make` on the three source files) || ||= GHC 7.8.3 =||= GHC a225c70 =|| ||= T9872a =|| 45.5s|| 7s|| ||= T9872b =|| 35.7s|| 6.5s|| ||= T9872c =|| 45.3s|| 7.5s|| -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 12 14:14:31 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Dec 2014 14:14:31 -0000 Subject: [GHC] #9123: Need for higher kinded roles In-Reply-To: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> References: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> Message-ID: <061.fe841a0d02632f4f6ca6b49fbddd1a3a@haskell.org> #9123: Need for higher kinded roles -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Project (more Type of failure: | than a week) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): I've recently realized that an alternate, much more tantalizing fix to this problem is to allow quantifying over implication constraints (#2256). To be concrete, consider {{{#!hs class Monad m where join :: m (m a) -> m a data StateT s m a = StateT (s -> m (a, s)) -- could be a newtype, but that doesn't change my argument type role StateT nominal representational nominal -- as inferred instance Monad m => Monad (StateT s m) where ... newtype IntStateT m a = IntStateT (StateT Int m a) deriving Monad }}} This induces the following instance: {{{ instance (...) => Monad (IntStateT m) where join = coerce (join :: StateT Int m (StateT Int m a) -> StateT Int m a) :: forall a. IntStateT m (IntStateT m a) -> IntStateT m a }}} GHC needs to infer the `(...)`. It starts with `Monad m` along with {{{ Coercible (StateT Int m (StateT Int m a) -> StateT Int m a) (IntStateT m (IntStateT m a) -> IntStateT m a) }}} This gets reduced to {{{ Coercible (StateT Int m (StateT Int m a)) (StateT Int m (IntStateT m a)) }}} and is then stuck, unable to unwrap the newtype in a nominal context. The problem, at this point is that `a` is out of scope in the instance context `(...)`, and so GHC gives up. If we had implication constraints, we could just quantify! The instance context would be complex, but everything would work out in practice. As a separate case, imagine I had declared `StateT` as a newtype (so that we can look through to its definition) and we wanted to prove, say, `Coercible (StateT Int) (StateT Age)`. Right now, we're stuck, but, I conjecture that the following would work: {{{ data Coercion a b where Coercion :: Coercible a b => Coercion a b pf :: forall m c. (forall a b. Coercible a b => Coercible (m a) (m b)) => Coercion (StateT Int m c) (StateT Age m c) pf = Coercion }}} (The `c` parameter is necessary to allow GHC to unwrap the newtype, as it won't unwrap a partially-applied newtype.) To prove, GHC unwraps the newtypes to get {{{ [W] Coercible (Int -> m (c, Int)) (Age -> m (c, Age)) }}} and then {{{ [W] Coercible (m (c, Int)) (m (c, Age)) }}} GHC will then look for an appropriate instance, finding {{{ [G] forall a b. Coercible a b => Coercible (m a) (m b) }}} which matches nicely. (This last step is beyond the current algorithm for the treatment of givens, but it's exactly what the instance-lookup algorithm does! So we just adapt that to a new scenario.) Thus, we now have {{{ [W] Coercible (c, Int) (c, Age) }}} which is solved handily. More comments on the solving algorithm on #2256, shortly. I think this solution, of using implication constraints, is '''much''' better than the ad-hoc idea in [wiki:Roles2]. It's more powerful, simpler to explain, simpler to implement, and it goes "all the way". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 12 15:19:27 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Dec 2014 15:19:27 -0000 Subject: [GHC] #2256: Incompleteness of type inference: must quantify over implication constraints In-Reply-To: <046.2c6c7c4440a32ff5fbe5ad1f48bf6276@haskell.org> References: <046.2c6c7c4440a32ff5fbe5ad1f48bf6276@haskell.org> Message-ID: <061.00d730d3621e6c34c4a1b6c5cd7aeddb@haskell.org> #2256: Incompleteness of type inference: must quantify over implication constraints -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: lowest | Milestone: 7.10.1 Component: Compiler | Version: 6.8.2 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): I initially put this ticket into my internal notes as "Difficulty: Rocket Science", but I've changed my mind. I think this is actually straightforward to implement. GHC already has implication constraints, except that they're effectively all Wanteds. So, all we would need are to be able to make Given implication constraints. But, these should be rather straightforward, because we can view top-level instances as Given implication constraints. We can just adapt the current look-in-Givens algorithm to do some matching, just like the instance-selection algorithm does. When we find an implication-constraint Given that matches a Wanted, we use it to solve the Wanted and then emit new Wanteds for the antecedents of the Given implication. I was initially concerned about overlap here -- what if an implication Given's RHS overlaps with a global instance? -- but this was a red herring. Givens have always potentially overlapped with global instances, and very few people are bothered. For example: {{{ min :: Ord a => a -> a -> a }}} If we call `min` at type `Int`, the `Ord` constraint is potentially ambiguous: do we mean the dictionary supplied or the global `Ord Int` dictionary? Of course, we mean the local one, and we don't require `-XIncoherentInstances` to do so. So, worrying about overlap in the context of implication Givens is a red herring. We have a clear rule: local constraints always shadow global ones. That's nice, simple, and unsurprising. This also doesn't change the "GHC never backtracks" principle. If a local implication-constraint's RHS matches, it is used, just like if GHC finds a global implication constraint (read, global constrained instance). To implement this, GHC would also need to be able to produce the witness for an implication constraint, but this is just like inferring the lambdas for a higher-rank type. I don't see any challenge here. Of course, a niggling feeling tells me that this ''has'' to be harder than I'm seeing it. But, really, all I see standing in the way is a bit of plumbing. Thoughts? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 12 15:40:05 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Dec 2014 15:40:05 -0000 Subject: [GHC] #9880: ghc crashes on th splices in instance context Message-ID: <048.f4daf5bbce32dd24217721fc99cc931b@haskell.org> #9880: ghc crashes on th splices in instance context -------------------------------------+------------------------------------- Reporter: Philonous | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Given Class.hs: {{{#!hs module Class where class Foo a where bar :: a -> Int }}} TH.hs {{{#!hs {-# LANGUAGE TemplateHaskell #-} module TH where import Class import Language.Haskell.TH mkFun :: Q [Dec] mkFun = return [FunD 'bar [Clause [WildP] (NormalB (LitE (IntegerL 0))) []]] }}} and Instance.hs {{{#!hs {-# LANGUAGE TemplateHaskell #-} module Instance where import TH import Class instance Foo Bool where $(mkFun) }}} compiling the project crashes ghc with {{{ #ghc --make Instance.hs [2 of 3] Compiling TH ( TH.hs, TH.o ) [3 of 3] Compiling Instance ( Instance.hs, Instance.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-unknown-linux): cvBindsAndSigs $[splice{v}]mkFun{v} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 12 18:45:29 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Dec 2014 18:45:29 -0000 Subject: [GHC] #9879: Panic with partial type signatures In-Reply-To: <047.e5c88bd3f1ae8bc6f7d19321ba46479c@haskell.org> References: <047.e5c88bd3f1ae8bc6f7d19321ba46479c@haskell.org> Message-ID: <062.db894924115601019b9a146920e6a1c0@haskell.org> #9879: Panic with partial type signatures -------------------------------------+------------------------------------- Reporter: monoidal | Owner: thomasw Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHCi crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomasw): * owner: => thomasw -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 12 18:46:13 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Dec 2014 18:46:13 -0000 Subject: [GHC] #9879: Panic with partial type signatures In-Reply-To: <047.e5c88bd3f1ae8bc6f7d19321ba46479c@haskell.org> References: <047.e5c88bd3f1ae8bc6f7d19321ba46479c@haskell.org> Message-ID: <062.baea2b891fd462eb20582e22f81c63ee@haskell.org> #9879: Panic with partial type signatures -------------------------------------+------------------------------------- Reporter: monoidal | Owner: thomasw Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHCi crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomasw): I'll look into this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 12 20:25:59 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Dec 2014 20:25:59 -0000 Subject: [GHC] #9881: GHCi gives misleading error message when looking up info of ambiguous type Message-ID: <050.4dea55782a9eac6405927023d9d109f3@haskell.org> #9881: GHCi gives misleading error message when looking up info of ambiguous type -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Other Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- When GHCi imports multiple functions with the same name, using {{{:i}}} results in an ambiguous occurrence error: {{{ > import Data.Text > import Data.Text.Lazy > :i length Top level: Ambiguous occurrence ?length? It could refer to either ?Data.Text.Lazy.length?, imported from ?Data.Text.Lazy? or ?Prelude.length?, imported from ?Prelude? (and originally defined in ?GHC.List?) or ?Data.Text.length?, imported from ?Data.Text? }}} However, if you use {{{:i}}} on a type name that has imported multiple times in GHCi, a misleading error is given: {{{ > import Data.Text > import Data.Text.Lazy > :i Text Top level: Not in scope: data constructor ?Text? }}} The real problem is that the type name {{{Text}}} was imported twice with two different definitions, so the error should probably look something like this: {{{ Top level: Ambiguous occurrence ?Text? It could refer to either ?Data.Text.Lazy.Text?, imported from ?Data.Text.Lazy? (and originally defined in ?Data.Text.Internal.Lazy?) or ?Data.Text.Text?, imported from ?Data.Text? (and originally defined in ?Data.Text.Internal?) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 12 22:56:09 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Dec 2014 22:56:09 -0000 Subject: [GHC] #8984: Improve output of failed GeneralizedNewtypeDeriving coercion due to type roles In-Reply-To: <044.9146c0f21c1d5c0ac4fad078a63640bb@haskell.org> References: <044.9146c0f21c1d5c0ac4fad078a63640bb@haskell.org> Message-ID: <059.fde8aaf4676270dcbf695267e28b84a7@haskell.org> #8984: Improve output of failed GeneralizedNewtypeDeriving coercion due to type roles -------------------------------------+------------------------------------- Reporter: haasn | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.1 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"0cc47eb90805f3e166ac4d3991e66d3346ca05e7/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="0cc47eb90805f3e166ac4d3991e66d3346ca05e7" Rewrite `Coercible` solver Summary: This is a rewrite of the algorithm to solve for Coercible "instances". A preliminary form of these ideas is at https://ghc.haskell.org/trac/ghc/wiki/Design/NewCoercibleSolver The basic idea here is that the `EqPred` constructor of `PredTree` now is parameterised by a new type `EqRel` (where `data EqRel = NomEq | ReprEq`). Thus, every equality constraint can now talk about nominal equality (the usual case) or representational equality (the `Coercible` case). This is a change from the previous behavior where `Coercible` was just considered a regular class with a special case in `matchClassInst`. Because of this change, representational equalities are now canonicalized just like nominal ones, allowing more equalities to be solved -- in particular, the case at the top of #9117. A knock-on effect is that the flattener must be aware of the choice of equality relation, because the inert set now stores both representational inert equalities alongside the nominal inert equalities. Of course, we can use representational equalities to rewrite only within another representational equality -- thus the parameterization of the flattener. A nice side effect of this change is that I've introduced a new type `CtFlavour`, which tracks G vs. W vs. D, removing some ugliness in the flattener. This commit includes some refactoring as discussed on D546. It also removes the ability of Deriveds to rewrite Deriveds. This fixes bugs #9117 and #8984. Reviewers: simonpj, austin, nomeata Subscribers: carter, thomie Differential Revision: https://phabricator.haskell.org/D546 GHC Trac Issues: #9117, #8984 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 12 22:56:09 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Dec 2014 22:56:09 -0000 Subject: [GHC] #9117: Coercible constraint solver misses one In-Reply-To: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> References: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> Message-ID: <062.9526dcea6d9ffe01ac36bd41aca1ad55@haskell.org> #9117: Coercible constraint solver misses one -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D546 | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"0cc47eb90805f3e166ac4d3991e66d3346ca05e7/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="0cc47eb90805f3e166ac4d3991e66d3346ca05e7" Rewrite `Coercible` solver Summary: This is a rewrite of the algorithm to solve for Coercible "instances". A preliminary form of these ideas is at https://ghc.haskell.org/trac/ghc/wiki/Design/NewCoercibleSolver The basic idea here is that the `EqPred` constructor of `PredTree` now is parameterised by a new type `EqRel` (where `data EqRel = NomEq | ReprEq`). Thus, every equality constraint can now talk about nominal equality (the usual case) or representational equality (the `Coercible` case). This is a change from the previous behavior where `Coercible` was just considered a regular class with a special case in `matchClassInst`. Because of this change, representational equalities are now canonicalized just like nominal ones, allowing more equalities to be solved -- in particular, the case at the top of #9117. A knock-on effect is that the flattener must be aware of the choice of equality relation, because the inert set now stores both representational inert equalities alongside the nominal inert equalities. Of course, we can use representational equalities to rewrite only within another representational equality -- thus the parameterization of the flattener. A nice side effect of this change is that I've introduced a new type `CtFlavour`, which tracks G vs. W vs. D, removing some ugliness in the flattener. This commit includes some refactoring as discussed on D546. It also removes the ability of Deriveds to rewrite Deriveds. This fixes bugs #9117 and #8984. Reviewers: simonpj, austin, nomeata Subscribers: carter, thomie Differential Revision: https://phabricator.haskell.org/D546 GHC Trac Issues: #9117, #8984 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 12 22:56:12 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Dec 2014 22:56:12 -0000 Subject: [GHC] #8024: Dynamic linking not working on PowerPC Linux. In-Reply-To: <044.9ac099edab3e89a81000a0e47392a6e5@haskell.org> References: <044.9ac099edab3e89a81000a0e47392a6e5@haskell.org> Message-ID: <059.f9797c59638e8ad2070604aabd4e26cd@haskell.org> #8024: Dynamic linking not working on PowerPC Linux. ----------------------------------------------+--------------------------- Reporter: erikd | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: D560 | ----------------------------------------------+--------------------------- Changes (by slyfox): * status: infoneeded => patch * differential: => D560 Comment: The problem happened to be in code emitting prologs for basic block entries (also got fixed by https://phabricator.haskell.org/D560). Typically haskell function has single entry point (-fPIC -ddump-asm- native): {{{ M.f_info: _ci4: ; PIC prolog bcl 20,31,1f 1: mflr %vI_nic lwz %vI_nij, _nii-(1b)(%vI_nic) add %vI_nic, %vI_nic, %vI_nij ... ... ; offset to LCTOC from nearest '1:' .text .align 2 _nii: .long .LCTOC1-(1b)+0 }}} But sometimes runtime needs to return back into a middle of haskell function (try/catch primitives?) and prolog gets emitted at each such point using the same LCTOC offset: {{{ M.f_info: _ci4: ; PIC prolog bcl 20,31,1f 1: mflr %vI_nic ; REF 1 lwz %vI_nij, _nii-(1b)(%vI_nic) add %vI_nic, %vI_nic, %vI_nij ... ... returns_here_later: ; PIC prolog bcl 20,31,1f 1: mflr %vI_nic ; REF 2 lwz %vI_nij, _nii-(1b)(%vI_nic) add %vI_nic, %vI_nic, %vI_nij ... ; offset to LCTOC from nearest '1:' .text .align 2 _nii: .long .LCTOC1-(1b)+0 }}} Here '_nii' contains offset to nearest '1:' label, not first one (as intended). It leads to miscomputation of LCTOC1 in function entry (around first '1:' which usually manifests in call to random location. It is fixed by using simpler prolog (similar to what modern gcc emits nowadays): {{{ bcl 20,31,1f 1: mflr %vI_ny4 addis %vI_ny4, %vI_ny4, .LCTOC1-(1b)@ha addi %vI_ny4, %vI_ny4, .LCTOC1-(1b)@l mr 30, %vI_ny4 }}} And it is safe to duplicate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 12 22:57:57 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Dec 2014 22:57:57 -0000 Subject: [GHC] #9117: Coercible constraint solver misses one In-Reply-To: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> References: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> Message-ID: <062.ad7cd2358fedc2d10e3063ab3c7714cc@haskell.org> #9117: Coercible constraint solver misses one -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | typecheck/should_compile/T9117{,_2,_3}| Blocking: | Differential Revisions: Phab:D546 | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * testcase: => typecheck/should_compile/T9117{,_2,_3} * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 12 23:03:38 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Dec 2014 23:03:38 -0000 Subject: [GHC] #8984: Improve output of failed GeneralizedNewtypeDeriving coercion due to type roles In-Reply-To: <044.9146c0f21c1d5c0ac4fad078a63640bb@haskell.org> References: <044.9146c0f21c1d5c0ac4fad078a63640bb@haskell.org> Message-ID: <059.dfb3fbeba444e42200bac968186dc014@haskell.org> #8984: Improve output of failed GeneralizedNewtypeDeriving coercion due to type roles -------------------------------------+------------------------------------- Reporter: haasn | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.1 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): The patch above does not implement the proposal in comment:6 and agreed to in comment:7. I'll implement this proposal soon, but it will likely miss the 7.10 branch. This is OK -- it won't hurt anyone to have this unfixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 12 23:04:29 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Dec 2014 23:04:29 -0000 Subject: [GHC] #8984: Improve output of failed GeneralizedNewtypeDeriving coercion due to type roles In-Reply-To: <044.9146c0f21c1d5c0ac4fad078a63640bb@haskell.org> References: <044.9146c0f21c1d5c0ac4fad078a63640bb@haskell.org> Message-ID: <059.ad9f34bc7949362024c250218fada938@haskell.org> #8984: Improve output of failed GeneralizedNewtypeDeriving coercion due to type roles -------------------------------------+------------------------------------- Reporter: haasn | Owner: goldfire Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.1 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | deriving/should_fail/T8984 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by goldfire): * owner: => goldfire * testcase: => deriving/should_fail/T8984 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 13 08:00:58 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Dec 2014 08:00:58 -0000 Subject: [GHC] #9845: GHC API evaluating some Cabal code fails with SegFault if executable is compiled statically In-Reply-To: <059.4340a519aad7bd56a35fa652e2b81e6f@haskell.org> References: <059.4340a519aad7bd56a35fa652e2b81e6f@haskell.org> Message-ID: <074.a7d2588adc29e99608d5944f70be13ff@haskell.org> #9845: GHC API evaluating some Cabal code fails with SegFault if executable is compiled statically -------------------------------------+------------------------------------- Reporter: | Owner: JeanPhilippeMoresmau | Status: new Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.8.3 Component: GHC API | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: 9875 Type of failure: Runtime | Related Tickets: #9480, #8935, crash | #8376 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by trommler): * status: merge => new * blockedby: => 9875 * milestone: 7.8.4 => 7.10.1 Comment: The fix for #8935 in HEAD introduces a regression on OS X. See ticket #9875. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 13 10:21:17 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Dec 2014 10:21:17 -0000 Subject: [GHC] #9882: Kind mismatch with singleton [Nat] Message-ID: <052.5a45a6dd72a21fd100bb8463ecce1207@haskell.org> #9882: Kind mismatch with singleton [Nat] -------------------------------------+------------------------------------- Reporter: Roel van Dijk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: GHC Difficulty: Unknown | rejects valid program Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE TypeOperators #-} import GHC.TypeLits ( Nat ) data Foo (n :: [Nat]) = Foo x :: Foo ('(:) 42 '[]) x = Foo y :: Foo (42 ': '[]) y = Foo z :: Foo [42] z = Foo }}} {{{ Expected kind ?*?, but ?42? has kind ?Nat? In the type signature for ?z?: z :: Foo [42] }}} I would expected z to be identical to both x and y. The error occurs in both GHCi and GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 13 10:27:36 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Dec 2014 10:27:36 -0000 Subject: [GHC] #9882: Kind mismatch with singleton [Nat] In-Reply-To: <052.5a45a6dd72a21fd100bb8463ecce1207@haskell.org> References: <052.5a45a6dd72a21fd100bb8463ecce1207@haskell.org> Message-ID: <067.2e67d3e5e9597302057b30783febdfe2@haskell.org> #9882: Kind mismatch with singleton [Nat] -------------------------------------+------------------------------------- Reporter: Roel van | Owner: Dijk | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Description changed by Roel van Dijk: Old description: > {{{#!hs > {-# LANGUAGE DataKinds #-} > {-# LANGUAGE KindSignatures #-} > {-# LANGUAGE TypeOperators #-} > > import GHC.TypeLits ( Nat ) > > data Foo (n :: [Nat]) = Foo > > x :: Foo ('(:) 42 '[]) > x = Foo > > y :: Foo (42 ': '[]) > y = Foo > > z :: Foo [42] > z = Foo > }}} > > {{{ > Expected kind ?*?, but ?42? has kind ?Nat? > In the type signature for ?z?: z :: Foo [42] > }}} > > I would expected z to be identical to both x and y. The error occurs in > both GHCi and GHC. New description: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE TypeOperators #-} import GHC.TypeLits ( Nat ) data Foo (n :: [Nat]) = Foo x :: Foo ('(:) 42 '[]) x = Foo y :: Foo (42 ': '[]) y = Foo z :: Foo [42] z = Foo }}} {{{ Expected kind ?*?, but ?42? has kind ?Nat? In the type signature for ?z?: z :: Foo [42] }}} I would expected z to be identical to both x and y. The error occurs in both GHCi and GHC. Some more tests: {{{#!hs a_works = Foo '[] a_fails = Foo [] z_works = Foo '[42] }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 13 10:32:11 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Dec 2014 10:32:11 -0000 Subject: [GHC] #9882: Kind mismatch with singleton [Nat] In-Reply-To: <052.5a45a6dd72a21fd100bb8463ecce1207@haskell.org> References: <052.5a45a6dd72a21fd100bb8463ecce1207@haskell.org> Message-ID: <067.eccddd3a1f9d24bbc079828ee60774db@haskell.org> #9882: Kind mismatch with singleton [Nat] -------------------------------------+------------------------------------- Reporter: Roel van | Owner: Dijk | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Roel van Dijk): I am now thinking this might not be a bug. The parser doesn't know that the `[42]` is of kind `[Nat]` so it parses it as `[] 42`, which has kind `*`. I was confused because `[1, 2, 3]` was accepted as a type of kind `[Nat]`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 13 10:32:40 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Dec 2014 10:32:40 -0000 Subject: [GHC] #9882: Kind mismatch with singleton [Nat] In-Reply-To: <052.5a45a6dd72a21fd100bb8463ecce1207@haskell.org> References: <052.5a45a6dd72a21fd100bb8463ecce1207@haskell.org> Message-ID: <067.f1428a0869929d3bbe2cef8488ab35f8@haskell.org> #9882: Kind mismatch with singleton [Nat] -------------------------------------+------------------------------------- Reporter: Roel van | Owner: Dijk | Status: closed Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: invalid | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by Roel van Dijk): * status: new => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 13 13:50:25 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Dec 2014 13:50:25 -0000 Subject: [GHC] #9883: Make OverloadedLists more usable by splitting the class interface Message-ID: <046.2f0f8d78805e972b7bee3e325045a73c@haskell.org> #9883: Make OverloadedLists more usable by splitting the class interface -------------------------------------+------------------------------------- Reporter: muesli4 | Owner: Type: feature request | Status: new Priority: normal | Milestone: ? Component: External Core | Version: 7.8.3 Keywords: overloaded lists, | Operating System: islist | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Moderate (less | None/Unknown than a day) | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- == Problem == While the OverloadedLists extension is very useful, it limits the types which can be used with it, by requesting too much. Assume you have a database specific DSEL which allows you to use list-like expressions in queries, it's easy to implement {{{fromList}}}, but we are unable to implement {{{toList}}} in a reasonable fashion without a backend and an existing connection. == Proposal == Modify the class interface in a way that does not require the instance to be ''listable''. {{{ class IsList l where type Item l fromList :: [Item l] -> l fromListN :: Int -> [Item l] -> l }}} We could then provide the pattern matching functionality on {{{IsList}}} instances with different approaches. === Another class === Just add another class which is used to provide the {{{toList}}} function, used on pattern matches. This is the easiest approach {{{ class AsList l where type Item l toList :: l -> [Item l] }}} Desugaring works as usual and it goes well with all structures. (The name is not the best though.) === Using Data.Foldable === The list pattern gets desugared using Data.Foldable: {{{ f :: (IsList l, Foldable l) => l -> l f [x, y, z] = [x, y] f l = l }}} gets something like: {{{ import Data.Foldable (toList) f :: (IsList l, Foldable l) => l -> l f (toList -> [x, y, z]) = fromList [x, y] f l = l }}} This approach does not go well with structures like {{{Data.Map}}}, because it expects the type constructor to take the ''element type'' as first argument, but we would like to have a tuple type. Maybe a wrapper could be provided, but I think it's not the way to go, as long as Data.Foldable does not use type families. == Drawbacks == Both approaches complicate the type of list expressions. This requires a bit more of typing, but it specifies exactly which functionality you need and one can simply drop the unused one, without creating dangerous dummy implementations: - {{{IsList}}} for overloaded list expressions - {{{AsList}}} or {{{Foldable}}} for pattern matching Most of the time OverloadedLists is used for convenience, so I don't expect the normal user to be really affected, library writers, specifically those who write some kind of DSEL, will have to be more precise, but get a more type-safe approach, which can not fail at runtime. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 13 20:09:19 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Dec 2014 20:09:19 -0000 Subject: [GHC] #9883: Make OverloadedLists more usable by splitting the class interface In-Reply-To: <046.2f0f8d78805e972b7bee3e325045a73c@haskell.org> References: <046.2f0f8d78805e972b7bee3e325045a73c@haskell.org> Message-ID: <061.9cf09fbc3814188cac03991612a0d3c6@haskell.org> #9883: Make OverloadedLists more usable by splitting the class interface -------------------------------------+------------------------------------- Reporter: muesli4 | Owner: Type: feature | Status: closed request | Milestone: ? Priority: normal | Version: 7.8.3 Component: External | Keywords: overloaded lists, Core | islist Resolution: duplicate | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: | Blocked By: None/Unknown | Related Tickets: #7495 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by carter): * status: new => closed * resolution: => duplicate * related: => #7495 Comment: interesting ideas! Its a dupe (at least in part) of https://ghc.haskell.org/trac/ghc/ticket/7495, so i'm closing it as a dupe of that, and adding a related ticket link ther -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 13 20:09:52 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Dec 2014 20:09:52 -0000 Subject: [GHC] #7495: generalizing overloaded list syntax to Sized Lists, HLists, HRecords, etc In-Reply-To: <042.94f63ae1f0ea5e1c87f7145cb04cda4b@haskell.org> References: <042.94f63ae1f0ea5e1c87f7145cb04cda4b@haskell.org> Message-ID: <057.d7c2b77c155d808eef0f4f9b1e57675c@haskell.org> #7495: generalizing overloaded list syntax to Sized Lists, HLists, HRecords, etc -------------------------------------+------------------------------------- Reporter: nwf | Owner: carter Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.6.1 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #9883 None/Unknown | Test Case: | Blocking: 9883 | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by carter): * blocking: => 9883 * related: => #9883 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 13 22:15:53 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Dec 2014 22:15:53 -0000 Subject: [GHC] #9884: Compling on arm and getting "No native code generator, so using LLVM" Message-ID: <044.853aba5514cba3c961da3d9712d139ef@haskell.org> #9884: Compling on arm and getting "No native code generator, so using LLVM" -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: low | Milestone: Component: Build System | Version: 7.9 Keywords: | Operating System: Architecture: arm | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: Incorrect hour) | warning at compile-time Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Compiling GHC on Arm and I get a constant stream of warnings like: {{{ when making flags consistent: Warning: No native code generator, so using LLVM }}} This can be fixed with a simple patch to `mk/build.mk.sample`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 14 05:02:43 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Dec 2014 05:02:43 -0000 Subject: [GHC] #9867: PatternSynonyms + ScopedTypeVariables triggers an internal error In-Reply-To: <046.5cdd1cb9d606767d1869bca60906658f@haskell.org> References: <046.5cdd1cb9d606767d1869bca60906658f@haskell.org> Message-ID: <061.e618848d89b164f67de3ddd0fdc06c8f@haskell.org> #9867: PatternSynonyms + ScopedTypeVariables triggers an internal error -------------------------------------+------------------------------------- Reporter: antalsz | Owner: cactus Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by cactus): Hrm. So what's happening here is that when we see {{{ pattern Nil = [] :: [a] }}} we rename and typecheck `[] :: [a]` as a pattern (like in a function definition); this by itself requires `ScopedTypeVariables` (in `rnHsBndrSig` I believe), as you can see by trying the following: {{{ {-# LANGUAGE PatternSynonyms #-} pattern Nil = [] :: [a] }}} {{{ T9867a.hs:2:21: Illegal type signature: ?[a]? Perhaps you intended to use ScopedTypeVariables In a pattern type-signature }}} If you do turn on `ScopedTypeVariables`, renaming succeeds and puts an unbound type variable in the type signature: {{{ pattern main at main:Main.Nil{d rvh} = ghc-prim-0.3.1.0:GHC.Types.[]{(w) d 6m} :: [a{tv awt}] }}} Then `tcInferPatSynDecl` typechecks this right-hand side, via some indirections: {{{ T9867.hs:2:15: env2 [(a{tv awt}, Type variable ?a{tv awt}? = a{tv aww}[sig:2])] T9867.hs:2:9: Skolemising a{tv aww}[sig:2] := a{tv awx}[sk] T9867.hs:2:9: writeMetaTyVar a{tv aww}[sig:2] := a{tv awx}[sk] }}} but by the time we get to `tc_patsyn_finish`, both `a{tv aww}` and `a{tv awx}` show up, as two separate types: the pattern type is `[a{tv awx}]`, but the pattern definition is `[] :: [a{tv aww}]`, so we end up generating the following code for the matcher: {{{ main at main:Main.$mNil{v rws}[gid] :: forall (r{tv awy}[sk] :: ghc-prim-0.3.1.0:GHC.Prim.OpenKind{(w) tc 34g}) a{tv awx}[sk]. [a{tv awx}[sk]] -> (ghc-prim-0.3.1.0:GHC.Prim.Void#{(w) tc 32L} -> r{tv awy}[sk]) -> (ghc-prim-0.3.1.0:GHC.Prim.Void#{(w) tc 32L} -> r{tv awy}[sk]) -> r{tv awy}[sk] [GblId, Str=DmdType] main at main:Main.$mNil{v rws} = /\(@ (r{tv awy}[sk] :: ghc-prim-0.3.1.0:GHC.Prim.OpenKind{(w) tc 34g})). /\(@ a{tv awx}[sk]). \ ((scrut_awA{v}[lid] :: [a{tv awx}[sk]])) ((cont_awB{v}[lid] :: Void#{(w) tc 32L} -> r{tv awy}[sk])) ((fail_awC{v}[lid] :: Void#{(w) tc 32L} -> r{tv awy}[sk])) -> case scrut_awA{v} of { ghc-prim-0.3.1.0:GHC.Types.[]{(w) d 6m}{EvBinds{}} :: [a{tv aww}[sig:2]] -> cont_awB{v} ghc-prim-0.3.1.0:GHC.Prim.void#{(w) v 0l} _ -> fail_awC{v} ghc-prim-0.3.1.0:GHC.Prim.void#{(w) v 0l} } }}} (note how we still have `[a{tv aww}]` in the type annotation of the case branch). This is where the error message is coming from. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 14 05:26:53 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Dec 2014 05:26:53 -0000 Subject: [GHC] #9867: PatternSynonyms + ScopedTypeVariables triggers an internal error In-Reply-To: <046.5cdd1cb9d606767d1869bca60906658f@haskell.org> References: <046.5cdd1cb9d606767d1869bca60906658f@haskell.org> Message-ID: <061.7feaffdec4ac98098ada73d5414a3d56@haskell.org> #9867: PatternSynonyms + ScopedTypeVariables triggers an internal error -------------------------------------+------------------------------------- Reporter: antalsz | Owner: cactus Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by cactus): I think we need to zonk the typechecked pattern before passing it to `tc_patsyn_finish`, so that the signature in it can be replaced with `[a{tv awx}]`. `TcHsSyn` doesn't currently export `zonkPat` but hopefully it will be enough to pass it an empty `ZonkEnv`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 14 05:44:50 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Dec 2014 05:44:50 -0000 Subject: [GHC] #9819: Create typesafe method of obtaining dictionary types from class definitions, and constraint objects from dictionary types In-Reply-To: <050.b04515eaa5272881d87195907090dfe3@haskell.org> References: <050.b04515eaa5272881d87195907090dfe3@haskell.org> Message-ID: <065.a9ba8a5a7ce0907142f5741f9c793f02@haskell.org> #9819: Create typesafe method of obtaining dictionary types from class definitions, and constraint objects from dictionary types -------------------------------------+------------------------------------- Reporter: | Owner: spacekitteh | Status: new Type: feature | Milestone: request | Version: Priority: normal | Keywords: Component: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less Operating System: | than a day) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by spacekitteh): Right. I'm not requesting local instances as a whole; rather, just access to the desugared typeclass dictionary types. Basically, adding a Dictionary kind, and a type function from Constraint kinds to Dictionary kinds (local instances could involve adding a type function in the reverse direction). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 14 07:03:48 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Dec 2014 07:03:48 -0000 Subject: [GHC] #9372: dll-split during stage 2 compiling ghc v7.8.3 for arm_linux In-Reply-To: <047.8ff8936a8082bdb3e0c2617996031a2e@haskell.org> References: <047.8ff8936a8082bdb3e0c2617996031a2e@haskell.org> Message-ID: <062.2f7fe4744a1ee196a3f27291fbf12fe1@haskell.org> #9372: dll-split during stage 2 compiling ghc v7.8.3 for arm_linux ----------------------------------------------+--------------------------- Reporter: chrisfgl | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8976 Differential Revisions: | ----------------------------------------------+--------------------------- Changes (by erikd): * cc: erikd (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 14 07:05:54 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Dec 2014 07:05:54 -0000 Subject: [GHC] #8976: dll-split: internal error: evacuate(static): strange closure type 0 In-Reply-To: <050.3f03921ecbab8dbcaa2aa5e8c2d08707@haskell.org> References: <050.3f03921ecbab8dbcaa2aa5e8c2d08707@haskell.org> Message-ID: <065.b54248a86ef1db144ee906958682f892@haskell.org> #8976: dll-split: internal error: evacuate(static): strange closure type 0 ----------------------------------------------+--------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Driver | Version: 7.8.1 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #9268 Differential Revisions: | ----------------------------------------------+--------------------------- Changes (by erikd): * cc: erikd (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 14 08:03:01 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Dec 2014 08:03:01 -0000 Subject: [GHC] #9819: Create typesafe method of obtaining dictionary types from class definitions, and constraint objects from dictionary types In-Reply-To: <050.b04515eaa5272881d87195907090dfe3@haskell.org> References: <050.b04515eaa5272881d87195907090dfe3@haskell.org> Message-ID: <065.60afcc08a45d3bccd7504da4ee0c3d48@haskell.org> #9819: Create typesafe method of obtaining dictionary types from class definitions, and constraint objects from dictionary types -------------------------------------+------------------------------------- Reporter: | Owner: spacekitteh | Status: new Type: feature | Milestone: request | Version: Priority: normal | Keywords: Component: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less Operating System: | than a day) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by spacekitteh): Upon perusing the dictionary creation source some more, it appears that it could be implemented by changing adding a flag to {{{ mkClassDataConOcc = mk_simple_deriv dataName "D:" -- We go straight to the "real" data con -- for datacons from classes }}} in compiler/basicTypes/OccName.hs like so {{{ mkClassDataConOcc True = mk_simple_deriv dataName "" mkClassDataConOcc False = mk_simple_deriv dataName "D:" }}} and change buildClass in compiler/iface/BuildTyCl.hs from: {{{ ... ; datacon_name <- newImplicitBinder tycon_name mkClassDataConOcc }}} to {{{ ; datacon_name <- newImplicitBinder tycon_name (mkClassDataConOcc visibleConstructor) }}} This would require modifying buildClass to accept DynFlags, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 14 08:03:31 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Dec 2014 08:03:31 -0000 Subject: [GHC] #9884: Compling on arm and getting "No native code generator, so using LLVM" In-Reply-To: <044.853aba5514cba3c961da3d9712d139ef@haskell.org> References: <044.853aba5514cba3c961da3d9712d139ef@haskell.org> Message-ID: <059.be9f539ac4d3272386519b32ea924252@haskell.org> #9884: Compling on arm and getting "No native code generator, so using LLVM" -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: low | Milestone: Component: Build | Version: 7.9 System | Keywords: Resolution: | Architecture: arm Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Incorrect | Blocked By: warning at compile-time | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Erik de Castro Lopo ): In [changeset:"1886fca9a92fd820f201a57c7afbc157e95f582c/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="1886fca9a92fd820f201a57c7afbc157e95f582c" Only use -fasm on platforms with an NCG (Closes: #9884). Summary: Signed-off-by: Erik de Castro Lopo Reviewers: austin, carter Reviewed By: carter Subscribers: carter, thomie Differential Revision: https://phabricator.haskell.org/D570 GHC Trac Issues: #9884 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 14 08:45:28 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Dec 2014 08:45:28 -0000 Subject: [GHC] #9884: Compling on arm and getting "No native code generator, so using LLVM" In-Reply-To: <044.853aba5514cba3c961da3d9712d139ef@haskell.org> References: <044.853aba5514cba3c961da3d9712d139ef@haskell.org> Message-ID: <059.7097ba1962c841c221ceb3dd42f8f9f4@haskell.org> #9884: Compling on arm and getting "No native code generator, so using LLVM" -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: closed Priority: low | Milestone: Component: Build | Version: 7.9 System | Keywords: Resolution: fixed | Architecture: arm Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Incorrect | Blocked By: warning at compile-time | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by erikd): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 14 10:30:16 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Dec 2014 10:30:16 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.93f0708fa90371ce02974ae13e5ba8b3@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Fuuzetsu Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Difficult (2-5 Type of failure: Other | days) Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Changes (by Fuuzetsu): * owner: => Fuuzetsu Comment: Oops, guess I forgot to put anything here. I've been tasked with fixing this some weeks ago and hope to make progress in this area within this week. Maybe even I'll have a small test case by later today. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 14 10:36:14 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Dec 2014 10:36:14 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.3ee0da4263c921e5a441297d7a9b8993@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Fuuzetsu Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Difficult (2-5 Type of failure: Other | days) Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Fuuzetsu): Oops, guess I forgot to put anything here. I've been tasked with fixing this some weeks ago and hope to make progress in this area within this week. Maybe even I'll have a small test case by later today. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 14 14:30:23 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Dec 2014 14:30:23 -0000 Subject: [GHC] #8024: Dynamic linking not working on PowerPC Linux. In-Reply-To: <044.9ac099edab3e89a81000a0e47392a6e5@haskell.org> References: <044.9ac099edab3e89a81000a0e47392a6e5@haskell.org> Message-ID: <059.e45e129670ed802c50a451f194b1ef1c@haskell.org> #8024: Dynamic linking not working on PowerPC Linux. ----------------------------------------------+--------------------------- Reporter: erikd | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: D560 | ----------------------------------------------+--------------------------- Comment (by Sergei Trofimovich ): In [changeset:"fa31e8f4a0f853848d96549a429083941877bf8d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="fa31e8f4a0f853848d96549a429083941877bf8d" powerpc: fix and enable shared libraries by default on linux Summary: And fix things all the way down to it. Namely: - remove 'r30' from free registers, it's an .LCTOC1 register for gcc. generated .plt stubs expect it to be initialised. - fix PicBase computation, which originally forgot to use 'tmp' reg in 'initializePicBase_ppc.fetchPC' - mark 'ForeighTarget's as implicitly using 'PicBase' register (see comment for details) - add 64-bit MO_Sub and test on alloclimit3/4 regtests - fix dynamic label offsets to match with .LCTOC1 offset Signed-off-by: Sergei Trofimovich Test Plan: validate passes equal amount of vanilla/dyn tests Reviewers: simonmar, erikd, austin Reviewed By: erikd, austin Subscribers: carter, thomie Differential Revision: https://phabricator.haskell.org/D560 GHC Trac Issues: #8024, #9831 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 14 14:30:24 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Dec 2014 14:30:24 -0000 Subject: [GHC] #9831: the 'impossible' happened : iselExpr64(powerpc) In-Reply-To: <044.1090bf2d6b74a28254c5352399819de1@haskell.org> References: <044.1090bf2d6b74a28254c5352399819de1@haskell.org> Message-ID: <059.4feccfef6542f040f29f4206b61d38ee@haskell.org> #9831: the 'impossible' happened : iselExpr64(powerpc) ----------------------------------------------+--------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.9 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: Phab:D560 | ----------------------------------------------+--------------------------- Comment (by Sergei Trofimovich ): In [changeset:"fa31e8f4a0f853848d96549a429083941877bf8d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="fa31e8f4a0f853848d96549a429083941877bf8d" powerpc: fix and enable shared libraries by default on linux Summary: And fix things all the way down to it. Namely: - remove 'r30' from free registers, it's an .LCTOC1 register for gcc. generated .plt stubs expect it to be initialised. - fix PicBase computation, which originally forgot to use 'tmp' reg in 'initializePicBase_ppc.fetchPC' - mark 'ForeighTarget's as implicitly using 'PicBase' register (see comment for details) - add 64-bit MO_Sub and test on alloclimit3/4 regtests - fix dynamic label offsets to match with .LCTOC1 offset Signed-off-by: Sergei Trofimovich Test Plan: validate passes equal amount of vanilla/dyn tests Reviewers: simonmar, erikd, austin Reviewed By: erikd, austin Subscribers: carter, thomie Differential Revision: https://phabricator.haskell.org/D560 GHC Trac Issues: #8024, #9831 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 14 14:55:41 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Dec 2014 14:55:41 -0000 Subject: [GHC] #9867: PatternSynonyms + ScopedTypeVariables triggers an internal error In-Reply-To: <046.5cdd1cb9d606767d1869bca60906658f@haskell.org> References: <046.5cdd1cb9d606767d1869bca60906658f@haskell.org> Message-ID: <061.99676ce473601f435fdbccf5fdd01be6@haskell.org> #9867: PatternSynonyms + ScopedTypeVariables triggers an internal error -------------------------------------+------------------------------------- Reporter: antalsz | Owner: cactus Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: pattern synonyms Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Compile- | Related Tickets: time crash | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by cactus): * keywords: => pattern synonyms * failure: None/Unknown => Compile-time crash * component: Compiler => Compiler (Type checker) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 14 15:26:58 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Dec 2014 15:26:58 -0000 Subject: [GHC] #9877: ForeignImport coercion evaluated before typechecking In-Reply-To: <045.98c4bf8afa11b5771190e9909bffe695@haskell.org> References: <045.98c4bf8afa11b5771190e9909bffe695@haskell.org> Message-ID: <060.cce2234b134b1041afd033ffc6527f50@haskell.org> #9877: ForeignImport coercion evaluated before typechecking -------------------------------------+------------------------------------- Reporter: varosi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Compile- | Difficulty: Unknown time crash | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by varosi): When I build it directly from Cabal it does not crash. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 14 15:29:17 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Dec 2014 15:29:17 -0000 Subject: [GHC] #9867: PatternSynonyms + ScopedTypeVariables triggers an internal error In-Reply-To: <046.5cdd1cb9d606767d1869bca60906658f@haskell.org> References: <046.5cdd1cb9d606767d1869bca60906658f@haskell.org> Message-ID: <061.bdd0a624a993496ff40a7dd345297496@haskell.org> #9867: PatternSynonyms + ScopedTypeVariables triggers an internal error -------------------------------------+------------------------------------- Reporter: antalsz | Owner: cactus Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: pattern synonyms Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Compile- | Related Tickets: time crash | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by cactus): Some brainstorming: The patsyn builders are typechecked from this code: {{{ (binds', (extra_binds', thing)) <- tcBindGroups top_lvl sig_fn prag_fn binds $ do { thing <- thing_inside -- See Note [Pattern synonym builders don't yield dependencies] ; patsyn_builders <- mapM tcPatSynBuilderBind patsyns ; let extra_binds = [ (NonRecursive, builder) | builder <- patsyn_builders ] ; return (extra_binds, thing) } }}} At the time we call `tcPatSynBuilderBind`, all the typechecked pattern synonyms are available in the global environment, so we could look up whatever we could possibly need from the output of the typechecker. Currently, it is only easy to grab stuff from the `PatSyn` (which deliberately doesn't contain any details of the actual definition of the pattern synonym, only its type), but we should be able to look up the `PatSynBind Id Id` for a given `PatSynBind Name Name`; and then we should be in business. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 14 20:10:36 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Dec 2014 20:10:36 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.8354e9f7229fc800760626471fc9b106@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Fuuzetsu Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Difficult (2-5 Type of failure: Other | days) Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Fuuzetsu): I got a test case: I took http-client, a library that was notorious for non-deterministic ABIs, found a small module without any internal imports and stripped it down. It seems that this can be exhibited by nearly any compilation as long as you are compiling more than one module at once: {{{ghc -O -j2 Foo}}} will, AFAICT, for the simple case, result in the same ABI pretty much always. {{{ghc -O -j2 Foo Bar}}} will often not, but how often depends on the content of each. {{{Foo}}} and {{{Bar}}} can be completely independent, not importing each other. Probably going to be looking at uniqs and that {{{unsafeInterleaveIO}}} (thanks to Duncan for pointing it out) but needed a test case first. I attach two modules, {{{T}}} and {{{S}}}: they are not ?trivial? modules because with those the ABI hash changes much less frequently. These modules only import the libraries that ship with GHC so it is easy to hack on. Follows a sample session with 7.8.3: {{{ [shana at lenalee:~/programming/ghc-nondeterminism]$ nix-shell -p haskellPackages.ghc --pure [nix-shell:~/programming/ghc-nondeterminism]$ ghc -fforce-recomp -O -j2 -outputdir tmpdir -odir tmpdir -hidir tmpdir -stubdir tmpdir T S && ghc --show-iface tmpdir/T.hi | grep ABI [1 of 2] Compiling S ( S.hs, tmpdir/S.o ) [2 of 2] Compiling T ( T.hs, tmpdir/T.o ) ABI hash: 801be37df642d815fae5f74aa0f56580 [nix-shell:~/programming/ghc-nondeterminism]$ ghc -fforce-recomp -O -j2 -outputdir tmpdir -odir tmpdir -hidir tmpdir -stubdir tmpdir T S && ghc --show-iface tmpdir/T.hi | grep ABI [1 of 2] Compiling S ( S.hs, tmpdir/S.o ) [2 of 2] Compiling T ( T.hs, tmpdir/T.o ) ABI hash: 59cd140ecf48d626231ac3f8ecb5291e [nix-shell:~/programming/ghc-nondeterminism]$ ghc -fforce-recomp -O -j2 -outputdir tmpdir -odir tmpdir -hidir tmpdir -stubdir tmpdir T S && ghc --show-iface tmpdir/T.hi | grep ABI [1 of 2] Compiling S ( S.hs, tmpdir/S.o ) [2 of 2] Compiling T ( T.hs, tmpdir/T.o ) ABI hash: 563ecab71f525a8aea21d4982ec67388 [nix-shell:~/programming/ghc-nondeterminism]$ l total 44K drwxr-xr-x 3 shana nogroup 4.0K Dec 14 19:59 . drwxr-xr-x 221 shana shana 12K Dec 14 19:58 .. -rw-r--r-- 1 shana nogroup 684 Dec 14 19:59 S.hs -rw-r--r-- 1 shana nogroup 18K Dec 14 19:59 T.hs drwxr-xr-x 2 shana nogroup 4.0K Dec 14 20:03 tmpdir }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 14 20:39:17 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Dec 2014 20:39:17 -0000 Subject: [GHC] #9372: dll-split during stage 2 compiling ghc v7.8.3 for arm_linux In-Reply-To: <047.8ff8936a8082bdb3e0c2617996031a2e@haskell.org> References: <047.8ff8936a8082bdb3e0c2617996031a2e@haskell.org> Message-ID: <062.00f0241e3def6774ce383f0ed77ea7b2@haskell.org> #9372: dll-split during stage 2 compiling ghc v7.8.3 for arm_linux ----------------------------------------------+--------------------------- Reporter: chrisfgl | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8976 Differential Revisions: | ----------------------------------------------+--------------------------- Changes (by nomeata): * status: new => closed * resolution: => duplicate Comment: I don?t think this is more than a duplicate of #8976, closing as such. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 14 20:42:02 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Dec 2014 20:42:02 -0000 Subject: [GHC] #8976: dll-split: internal error: evacuate(static): strange closure type 0 In-Reply-To: <050.3f03921ecbab8dbcaa2aa5e8c2d08707@haskell.org> References: <050.3f03921ecbab8dbcaa2aa5e8c2d08707@haskell.org> Message-ID: <065.1c0df3e7272a7deeaa598c61813f0c3c@haskell.org> #8976: dll-split: internal error: evacuate(static): strange closure type 0 ----------------------------------------------+--------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Driver | Version: 7.8.1 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #9268 Differential Revisions: | ----------------------------------------------+--------------------------- Comment (by nomeata): I managed to build 7.8.4-rc1 by telling GHC to use gold as the linker. Unfortunately, this was not straight forward, as setting CONF_GCC_LINKER_OPTS_STAGE2 using this patch had knock-on-effects: {{{ Index: ghc-7.8.3.20141119/aclocal.m4 =================================================================== --- ghc-7.8.3.20141119.orig/aclocal.m4 2014-12-08 18:49:28.207171714 +0100 +++ ghc-7.8.3.20141119/aclocal.m4 2014-12-08 19:03:06.815522917 +0100 @@ -553,6 +553,10 @@ $3="$$3 -D_HPUX_SOURCE" $5="$$5 -D_HPUX_SOURCE" ;; + arm*) + # On arm, link using gold + $3="$$3 -fuse-ld=gold" + ;; esac # If gcc knows about the stack protector, turn it off. }}} See #9873 for these problems and my (work-around-quality) patch. > I guess it would be good to force the ARM build to use the gold > linker for dyn linking, at least when the bfd linker is "broken". Probably yes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 14 21:16:19 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Dec 2014 21:16:19 -0000 Subject: [GHC] #9223: Type equality makes type variable untouchable In-Reply-To: <048.6ce33f316f2e616ec0311d809cccfbe7@haskell.org> References: <048.6ce33f316f2e616ec0311d809cccfbe7@haskell.org> Message-ID: <063.e9836423a283911a1663cd140f2c5142@haskell.org> #9223: Type equality makes type variable untouchable -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by porges): I ran into something similar to this with a type like: forall t. (forall m. (C m, m ~ t) => m) -> t The solution was to write instead: forall t. ((C t) => t) -> t Are there any cases in which these aren't equivalent? If not, why is GHC not able to reduce the first to the second? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 14 22:10:53 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Dec 2014 22:10:53 -0000 Subject: [GHC] #9885: ghc-pkg parser eats too much memory Message-ID: <045.91c2102f5d7dc20ac2d922c7041cfbfb@haskell.org> #9885: ghc-pkg parser eats too much memory -------------------------------------+------------------------------------- Reporter: gnezdo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: ghc-pkg | Version: 7.8.3 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: Runtime Difficulty: Moderate (less | performance bug than a day) | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Parsing of spec files in ghc-pkg scales very poorly. The following script demonstrates memory consumption growth as a function of the number of tokens in ld-options (16K leads to ~6G) #!/bin/bash # Demonstrates memory consumption behavior of ghc-pkg as a function of # the number of ld-options arguments. for i in {10..14}; do size=$((1 << $i)) echo $size rm -fr a.packages /usr/bin/ghc-pkg init a.packages cat > a.spec <> a.spec for i in $(seq 1 $size); do echo -n "x "; done >> a.spec /usr/bin/time /usr/bin/ghc-pkg --global-package-db a.packages register --force a.spec done exit 0 # This was collected with ghc-7.6.3. 7.8.3 fares as badly. % bash a.sh 1024 Reading package info from "a.spec" ... done. 0.03user 0.00system 0:00.03elapsed 97%CPU (0avgtext+0avgdata 17848maxresident)k 0inputs+32outputs (0major+4973minor)pagefaults 0swaps 2048 Reading package info from "a.spec" ... done. 0.09user 0.01system 0:00.10elapsed 99%CPU (0avgtext+0avgdata 60872maxresident)k 0inputs+56outputs (0major+15723minor)pagefaults 0swaps 4096 Reading package info from "a.spec" ... done. 0.41user 0.07system 0:00.49elapsed 99%CPU (0avgtext+0avgdata 294340maxresident)k 0inputs+104outputs (0major+74090minor)pagefaults 0swaps 8192 Reading package info from "a.spec" ... done. 1.72user 0.30system 0:02.04elapsed 99%CPU (0avgtext+0avgdata 1168836maxresident)k 0inputs+192outputs (0major+292716minor)pagefaults 0swaps 16384 Reading package info from "a.spec" ... done. 9.11user 1.38system 0:10.51elapsed 99%CPU (0avgtext+0avgdata 5396932maxresident)k 0inputs+376outputs (0major+1349736minor)pagefaults 0swaps -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 14 22:15:54 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Dec 2014 22:15:54 -0000 Subject: [GHC] #9885: ghc-pkg parser eats too much memory In-Reply-To: <045.91c2102f5d7dc20ac2d922c7041cfbfb@haskell.org> References: <045.91c2102f5d7dc20ac2d922c7041cfbfb@haskell.org> Message-ID: <060.b4703de4319fbb6efbaf985eb65379de@haskell.org> #9885: ghc-pkg parser eats too much memory -------------------------------------+------------------------------------- Reporter: gnezdo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: ghc-pkg | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Moderate (less performance bug | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Comment (by gnezdo): I did some profiling. To save somebody a bit of digging, reproducing the build/profile/plot script here (would love to hear how to do this more optimally): {{{ #!/bin/bash # Demonstrates memory consumption behavior of ghc-pkg as a function of # the number of ld-options arguments. set -eu (cd ~/ghc-copy/Cabal/Cabal && cabal install --enable-library-profiling --enable-executable-profiling --force-reinstalls --ghc-option=-rtsopts --ghc-option=-prof --ghc-option=-fprof-auto) (cd ~/ghc-copy/ghc/libraries/bin-package-db && cabal install --enable- library-profiling --enable-executable-profiling --force-reinstalls --ghc- option=-rtsopts --ghc-option=-prof --ghc-option=-fprof-auto) (cd ~/ghc-copy/ghc/utils/ghc-pkg && cabal install --enable-library- profiling --enable-executable-profiling --force-reinstalls --ghc- option=-rtsopts --ghc-option=-prof --ghc-option=-fprof-auto --ghc- option=-DBOOTSTRAPPING) ghcpkg=~/.cabal/bin/ghc-pkg for i in {13..13}; do size=$((1 << $i)) echo $size rm -fr a.packages $ghcpkg init a.packages cat > a.spec <> a.spec for i in $(seq 1 $size); do echo -n "x "; done >> a.spec rm -f ghc-pkg.{hp,ps} /usr/bin/time $ghcpkg -v2 --global-package-db a.packages register --force a.spec +RTS -hc -L100 || true hp2ps -b -c ghc-pkg.hp evince ghc-pkg.ps done }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 14 22:19:41 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Dec 2014 22:19:41 -0000 Subject: [GHC] #9885: ghc-pkg parser eats too much memory In-Reply-To: <045.91c2102f5d7dc20ac2d922c7041cfbfb@haskell.org> References: <045.91c2102f5d7dc20ac2d922c7041cfbfb@haskell.org> Message-ID: <060.d2b137d0b91c99f057cfcd9a62dda592@haskell.org> #9885: ghc-pkg parser eats too much memory -------------------------------------+------------------------------------- Reporter: gnezdo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: ghc-pkg | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Moderate (less performance bug | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Comment (by gnezdo): The most expensive place seems to be this (quoted from .hp file, lightly munged): {{{ (953)>>=.\.\.(...) >>=.\.\ >>=.\ >>= many1 many sepBy1 sepBy parseSepList parseOptCommaList listField installedFieldDescrs accumFields.setField accumFields parseFieldsFlat.\ parseFieldsFlat parseInstalledPackageInfo parsePackageInfo registerPackage runit main 794023536 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 14 22:21:43 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Dec 2014 22:21:43 -0000 Subject: [GHC] #3927: Incomplete/overlapped pattern warnings + GADTs = inadequate In-Reply-To: <046.0473c92f4a34c84959f5237ada18226b@haskell.org> References: <046.0473c92f4a34c84959f5237ada18226b@haskell.org> Message-ID: <061.d78f78b715b1887142820b3e4d5ff8f5@haskell.org> #3927: Incomplete/overlapped pattern warnings + GADTs = inadequate -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 6.12.1 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #4139 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nh2): I'm having the same problem, `-Wall` reporting `Patterns not matched: Step _ (End _)` for some code but if I put that match in, I get `Inaccessible code in a pattern with constructor`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 14 23:30:41 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Dec 2014 23:30:41 -0000 Subject: [GHC] #9691: GHC-HEAD runtime is broken on arm In-Reply-To: <047.9fcb5b64ebe9f7a33ad168c55acc7b20@haskell.org> References: <047.9fcb5b64ebe9f7a33ad168c55acc7b20@haskell.org> Message-ID: <062.d0323e4c47f62c4d0178138c969eb7f9@haskell.org> #9691: GHC-HEAD runtime is broken on arm ----------------------------------------+--------------------------- Reporter: mkbrandt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------+--------------------------- Changes (by erikd): * cc: erikd (added) Comment: I'm seeing something very similar with git head (b8392ae76a6d39) cross compiling from a Debian amd64-linux to arm-linux-gnueabihf (beaglebone- black running Debian). My test program is: {{{ main :: IO () main = putStrLn "Hello" }}} and when I copy the compiled binary to the beaglebone and run it, it segfaults almost immediately. The GDB backtrace looks like this: {{{ Program received signal SIGSEGV, Segmentation fault. 0x0021b8dc in stg_init_finish$def () (gdb) bt #0 0x0021b8dc in stg_init_finish$def () #1 0x00217116 in threadPaused () #2 0x00000000 in ?? () }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 14 23:37:52 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Dec 2014 23:37:52 -0000 Subject: [GHC] #9691: GHC-HEAD runtime is broken on arm In-Reply-To: <047.9fcb5b64ebe9f7a33ad168c55acc7b20@haskell.org> References: <047.9fcb5b64ebe9f7a33ad168c55acc7b20@haskell.org> Message-ID: <062.210ef09812fd185f0150eee0304ceda9@haskell.org> #9691: GHC-HEAD runtime is broken on arm ----------------------------------------+--------------------------- Reporter: mkbrandt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------+--------------------------- Comment (by erikd): Very similar problem on natve arm -> arm compiler: {{{ Program received signal SIGSEGV, Segmentation fault. 0x01d0a278 in stg_init_finish$def () (gdb) bt #0 0x01d0a278 in stg_init_finish$def () #1 0x01d031b2 in threadPaused () #2 0x4023f8ca in phys_pages_info (format=0x1 ) at ../sysdeps/unix/sysv/linux/getsysstats.c:314 #3 0x01d00dd4 in schedule () Backtrace stopped: previous frame inner to this frame (corrupt stack?) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 15 00:02:58 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Dec 2014 00:02:58 -0000 Subject: [GHC] #9886: Undefined reference to `__sync_fetch_and_xor_8' Message-ID: <044.594e65ad21717924722ced76afd26d12@haskell.org> #9886: Undefined reference to `__sync_fetch_and_xor_8' -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (CodeGen) | Operating System: Keywords: | Unknown/Multiple Architecture: powerpc | Type of failure: Building Difficulty: Unknown | GHC failed Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Compiling on PowerPC with git head (0c9c2d899e63b810), compile terminates with: {{{ /home/ghc-upstream/libraries/ghc-prim/dist-install/build/ libHSghcpr_FgrV6cgh2JHBlbcx1OSlwt-ghc7.9.20141214.so: undefined reference to `__sync_fetch_and_xor_8' /home/ghc-upstream/libraries/ghc-prim/dist-install/build/ libHSghcpr_FgrV6cgh2JHBlbcx1OSlwt-ghc7.9.20141214.so: undefined reference to `__sync_fetch_and_and_8' /home/ghc-upstream/libraries/ghc-prim/dist-install/build/ libHSghcpr_FgrV6cgh2JHBlbcx1OSlwt-ghc7.9.20141214.so: undefined reference to `__sync_fetch_and_nand_8' /home/ghc-upstream/libraries/ghc-prim/dist-install/build/ libHSghcpr_FgrV6cgh2JHBlbcx1OSlwt-ghc7.9.20141214.so: undefined reference to `__sync_val_compare_and_swap_8' /home/ghc-upstream/libraries/ghc-prim/dist-install/build/ libHSghcpr_FgrV6cgh2JHBlbcx1OSlwt-ghc7.9.20141214.so: undefined reference to `__sync_fetch_and_sub_8' /home/ghc-upstream/libraries/ghc-prim/dist-install/build/ libHSghcpr_FgrV6cgh2JHBlbcx1OSlwt-ghc7.9.20141214.so: undefined reference to `__sync_fetch_and_add_8' /home/ghc-upstream/libraries/ghc-prim/dist-install/build/ libHSghcpr_FgrV6cgh2JHBlbcx1OSlwt-ghc7.9.20141214.so: undefined reference to `__sync_fetch_and_or_8' }}} Looks like some new primops that need to be implemented for powerpc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 15 00:07:20 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Dec 2014 00:07:20 -0000 Subject: [GHC] #9886: Undefined reference to `__sync_fetch_and_xor_8' In-Reply-To: <044.594e65ad21717924722ced76afd26d12@haskell.org> References: <044.594e65ad21717924722ced76afd26d12@haskell.org> Message-ID: <059.f282c4d8fc6a9797e406c39e7b8d0ff6@haskell.org> #9886: Undefined reference to `__sync_fetch_and_xor_8' ----------------------------------------------+--------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (CodeGen) | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------------+--------------------------- Comment (by erikd): There is a quick and *very* dirty hack to get GHC compiling here ( https://phabricator.haskell.org/D560#15871 ) but it doesn't actually fix the problem, just prevent the compile error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 15 01:51:46 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Dec 2014 01:51:46 -0000 Subject: [GHC] #9878: Static pointers in GHCi cause panic In-Reply-To: <047.a0b4c5e0dee3f65cf24b644a915474ce@haskell.org> References: <047.a0b4c5e0dee3f65cf24b644a915474ce@haskell.org> Message-ID: <062.2afdd6665e6162bace0bcf50f966353a@haskell.org> #9878: Static pointers in GHCi cause panic -------------------------------------+------------------------------------- Reporter: monoidal | Owner: facundo.dominguez Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHCi crash | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by qnikst): There are 2 issues here: 1. That we don't support static pointers in ghci without fobject code. This is because module constructor that we are creating is not called, and because `speEntry` expressions that float out on desugarer phase is not instantiated by ghci. 2. Also staticPtrKeys works incorrectly: a. it segfaults b. it memoizes it's result: {{{ Prelude> :l Static Ok, modules loaded: Static. Prelude Static> length GHC.StaticPtr.currentStaticPtrKeys Prelude Static> length GHC.StaticPtr.staticPtrKeys staticPtrKeys <-- debug ouput (function was called) 0 Prelude Static> f99 <-- forcing module loading True Prelude Static> length GHC.StaticPtr.staticPtrKeys 0 <-- no debug output (function was not called) Prelude Static> fmap length GHC.StaticPtr.currentStaticPtrKeys <-- IO variant staticPtrKeys <-- debug output count: 1025 1025 }}} While I don't know an easy way to workaround 1st issue, I'll attach patches for the 2a and 2b. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 15 02:59:43 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Dec 2014 02:59:43 -0000 Subject: [GHC] #9819: Create typesafe method of obtaining dictionary types from class definitions, and constraint objects from dictionary types In-Reply-To: <050.b04515eaa5272881d87195907090dfe3@haskell.org> References: <050.b04515eaa5272881d87195907090dfe3@haskell.org> Message-ID: <065.18d012301ca5afc04768acc662afa3cb@haskell.org> #9819: Create typesafe method of obtaining dictionary types from class definitions, and constraint objects from dictionary types -------------------------------------+------------------------------------- Reporter: | Owner: spacekitteh | Status: new Type: feature | Milestone: request | Version: Priority: normal | Keywords: Component: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less Operating System: | than a day) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:9 spacekitteh]: > Right. I'm not requesting local instances as a whole; rather, just access to the desugared typeclass dictionary types. Basically, adding a Dictionary kind, and a type function from Constraint kinds to Dictionary kinds (local instances could involve adding a type function in the reverse direction). Additionally, a Coercible instance for the class and the dictionary would be useful too. > > This seems like it would be fairly straightforward to implement and not involve much design work; the problems seem to only arise when going from Dictionary -> Constraint. Ah. This makes sense. But, before diving into implementation, we need a clear specification of the feature, preferably on a wiki page. The page should contain motivation and examples of programs that you wish to be accepted. Then, we'll all have a better idea of what we're discussing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 15 03:57:14 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Dec 2014 03:57:14 -0000 Subject: [GHC] #9819: Create typesafe method of obtaining dictionary types from class definitions, and constraint objects from dictionary types In-Reply-To: <050.b04515eaa5272881d87195907090dfe3@haskell.org> References: <050.b04515eaa5272881d87195907090dfe3@haskell.org> Message-ID: <065.abc7fc28c3a909b12434f5730c264d78@haskell.org> #9819: Create typesafe method of obtaining dictionary types from class definitions, and constraint objects from dictionary types -------------------------------------+------------------------------------- Reporter: | Owner: spacekitteh | Status: new Type: feature | Milestone: request | Version: Priority: normal | Keywords: Component: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less Operating System: | than a day) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by spacekitteh): (Sorry for not being very clear; I'm autistic) I'll get to work on a wiki page I guess. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 15 04:42:56 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Dec 2014 04:42:56 -0000 Subject: [GHC] #9819: Create typesafe method of obtaining dictionary types from class definitions, and constraint objects from dictionary types In-Reply-To: <050.b04515eaa5272881d87195907090dfe3@haskell.org> References: <050.b04515eaa5272881d87195907090dfe3@haskell.org> Message-ID: <065.8c1e2cd403ac4777a9a9d0acfd8492d8@haskell.org> #9819: Create typesafe method of obtaining dictionary types from class definitions, and constraint objects from dictionary types -------------------------------------+------------------------------------- Reporter: | Owner: spacekitteh | Status: new Type: feature | Milestone: request | Version: Priority: normal | Keywords: Component: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less Operating System: | than a day) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by spacekitteh): https://ghc.haskell.org/trac/ghc/wiki/DesugaredDictionaries -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 15 04:44:57 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Dec 2014 04:44:57 -0000 Subject: [GHC] #9878: Static pointers in GHCi cause panic In-Reply-To: <047.a0b4c5e0dee3f65cf24b644a915474ce@haskell.org> References: <047.a0b4c5e0dee3f65cf24b644a915474ce@haskell.org> Message-ID: <062.327f3168ff7d14fe7f169dafae4f2256@haskell.org> #9878: Static pointers in GHCi cause panic -------------------------------------+------------------------------------- Reporter: monoidal | Owner: facundo.dominguez Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHCi crash | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): the hashtable has a comment remarking that it isn't thread safe in the context of multiple concurrent updates... is that OK? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 15 06:06:00 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Dec 2014 06:06:00 -0000 Subject: [GHC] #9885: ghc-pkg parser eats too much memory In-Reply-To: <045.91c2102f5d7dc20ac2d922c7041cfbfb@haskell.org> References: <045.91c2102f5d7dc20ac2d922c7041cfbfb@haskell.org> Message-ID: <060.2beea6f7396d1dda33e176d0d58d9531@haskell.org> #9885: ghc-pkg parser eats too much memory -------------------------------------+------------------------------------- Reporter: gnezdo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: ghc-pkg | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Moderate (less performance bug | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Comment (by gnezdo): Filed as https://github.com/haskell/cabal/issues/2276 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 15 08:32:00 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Dec 2014 08:32:00 -0000 Subject: [GHC] #9886: Undefined reference to `__sync_fetch_and_xor_8' In-Reply-To: <044.594e65ad21717924722ced76afd26d12@haskell.org> References: <044.594e65ad21717924722ced76afd26d12@haskell.org> Message-ID: <059.3f85b12b47e96ca46d1106b8daf94fe3@haskell.org> #9886: Undefined reference to `__sync_fetch_and_xor_8' ----------------------------------------------+--------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (CodeGen) | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------------+--------------------------- Comment (by tibbe): I believe we fixed this on x86 by requiring i686. Can't find the ticket right now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 15 08:33:09 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Dec 2014 08:33:09 -0000 Subject: [GHC] #9223: Type equality makes type variable untouchable In-Reply-To: <048.6ce33f316f2e616ec0311d809cccfbe7@haskell.org> References: <048.6ce33f316f2e616ec0311d809cccfbe7@haskell.org> Message-ID: <063.583c419c6bfded56d57ea552b6a6123a@haskell.org> #9223: Type equality makes type variable untouchable -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): @porges: Yes, the two types should be equivalent. GHC HEAD (and 7.10) should be better in this regard. Can you try your example with that? @goldire: you may be right. But even if you are, there's a balance between trying to make type inference as clever as possible and making it so unpredictable that no one knows whether it'll work or not. But I'm open to suggetions. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 15 08:37:01 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Dec 2014 08:37:01 -0000 Subject: [GHC] #3927: Incomplete/overlapped pattern warnings + GADTs = inadequate In-Reply-To: <046.0473c92f4a34c84959f5237ada18226b@haskell.org> References: <046.0473c92f4a34c84959f5237ada18226b@haskell.org> Message-ID: <061.9417f89d38a9ebc4848b25afc27c6f5d@haskell.org> #3927: Incomplete/overlapped pattern warnings + GADTs = inadequate -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 6.12.1 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #4139 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: george.karachalias@? (added) Comment: Happily, George K is working on this: see [wiki/PatternMatchCheck] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 15 08:39:11 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Dec 2014 08:39:11 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.d4c8568c2615e3a35a1ab292c0f426ba@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Fuuzetsu Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Difficult (2-5 Type of failure: Other | days) Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonmar): @Fuuzetsu: there are several known causes of non-deterministic ABIs. See the description of the ticket for more details. It's usually possible to reproduce these by compiling a package once, touch the source files, and then recompile it and watch the hashes change. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 15 08:50:10 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Dec 2014 08:50:10 -0000 Subject: [GHC] #9873: Use CONF_GCC_LINKER_OPTS_STAGE2 only in stage2 In-Reply-To: <046.77f53bab4b42e7b7f0531b045d80ca9c@haskell.org> References: <046.77f53bab4b42e7b7f0531b045d80ca9c@haskell.org> Message-ID: <061.bb6ae4f11d0da7ecbc384b2353d0a705@haskell.org> #9873: Use CONF_GCC_LINKER_OPTS_STAGE2 only in stage2 -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.9 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nomeata): Did you also apply the patch that actually makes it use `gold`? {{{ Index: ghc-7.8.3.20141119/aclocal.m4 =================================================================== --- ghc-7.8.3.20141119.orig/aclocal.m4 2014-12-08 18:49:28.207171714+0100 +++ ghc-7.8.3.20141119/aclocal.m4 2014-12-08 19:03:06.815522917+0100 @@ -553,6 +553,10 @@ $3="$$3 -D_HPUX_SOURCE" $5="$$5 -D_HPUX_SOURCE" ;; + arm*) + # On arm, link using gold + $3="$$3 -fuse-ld=gold" + ;; esac # If gcc knows about the stack protector, turn it off. }}} And how does it fail? Did it run `dll-split` successfully? Might be a different issue. You should talk to gamari about it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 15 08:54:16 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Dec 2014 08:54:16 -0000 Subject: [GHC] #9819: Create typesafe method of obtaining dictionary types from class definitions, and constraint objects from dictionary types In-Reply-To: <050.b04515eaa5272881d87195907090dfe3@haskell.org> References: <050.b04515eaa5272881d87195907090dfe3@haskell.org> Message-ID: <065.6155e83c8905dd59b0829ea0d2c70afd@haskell.org> #9819: Create typesafe method of obtaining dictionary types from class definitions, and constraint objects from dictionary types -------------------------------------+------------------------------------- Reporter: | Owner: spacekitteh | Status: new Type: feature | Milestone: request | Version: Priority: normal | Keywords: Component: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less Operating System: | than a day) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Thanks. I have not been following the thread in detail, because I've been hoping it would reach a conclusion in the form of a wiki page summarising the proposal. Thank you for making a start on it. But I can't understand it (yet) I'm afraid. Could you have a go at clarifying. In particular: * What, precisely, IS the proposal? Perhaps you can add a section heading "The proposal" that says, as precisely as possible, what the changes (from the point of view of the user) are. Is there any new syntax? Are there any new system-provided functions? Does type inference change? (For example, the wiki page mentions `using`, but I have no idea what it is.) * You could have a sub-section "What this proposal is NOT", covering the bit about overlapping instances. * Several examples of using the new facility. Again a section "Examples of use". * Then (and only then) some discussion about implementation. Thanks. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 15 09:15:18 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Dec 2014 09:15:18 -0000 Subject: [GHC] #9887: No message when GCHI reusing compiled code Message-ID: <045.cf91be422b5fc2a64d8ab73a523f6c8e@haskell.org> #9887: No message when GCHI reusing compiled code -------------------------------------+------------------------------------- Reporter: jsrice | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: Other hour) | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Running ":l Main.hs" at the GHCI prompt would load the compiled module. I am new to Haskell and this was a stumbling block that made it so that I could not interactively debug my code with GHCI. Deleting the object files was suggested to me on IRC and that allowed me to get the "*Main" prompt I was looking for. A message warning users "reusing compiled code" would likely save some future users some time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 15 09:39:21 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Dec 2014 09:39:21 -0000 Subject: [GHC] #9886: Undefined reference to `__sync_fetch_and_xor_8' In-Reply-To: <044.594e65ad21717924722ced76afd26d12@haskell.org> References: <044.594e65ad21717924722ced76afd26d12@haskell.org> Message-ID: <059.31c66cf08c8e09a3196b65cfb5de1944@haskell.org> #9886: Undefined reference to `__sync_fetch_and_xor_8' ----------------------------------------------+--------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (CodeGen) | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------------+--------------------------- Comment (by tibbe): The x86 issue was fixed in #9346. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 15 09:58:52 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Dec 2014 09:58:52 -0000 Subject: [GHC] #9873: Use CONF_GCC_LINKER_OPTS_STAGE2 only in stage2 In-Reply-To: <046.77f53bab4b42e7b7f0531b045d80ca9c@haskell.org> References: <046.77f53bab4b42e7b7f0531b045d80ca9c@haskell.org> Message-ID: <061.ffce8924af9c61f0fb442746fd354222@haskell.org> #9873: Use CONF_GCC_LINKER_OPTS_STAGE2 only in stage2 -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.9 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by erikd): Nope missed that bit. Retrying now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 15 12:21:53 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Dec 2014 12:21:53 -0000 Subject: [GHC] #9887: No message when GCHI reusing compiled code In-Reply-To: <045.cf91be422b5fc2a64d8ab73a523f6c8e@haskell.org> References: <045.cf91be422b5fc2a64d8ab73a523f6c8e@haskell.org> Message-ID: <060.9ee2123c2264e22b84415a4ad89ba4e3@haskell.org> #9887: No message when GCHI reusing compiled code -------------------------------------+------------------------------------- Reporter: jsrice | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: Other | hour) Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): To reproduce: {{{ $ cat T9887.hs module T9887 where foo = "bar" $ ghc -c -dynamic T9887.hs $ ghci GHCi, version 7.8.3: ... Prelude> :l T9887 Ok, modules loaded: T9887. -- Should show: "reusing compiled code" Prelude T9887> :break 2 No modules are loaded with debugging support. -- Improve this message as well. }}} For whoever implements this suggestion: don't forget to update the [https://downloads.haskell.org/~ghc/7.8.3/docs/html/users_guide/ghci- compiled.html Users's guide]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 15 13:34:01 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Dec 2014 13:34:01 -0000 Subject: [GHC] #9880: ghc crashes on th splices in instance context In-Reply-To: <048.f4daf5bbce32dd24217721fc99cc931b@haskell.org> References: <048.f4daf5bbce32dd24217721fc99cc931b@haskell.org> Message-ID: <063.c3a68e8388698338a2eb153da83dd5ea@haskell.org> #9880: ghc crashes on th splices in instance context -------------------------------------+------------------------------------- Reporter: Philonous | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: goldfire (added) Comment: HEAD says {{{ T9880.hs:5:3: Declaration splices are allowed only at the top level: $mkFun }}} which is a lot better than crashing. Richard is this supposed to work now? I recall that you largely made splices in local declarations work. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 15 14:50:21 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Dec 2014 14:50:21 -0000 Subject: [GHC] #7942: aarch64 support in ghc In-Reply-To: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> References: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> Message-ID: <060.b5e3ad73500caaef9995d50fede6ff46@haskell.org> #7942: aarch64 support in ghc -------------------------------------+------------------------------------- Reporter: jcapik | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.10.1 Component: Compiler | Version: Resolution: fixed | Keywords: Operating System: Linux | Architecture: arm Type of failure: GHC | Difficulty: Unknown doesn't work at all | Blocked By: Test Case: | Related Tickets: 7623, 8664 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Yes, leaving AArch64 in 7.10 only was the intention; no 7.8.4. Sorry for the confusion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 15 14:55:49 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Dec 2014 14:55:49 -0000 Subject: [GHC] #8951: genSym uses atomic_inc but doesn't link arm_atomic_spin_lock In-Reply-To: <047.6361bb2814dd444a3dfd661ef69cb2b7@haskell.org> References: <047.6361bb2814dd444a3dfd661ef69cb2b7@haskell.org> Message-ID: <062.a9504bfac25809a62299c2310c4f61f9@haskell.org> #8951: genSym uses atomic_inc but doesn't link arm_atomic_spin_lock -------------------------------------+------------------------------------- Reporter: cjwatson | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.4 Component: Build | Version: 7.8.1-rc1 System | Keywords: Resolution: fixed | Architecture: arm Operating System: Linux | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged to 7.8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 15 14:55:55 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Dec 2014 14:55:55 -0000 Subject: [GHC] #9817: signal handlers in unix are passed garbage when using the signle threaded rts In-Reply-To: <045.646b26d4129c0e58f98ff89c628f56b1@haskell.org> References: <045.646b26d4129c0e58f98ff89c628f56b1@haskell.org> Message-ID: <060.9ae98c65aa581429c3fc358fe8c53f70@haskell.org> #9817: signal handlers in unix are passed garbage when using the signle threaded rts -------------------------------------+------------------------------------- Reporter: redneb | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 7.8.4 Component: Runtime | Version: 7.8.3 System | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: POSIX | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D515 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed * milestone: => 7.8.4 Comment: Merged to 7.8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 15 14:56:01 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Dec 2014 14:56:01 -0000 Subject: [GHC] #9620: libffi.a is put in the wrong folder In-Reply-To: <045.b16a82152c1ca2a716618b81b7153c19@haskell.org> References: <045.b16a82152c1ca2a716618b81b7153c19@haskell.org> Message-ID: <060.95ff1e901e90a95d6730b569b3fbb1c2@haskell.org> #9620: libffi.a is put in the wrong folder -------------------------------------+------------------------------------- Reporter: rezb1t | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.4 Component: Build | Version: 7.9 System | Keywords: libffi lib64 Resolution: fixed | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * milestone: 7.10.1 => 7.8.4 Comment: Merged to 7.8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 15 14:56:07 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Dec 2014 14:56:07 -0000 Subject: [GHC] #9336: binutils gold linker detection does not work when called via gcc and selected by commandline parameters In-Reply-To: <044.1f99437dfb37404e6cbefdee11591c8a@haskell.org> References: <044.1f99437dfb37404e6cbefdee11591c8a@haskell.org> Message-ID: <059.ebcc001bb82a7ca45c4caa499c6f0e4a@haskell.org> #9336: binutils gold linker detection does not work when called via gcc and selected by commandline parameters -------------------------------------+------------------------------------- Reporter: slomo | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.4 Component: Driver | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8976 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed Comment: Merged to 7.8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 15 14:56:14 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Dec 2014 14:56:14 -0000 Subject: [GHC] #9523: Typo in GHC Generics documentation In-Reply-To: <045.f6500f2e6e7dfb47345436a2e3e2ff3d@haskell.org> References: <045.f6500f2e6e7dfb47345436a2e3e2ff3d@haskell.org> Message-ID: <060.fbceeda175c5b0ad34f7ebfcde82217f@haskell.org> #9523: Typo in GHC Generics documentation -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.4 Component: | Version: 7.8.3 Documentation | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed * milestone: 7.10.1 => 7.8.4 Comment: Merged to 7.8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 15 14:56:39 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Dec 2014 14:56:39 -0000 Subject: [GHC] #9552: powerpc64 little endian: dll-split: Reachable modules from DynFlags out of date In-Reply-To: <047.a5a0d83a85e9f507ac92882847117a99@haskell.org> References: <047.a5a0d83a85e9f507ac92882847117a99@haskell.org> Message-ID: <062.65748b781e46ca7e57373f003d53593f@haskell.org> #9552: powerpc64 little endian: dll-split: Reachable modules from DynFlags out of date -------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Building | Difficulty: Unknown GHC failed | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed Comment: Merged to 7.8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 15 14:56:47 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Dec 2014 14:56:47 -0000 Subject: [GHC] #8988: Documentation build fails if GHCi is unavailable In-Reply-To: <047.4e32c2ffd98d48e7ad6de5d06c23433e@haskell.org> References: <047.4e32c2ffd98d48e7ad6de5d06c23433e@haskell.org> Message-ID: <062.b4fce988015d90c3505f02898c83c296@haskell.org> #8988: Documentation build fails if GHCi is unavailable -------------------------------------+------------------------------------- Reporter: cjwatson | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.1 (Type checker) | Keywords: Resolution: fixed | Architecture: arm Operating System: Linux | Difficulty: Easy (less than 1 Type of failure: Building | hour) GHC failed | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed Comment: Merged to 7.8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 15 15:04:04 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Dec 2014 15:04:04 -0000 Subject: [GHC] #9390: Inlining prevents evaluation of ignored parts of unboxed tuples In-Reply-To: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> References: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> Message-ID: <062.b9aef042152aaeeab09e93d9544e6f00@haskell.org> #9390: Inlining prevents evaluation of ignored parts of unboxed tuples -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Incorrect | Difficulty: Unknown result at runtime | Blocked By: Test Case: | Related Tickets: simplCore/should_run/T9390 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed * milestone: 7.10.1 => 7.8.4 Comment: Merged to 7.8.4 since this is actually a good bug to fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 15 15:04:21 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Dec 2014 15:04:21 -0000 Subject: [GHC] #9877: ForeignImport coercion evaluated before typechecking In-Reply-To: <045.98c4bf8afa11b5771190e9909bffe695@haskell.org> References: <045.98c4bf8afa11b5771190e9909bffe695@haskell.org> Message-ID: <060.a7d5ef4211fc32cc36119ba6441bdb2b@haskell.org> #9877: ForeignImport coercion evaluated before typechecking -------------------------------------+------------------------------------- Reporter: varosi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Compile- | Difficulty: Unknown time crash | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by varosi): As I know buildwrapper is using GHC API, but I don't know how could I test it out of EclipseFP. This is buildwrapper project: https://github.com/JPMoresmau/BuildWrapper -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 15 15:04:28 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Dec 2014 15:04:28 -0000 Subject: [GHC] #9415: Superclass cycle with ambiguous type causes loop In-Reply-To: <047.4ec8abd880d85c1c64e1296abb8ae151@haskell.org> References: <047.4ec8abd880d85c1c64e1296abb8ae151@haskell.org> Message-ID: <062.351f96ff9b99936b5249e0ea5a9e8dc1@haskell.org> #9415: Superclass cycle with ambiguous type causes loop -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | typecheck/should_fail/T9415 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed * milestone: 7.10.1 => 7.8.4 Comment: Merged to 7.8.4 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 15 15:04:34 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Dec 2014 15:04:34 -0000 Subject: [GHC] #9371: Overlapping type families, segafult In-Reply-To: <044.67d504251b4c6afbb591b885728a5986@haskell.org> References: <044.67d504251b4c6afbb591b885728a5986@haskell.org> Message-ID: <059.7a42300e453162177cc2234bce96118a@haskell.org> #9371: Overlapping type families, segafult -------------------------------------+------------------------------------- Reporter: pingu | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime | Difficulty: Unknown crash | Blocked By: Test Case: indexed- | Related Tickets: types/should_fail/T9371 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed * milestone: 7.10.1 => 7.8.4 Comment: Merged to 7.8.4 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 15 15:13:13 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Dec 2014 15:13:13 -0000 Subject: [GHC] #7143: ghc-7.6.0.20120810-x86_64-windows.exe -> ghc can't figure out LLVM version In-Reply-To: <048.2fa9f9bf55f3bc1ae7013e61d58e551e@haskell.org> References: <048.2fa9f9bf55f3bc1ae7013e61d58e551e@haskell.org> Message-ID: <063.792f0c353e40b813e516bbdb4c5ee8b6@haskell.org> #7143: ghc-7.6.0.20120810-x86_64-windows.exe -> ghc can't figure out LLVM version -------------------------------------+------------------------------------- Reporter: cetinsert | Owner: Fanael Type: bug | Status: closed Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.6.1-rc1 (LLVM) | Keywords: llvm Resolution: fixed | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: Incorrect | Blocked By: warning at compile-time | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D190 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed * milestone: 7.10.1 => 7.8.4 Comment: Merged to 7.8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 15 15:13:59 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Dec 2014 15:13:59 -0000 Subject: [GHC] #9563: Support for deriving Generic1 for data families In-Reply-To: <047.5afce0493774ce2d5de4e9e316ca0dec@haskell.org> References: <047.5afce0493774ce2d5de4e9e316ca0dec@haskell.org> Message-ID: <062.74dace1806424b9e356d711ded47baef@haskell.org> #9563: Support for deriving Generic1 for data families -------------------------------------+------------------------------------- Reporter: mnislaih | Owner: dreixel Type: bug | Status: closed Priority: high | Milestone: 7.8.4 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: GHC | Difficulty: Unknown rejects valid program | Blocked By: Test Case: | Related Tickets: generics/T9563 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged to 7.8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 15 15:15:08 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Dec 2014 15:15:08 -0000 Subject: [GHC] #8778: Typeable TypeNats In-Reply-To: <047.b9d30639552108a8bde373a259728a9f@haskell.org> References: <047.b9d30639552108a8bde373a259728a9f@haskell.org> Message-ID: <062.d8ca9b76cd43bcbb9693164582d37535@haskell.org> #8778: Typeable TypeNats -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: diatchki Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: 7.8.1-rc1 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: 4385 Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Closing since this is all done. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 15 15:24:30 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Dec 2014 15:24:30 -0000 Subject: [GHC] #4428: Local functions lose their unfoldings In-Reply-To: <041.05f579c54cae7f6ea359ae3b76daabb5@haskell.org> References: <041.05f579c54cae7f6ea359ae3b76daabb5@haskell.org> Message-ID: <056.5bfb610ea9fe2a8e74969599b3f3d353@haskell.org> #4428: Local functions lose their unfoldings -------------------------------------+------------------------------------- Reporter: rl | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: Compiler | Version: 7.1 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: infoneeded => closed * resolution: => fixed * milestone: 7.10.1 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 15 15:26:52 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Dec 2014 15:26:52 -0000 Subject: [GHC] #4896: Deriving Data does not work for attached code In-Reply-To: <044.d2e84887ce906663629df5acb6b383eb@haskell.org> References: <044.d2e84887ce906663629df5acb6b383eb@haskell.org> Message-ID: <059.a10ad9a7bd89d91b890c9670a527d58d@haskell.org> #4896: Deriving Data does not work for attached code -------------------------------------+------------------------------------- Reporter: mitar | Owner: Type: bug | Status: closed Priority: low | Milestone: 7.10.1 Component: Compiler | Version: 7.1 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | deriving/should_compile/T4896 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: infoneeded => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 15 15:31:12 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Dec 2014 15:31:12 -0000 Subject: [GHC] #9393: execvpe should handle ENOTDIR In-Reply-To: <044.de71ccdfac1cf39975dbc19d1eedf841@haskell.org> References: <044.de71ccdfac1cf39975dbc19d1eedf841@haskell.org> Message-ID: <059.eb1284c0ce612f6d5e634122b84578f7@haskell.org> #9393: execvpe should handle ENOTDIR -------------------------------------+------------------------------------- Reporter: iquiw | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.8.2 Libraries | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by hvr): * status: upstream => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 15 15:33:33 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Dec 2014 15:33:33 -0000 Subject: [GHC] #9169: Add mkWeakTMVar to Control.Concurrent.STM.TMVar In-Reply-To: <049.23b37a7a3374245a7e82fd5db3c1a49c@haskell.org> References: <049.23b37a7a3374245a7e82fd5db3c1a49c@haskell.org> Message-ID: <064.fb3e86d28590097877005c4080f3939e@haskell.org> #9169: Add mkWeakTMVar to Control.Concurrent.STM.TMVar -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: thoughtpolice Type: feature | Status: upstream request | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Core | Keywords: stm Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"8afdf274194e77e85e6a08dc4963022c56fc29d8/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="8afdf274194e77e85e6a08dc4963022c56fc29d8" stm: update submodule for #9169 addition Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 15 15:33:55 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Dec 2014 15:33:55 -0000 Subject: [GHC] #9169: Add mkWeakTMVar to Control.Concurrent.STM.TMVar In-Reply-To: <049.23b37a7a3374245a7e82fd5db3c1a49c@haskell.org> References: <049.23b37a7a3374245a7e82fd5db3c1a49c@haskell.org> Message-ID: <064.53c0f45186db5589a7cfd08958eb04cb@haskell.org> #9169: Add mkWeakTMVar to Control.Concurrent.STM.TMVar -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: thoughtpolice Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Core | Keywords: stm Libraries | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: upstream => closed * resolution: => fixed Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 15 16:09:45 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Dec 2014 16:09:45 -0000 Subject: [GHC] #9316: GHC 7.8.3 no longer infers correct type in presence of type families and constraints In-Reply-To: <047.3e08ece466a818f844fb33b47be1c8dd@haskell.org> References: <047.3e08ece466a818f844fb33b47be1c8dd@haskell.org> Message-ID: <062.e79fb460f69d4e94681687fb85256b27@haskell.org> #9316: GHC 7.8.3 no longer infers correct type in presence of type families and constraints -------------------------------------+------------------------------------- Reporter: ocharles | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: 7.10.1 => 7.8.4 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 15 16:10:14 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Dec 2014 16:10:14 -0000 Subject: [GHC] #9132: takeWhile&C. still not fusible In-Reply-To: <051.252bf456ce6fe936293a4484081567fb@haskell.org> References: <051.252bf456ce6fe936293a4484081567fb@haskell.org> Message-ID: <066.afee5816ca6fc86e22cd6c8c841f38fd@haskell.org> #9132: takeWhile&C. still not fusible -------------------------------------+------------------------------------- Reporter: | Owner: skeuchel Blaisorblade | Status: closed Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.8.3 Component: Core | Keywords: fusion Libraries | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Moderate (less Operating System: | than a day) Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: #9537 performance bug | Test Case: | Blocking: | Differential Revisions: Phab:D322 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 15 16:34:01 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Dec 2014 16:34:01 -0000 Subject: [GHC] #9353: prefetch primops are not currently useful In-Reply-To: <050.df9431cf6a5e94b42f1021289c874b34@haskell.org> References: <050.df9431cf6a5e94b42f1021289c874b34@haskell.org> Message-ID: <065.ba1047b55c90d190fe1122d0d04102f8@haskell.org> #9353: prefetch primops are not currently useful -------------------------------------+------------------------------------- Reporter: | Owner: MikeIzbicki | Status: new Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: D350 | -------------------------------------+------------------------------------- Comment (by carter): its my fault partly too, that PR was originally going to be for the seq like interface, but then I realized how much more complicated that would be and moved to the state# based one -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 15 16:34:02 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Dec 2014 16:34:02 -0000 Subject: [GHC] #9857: GHC 7.9 panics (simplifier ticks exhausted) on `half-0.2` In-Reply-To: <042.3b1974ccb36d315c778a524393b08ca5@haskell.org> References: <042.3b1974ccb36d315c778a524393b08ca5@haskell.org> Message-ID: <057.5475d418cf938d1644c81404b40deb83@haskell.org> #9857: GHC 7.9 panics (simplifier ticks exhausted) on `half-0.2` -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by hvr): Supposedly fixed via fbb42b2ea42b6467135f26db47d9c296e7ad75a3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 15 16:34:15 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Dec 2014 16:34:15 -0000 Subject: [GHC] #9857: GHC 7.9 panics (simplifier ticks exhausted) on `half-0.2` In-Reply-To: <042.3b1974ccb36d315c778a524393b08ca5@haskell.org> References: <042.3b1974ccb36d315c778a524393b08ca5@haskell.org> Message-ID: <057.9c103d364a183ea56d0ca466b58fc197@haskell.org> #9857: GHC 7.9 panics (simplifier ticks exhausted) on `half-0.2` -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Fixed by this (whose commit message contains a mis-typed ticket number) {{{ commit fbb42b2ea42b6467135f26db47d9c296e7ad75a3 Author: Simon Peyton Jones Date: Sat Dec 13 22:47:01 2014 +0000 Pattern-synonym matcher and builder Ids must be *LocalIds* This easy-to-make mistake meant that pattern-synonym matcher and builder Ids weren't being treated as locally defined by the simpplier. That meant that we never looked up them up in the environment, got an out-of-date unfolding, which made the Simplifier fall into an infinite loop. This was the cause of Trac #98587, but it was quite tricky to find! In a separate patch I'll make Lint check for locally-bound GlobalIds, since they are always an error. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 15 16:53:34 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Dec 2014 16:53:34 -0000 Subject: [GHC] #9353: prefetch primops are not currently useful In-Reply-To: <050.df9431cf6a5e94b42f1021289c874b34@haskell.org> References: <050.df9431cf6a5e94b42f1021289c874b34@haskell.org> Message-ID: <065.2104a64335f0f7605798327b7bebd617@haskell.org> #9353: prefetch primops are not currently useful -------------------------------------+------------------------------------- Reporter: | Owner: MikeIzbicki | Status: new Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: D350 | -------------------------------------+------------------------------------- Comment (by carter): to clarify: i think the seq style api is still the right path for the future, or at least should be explored eventually. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 15 17:07:58 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Dec 2014 17:07:58 -0000 Subject: [GHC] #9882: Kind mismatch with singleton [Nat] In-Reply-To: <052.5a45a6dd72a21fd100bb8463ecce1207@haskell.org> References: <052.5a45a6dd72a21fd100bb8463ecce1207@haskell.org> Message-ID: <067.2d8f712d9886a9cc2d00ad0291c8e54e@haskell.org> #9882: Kind mismatch with singleton [Nat] -------------------------------------+------------------------------------- Reporter: Roel van | Owner: Dijk | Status: closed Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: invalid | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"a972bddfc8115d80d774383a55202a293dc68595/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a972bddfc8115d80d774383a55202a293dc68595" Improve documentation of syntax for promoted lists THe documentation in 7.9.4 of promoted list and tuple types was misleading, which led to Trac #9882. This patch makes explicit that only type-level with two or more elements can have the quote omitted. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 15 17:15:00 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Dec 2014 17:15:00 -0000 Subject: [GHC] #9883: Make OverloadedLists more usable by splitting the class interface In-Reply-To: <046.2f0f8d78805e972b7bee3e325045a73c@haskell.org> References: <046.2f0f8d78805e972b7bee3e325045a73c@haskell.org> Message-ID: <061.59dd974ae2ac9c9b49b929b00d10e93e@haskell.org> #9883: Make OverloadedLists more usable by splitting the class interface -------------------------------------+------------------------------------- Reporter: muesli4 | Owner: Type: feature | Status: closed request | Milestone: ? Priority: normal | Version: 7.8.3 Component: External | Keywords: overloaded lists, Core | islist Resolution: duplicate | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: | Blocked By: 7495 None/Unknown | Related Tickets: #7495 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm far from sure that it's a dup of #7495, so I'm reopening. This ticket has a clear proposal; #7495 does not. By all means go ahead and forge a consensus about this ticket. I wonder if `IsList` could be a superclass of `AsList`? That is, do you want to be able to pattern-match on a list-like thing, but not be able to use literals for that type? Or are they best considered as orthogonal? The nomenclature clearly needs fixing! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 15 17:17:50 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Dec 2014 17:17:50 -0000 Subject: [GHC] #9883: Make OverloadedLists more usable by splitting the class interface In-Reply-To: <046.2f0f8d78805e972b7bee3e325045a73c@haskell.org> References: <046.2f0f8d78805e972b7bee3e325045a73c@haskell.org> Message-ID: <061.0c1a4e553a82b880bd449b8f2c8a3c81@haskell.org> #9883: Make OverloadedLists more usable by splitting the class interface -------------------------------------+------------------------------------- Reporter: muesli4 | Owner: Type: feature | Status: new request | Milestone: ? Priority: normal | Version: 7.8.3 Component: External | Keywords: overloaded lists, Core | islist Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: | Blocked By: 7495 None/Unknown | Related Tickets: #7495 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: closed => new * resolution: duplicate => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 15 17:23:11 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Dec 2014 17:23:11 -0000 Subject: [GHC] #9857: GHC 7.9 panics (simplifier ticks exhausted) on `half-0.2` In-Reply-To: <042.3b1974ccb36d315c778a524393b08ca5@haskell.org> References: <042.3b1974ccb36d315c778a524393b08ca5@haskell.org> Message-ID: <057.94bcf7768085719efb2787f3e3bd61ff@haskell.org> #9857: GHC 7.9 panics (simplifier ticks exhausted) on `half-0.2` -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: closed Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | patsyn/should_compile/T9857 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => patsyn/should_compile/T9857 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 15 17:39:48 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Dec 2014 17:39:48 -0000 Subject: [GHC] #9882: Kind mismatch with singleton [Nat] In-Reply-To: <052.5a45a6dd72a21fd100bb8463ecce1207@haskell.org> References: <052.5a45a6dd72a21fd100bb8463ecce1207@haskell.org> Message-ID: <067.1acbf3082bea9f3a98c4ddf707b7a71f@haskell.org> #9882: Kind mismatch with singleton [Nat] -------------------------------------+------------------------------------- Reporter: Roel van | Owner: Dijk | Status: closed Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: invalid | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"a3e6915431f93ebc0aaee22b7b9f118bffb01cae/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a3e6915431f93ebc0aaee22b7b9f118bffb01cae" Wibbles to documentation for promoted lists and tuples (Trac #9882) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 15 19:56:11 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Dec 2014 19:56:11 -0000 Subject: [GHC] #9883: Make OverloadedLists more usable by splitting the class interface In-Reply-To: <046.2f0f8d78805e972b7bee3e325045a73c@haskell.org> References: <046.2f0f8d78805e972b7bee3e325045a73c@haskell.org> Message-ID: <061.ad29bdee0235be46c76158e69887bfab@haskell.org> #9883: Make OverloadedLists more usable by splitting the class interface -------------------------------------+------------------------------------- Reporter: muesli4 | Owner: Type: feature | Status: new request | Milestone: ? Priority: normal | Version: 7.8.3 Component: External | Keywords: overloaded lists, Core | islist Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: | Blocked By: 7495 None/Unknown | Related Tickets: #7495 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by muesli4): Replying to [comment:3 simonpj]: > I'm far from sure that it's a dup of #7495, so I'm reopening. This ticket has a clear proposal; #7495 does not. I'm not sure either. I was trying to get a discussion running about this, since I'm not that much experienced in Haskell (at least I haven't written an extension), which does not mean I'm not interested in working on GHC. :) > By all means go ahead and forge a consensus about this ticket. > > I wonder if `IsList` could be a superclass of `AsList`? It could and it would even remove the redundant element type definition. My first intent was, to decouple the ''literal''-functionality from the rest. That's also a point I don't like about the {{{Num}}} class, instead of using {{{Num}}}, one could provide the ''literal''-functionality with a {{{NumLit}}} class, which then in turn could be a super class of {{{Num}}}. But I'm not sure whether I'm keeping track of everything it affects, so feel free to correct me. > That is, do you want to be able to pattern-match on a list-like thing, but not be able to use literals for that type? It could make sense, though I admit probably not often. > Or are they best considered as orthogonal? Aren't they already orthogonal semantically in the OverloadedLists extension? I would keep them split, if someone needs both, he or she can use both. > The nomenclature clearly needs fixing! How about this (I added the {{{ListView}}} class only because I thought it sounded exactly how it should be.): {{{ {-# LANGUAGE TypeFamilies #-} type family ListViewItem :: * -> * -- From ListLiteral class ListLit l where fromList :: [ListViewItem l] -> l fromListN :: Int -> [ListViewItem l] -> l -- From ListConvertible class ListConv l where -- Name could conflict with Data.Foldable.toList toList :: l -> [ListViewItem l] -- From ListViewable, since we provide a view into something utilizing a list. -- FIXME Better use some kind of type class alias here! class (ListLit l, ListConv l) => ListView l where }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 15 20:37:29 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Dec 2014 20:37:29 -0000 Subject: [GHC] #9880: ghc crashes on th splices in instance context In-Reply-To: <048.f4daf5bbce32dd24217721fc99cc931b@haskell.org> References: <048.f4daf5bbce32dd24217721fc99cc931b@haskell.org> Message-ID: <063.4c27bcf56173161e490db3fe0f9d718a@haskell.org> #9880: ghc crashes on th splices in instance context -------------------------------------+------------------------------------- Reporter: Philonous | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): The behavior you see -- that error -- is what I'd expect. I had a brief go at implementing local declaration splices but soon realized that implementing this involves quite a bit of replumbing. The splices would have to break up mutually-recursive groups within class, instance, and `let` declarations, and that would require changes to several bits of HsSyn. So, I settled for just fixing the panic and waiting for someone to scream loudly that they need this feature. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 15 20:49:13 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Dec 2014 20:49:13 -0000 Subject: [GHC] #9123: Need for higher kinded roles In-Reply-To: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> References: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> Message-ID: <061.1873de5cf1b452b50c82f4482a2d21c7@haskell.org> #9123: Need for higher kinded roles -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Project (more Type of failure: | than a week) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): At the nub of this is the following observation. If a function has type {{{ forall m. (forall a b. Coercible a b => Coercible (m a) (m b)) => ...blah... }}} then that, in effect, restricts `m` to type constructors whose first argument has nominal role -- exactly the problem posed in the Description of this ticket. Very good observation. But the inferred context for `deriving` clauses is deliberately restricted. If you say {{{ newtype T m a = MkT (m a) deriving( C ) }}} (again from the Description) GHC will insist on a simple context, i.e. a class applied to type variables. You want to ''infer'' a rather complicated context. I don't know how to do that. You could perhaps ''declare'' it like this, using "standalone deriving" {{{ deriving instance (C m, forall a. Coercible a b => Coercible (m a) (m b)) => C (T m) }}} but GHC users might not be so happy with that whenever they say `deriving( Monad )`. Or perhaps {{{ type RepArg1 m = forall a b. (Coercible a b => Coercible (m a) (m b)) deriving instance (C m, RepArg1 m) => C (T m) }}} And now we are close to [wiki:Roles2]. (But we still don't have `deriving( Monad )` unannotated. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 15 20:56:22 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Dec 2014 20:56:22 -0000 Subject: [GHC] #2256: Incompleteness of type inference: must quantify over implication constraints In-Reply-To: <046.2c6c7c4440a32ff5fbe5ad1f48bf6276@haskell.org> References: <046.2c6c7c4440a32ff5fbe5ad1f48bf6276@haskell.org> Message-ID: <061.91bde0dc5366a1c03bdbacd8fcc5cb50@haskell.org> #2256: Incompleteness of type inference: must quantify over implication constraints -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: lowest | Milestone: 7.10.1 Component: Compiler | Version: 6.8.2 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): I agree that much of this is not hard. And it's certainly useful. Indeed it is explicitly discussed in our Haskell Workshop 2000 paper [http://research.microsoft.com/en-us/um/people/simonpj/papers/derive.htm Derivable Type Classes]. The issues I see are: * Inference. If users can write such instances, they will probably expect them to be inferred. But that may wrongly defer a type error from a function to its call sites, by inferring an implication which is actually unsatisfiable. * Completeness. "Given" constraints interact with each other. How do "given" implications interact with simple "givens"? * Impredicativity. Can a constraint variable `c` be instantiated with one of these implications? Perhaps it's just a question of ruling that out. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 15 20:56:59 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Dec 2014 20:56:59 -0000 Subject: [GHC] #9880: ghc crashes on th splices in instance context In-Reply-To: <048.f4daf5bbce32dd24217721fc99cc931b@haskell.org> References: <048.f4daf5bbce32dd24217721fc99cc931b@haskell.org> Message-ID: <063.f8a608c71239092d30ebd43553e9a6ac@haskell.org> #9880: ghc crashes on th splices in instance context -------------------------------------+------------------------------------- Reporter: Philonous | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Is this behaviour documented in the user manual? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 15 21:56:43 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Dec 2014 21:56:43 -0000 Subject: [GHC] #8024: Dynamic linking not working on PowerPC Linux. In-Reply-To: <044.9ac099edab3e89a81000a0e47392a6e5@haskell.org> References: <044.9ac099edab3e89a81000a0e47392a6e5@haskell.org> Message-ID: <059.d5dc9fe58b9bdef85947fbdd009f1494@haskell.org> #8024: Dynamic linking not working on PowerPC Linux. ----------------------------------------------+--------------------------- Reporter: erikd | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: D560 | ----------------------------------------------+--------------------------- Changes (by slyfox): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 15 21:57:19 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Dec 2014 21:57:19 -0000 Subject: [GHC] #9831: the 'impossible' happened : iselExpr64(powerpc) In-Reply-To: <044.1090bf2d6b74a28254c5352399819de1@haskell.org> References: <044.1090bf2d6b74a28254c5352399819de1@haskell.org> Message-ID: <059.eb6b595bc7e8f556273de61dedb8f38c@haskell.org> #9831: the 'impossible' happened : iselExpr64(powerpc) ----------------------------------------------+--------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.9 Resolution: fixed | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: Phab:D560 | ----------------------------------------------+--------------------------- Changes (by slyfox): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 15 22:21:21 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Dec 2014 22:21:21 -0000 Subject: [GHC] #9873: Use CONF_GCC_LINKER_OPTS_STAGE2 only in stage2 In-Reply-To: <046.77f53bab4b42e7b7f0531b045d80ca9c@haskell.org> References: <046.77f53bab4b42e7b7f0531b045d80ca9c@haskell.org> Message-ID: <061.8f570b01169061074bba026ed48d87ea@haskell.org> #9873: Use CONF_GCC_LINKER_OPTS_STAGE2 only in stage2 -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.9 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by erikd): It fails the first time it tries to run an executable generated by the stage1 compiler. During some earlier testing I had disabled compiling the `dyn` way, so the first failure was with the `inplace/bin/ghc-stage2` binary. If I re-enable the `dyn` way, the first failure is when the build tries to run `inplace/bin/dll-split`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 15 22:29:48 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Dec 2014 22:29:48 -0000 Subject: [GHC] #9049: Expose srcLoc from the assertion architecture to allow better error messages In-Reply-To: <042.a0d4c757be085a0284ebca147547b4f3@haskell.org> References: <042.a0d4c757be085a0284ebca147547b4f3@haskell.org> Message-ID: <057.53a9c6510613559580c679a63822be6e@haskell.org> #9049: Expose srcLoc from the assertion architecture to allow better error messages -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonmar): Simon PJ: you asked what I thought about ImplicitLocations, see comment:8 above. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 15 22:31:55 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Dec 2014 22:31:55 -0000 Subject: [GHC] #9873: Use CONF_GCC_LINKER_OPTS_STAGE2 only in stage2 In-Reply-To: <046.77f53bab4b42e7b7f0531b045d80ca9c@haskell.org> References: <046.77f53bab4b42e7b7f0531b045d80ca9c@haskell.org> Message-ID: <061.67176b3025e1d0e7e4727d9c51f804b9@haskell.org> #9873: Use CONF_GCC_LINKER_OPTS_STAGE2 only in stage2 -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.9 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nomeata): Without a build logs, it?s hard to help here. Any please open a new ticket or discuss it on ghc-dev, this on is about a deficiency in the build system. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 15 23:18:59 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Dec 2014 23:18:59 -0000 Subject: [GHC] #9888: Inconsistent type family resolution Message-ID: <047.9b85d7d0596e6f9647f234cd7e0a9de4@haskell.org> #9888: Inconsistent type family resolution -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: GHC Blocked By: | rejects valid program Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- This is as small as I'm able to make the example. It uses the [http://hackage.haskell.org/package/singletons singletons] library. If I write my own `Map` type family, I can get the code to work. However, there seems to be a problem in GHC since I get seemingly conflicting information in GHCi. {{{#!hs {-# LANGUAGE TypeFamilies, TypeOperators, DataKinds, FlexibleContexts, UndecidableInstances #-} module Foo where import Data.Singletons.Prelude hiding (And) -- if every type in the list is equal, `CommonElt` returns the common type type family CommonElt xs where CommonElt (x ': xs) = EqResult (And (Map ((TyCon2 (==)) $ x) xs)) x type family a == b where a == a = 'True a == b = 'False type family And xs where And '[] = 'True And ('False ': xs) = 'False And ('True ': xs) = And xs -- converts a True result to a type type family EqResult b v where EqResult 'True r = r type R = CommonElt '[Int, Int] f :: R f = 3 }}} This code does not compile: {{{ Foo.hs:30:5: No instance for (Num (EqResult (And ((Int == Int) :$$$ '[])) Int)) arising from the literal ?3? In the expression: 3 In an equation for ?f?: f = 3 Failed, modules loaded: none. }}} But if I comment out `f` and load the rest of the file in GHCi, I can easily see that `R ~ Int`: {{{ > :kind! R R :: * = Int }}} This seems suspicious to me because GHCi can resolve the type of `R`, but when code requiring `R` to be resolved is compiled (in GHCi or with GHC), I get the error above. I believe that `:kind!` is correctly resolving the type to `Int`, and that the type error is a bug. This is documented in more detail at [http://stackoverflow.com/questions/27490352/type-family-shenanigans-in- ghci this StackOverflow post]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 16 01:44:05 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Dec 2014 01:44:05 -0000 Subject: [GHC] #2256: Incompleteness of type inference: must quantify over implication constraints In-Reply-To: <046.2c6c7c4440a32ff5fbe5ad1f48bf6276@haskell.org> References: <046.2c6c7c4440a32ff5fbe5ad1f48bf6276@haskell.org> Message-ID: <061.9fdaafab752bf9e599a72adf99865138@haskell.org> #2256: Incompleteness of type inference: must quantify over implication constraints -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: lowest | Milestone: 7.10.1 Component: Compiler | Version: 6.8.2 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): * Inference: We don't. Just like we don't infer higher-rank types (which, of course, are the same as implication constraints). If a user wants this feature, they have to ask for it. * Completeness: This is thornier. Here is how I see a problem arising: {{{ class C a class D a instance D Int needsD :: D a => a -> () implic :: (forall a. C a => D a) -> () implic = needsD (5 :: Int) }}} When typechecking `implic`, the local universal dictionary for `D a` will be used to provide a dictionary to `needsD`. This will then generate an unsatisfiable wanted `C Int`. But, of course, we could have just used the global instance `D Int` instead. An issue such as this one can't arise today (even with local dictionaries shadowing global ones) because local dictionaries never give rise to new wanteds. If you have a local dictionary, it's good to use. Given/Given interactions would be the same. If one implication-Given can be used in an interaction, it would be, giving rise to its antecedent Wanted constraints. This does get me a little worried about nondeterminism. But, I conjecture that if this interaction can give rise to nondeterminism, then it would be possible to exhibit the nondeterminism today, using overlapping instances. So, it all comes down to specifying completeness against what spec, and I'm saying that we could be complete against a spec where every local constraint shadows every overlapped global one. That is, when `(forall a. C a => D a)` is in scope, `instance D Int` is not. Will this be easy enough to use to make it practicable? There will be some surprises around it, but I think it's all quite easy to digest with a little guidance. (Certainly easier to understand than closed type families!) * Impredicativity: This, to me, is just like the story in kind `*`. `c` should be forbidden from unifying with an implication constraint. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 16 01:46:47 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Dec 2014 01:46:47 -0000 Subject: [GHC] #9880: ghc crashes on th splices in instance context In-Reply-To: <048.f4daf5bbce32dd24217721fc99cc931b@haskell.org> References: <048.f4daf5bbce32dd24217721fc99cc931b@haskell.org> Message-ID: <063.8a1305eb0f8593bc43284265e7a2608c@haskell.org> #9880: ghc crashes on th splices in instance context -------------------------------------+------------------------------------- Reporter: Philonous | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): Doesn't seem to be. I'll fix that shortly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 16 01:56:41 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Dec 2014 01:56:41 -0000 Subject: [GHC] #9888: Inconsistent type family resolution In-Reply-To: <047.9b85d7d0596e6f9647f234cd7e0a9de4@haskell.org> References: <047.9b85d7d0596e6f9647f234cd7e0a9de4@haskell.org> Message-ID: <062.fc012d4a0a37200e197d97e8732d0c09@haskell.org> #9888: Inconsistent type family resolution -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: duplicate | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => duplicate Comment: This looks like a duplicate of #9433. You've used `(==)` unapplied in your code, which is against the rules. It should be a syntax error, but instead, GHC attempts to make progress and falls flat on its face. Instead of `(TyCon2 (==))` in that spot, try `(:==$)`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 16 02:10:59 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Dec 2014 02:10:59 -0000 Subject: [GHC] #9123: Need for higher kinded roles In-Reply-To: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> References: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> Message-ID: <061.87bf9020939fdc1bf213341ac131a29f@haskell.org> #9123: Need for higher kinded roles -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Project (more Type of failure: | than a week) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:30 simonpj]: > You want to ''infer'' a rather complicated context. I don't know how to do that. Sure you do! Currently, the code in !TcDeriv instructs the solver to try to reduce certain constraints. This reduction results in an unsolved implication constraint -- exactly the one we need to quantify over. The !TcDeriv code, at this point, extracts out the flat (er... now called ''simple'') constraints, checks to see if they're exotic, and then reports an error if there are any exotic simple constraints or if there are any leftover implication constraints. Currently, there's a leftover implication, and so we report an error. If, instead, we quantified over the leftover implication, we'd be done, with an inferred implication constraint. A separate question is whether or not this is desirable from a user's standpoint. `deriving` quite rightly restricts what it will quantify over. And implication constraints seem quite exotic. We could, though, say that implication constraints aren't exotic. Or, we could bake in the particular implication constraint `(forall a b. Coercible a b => Coercible (m a) (m b))`, recognize that, rewrite it to use Simon's type synonym `RepArg1 m`, and then it doesn't seem so exotic after all. That's terribly hacky, but it just might be useful enough to do. Or, we could punt and require users to write the constraint when they want it -- the error message will give them guidance. I don't have a strong opinion in any direction here. It is worth noting that, if `join :: m (m a) -> m a` is in `Monad`, most GNDs of `Monad` would work today. The ones that trip up are when the newtype wraps a monad transformer. That's a common-enough case that we don't want to make it impossible, but a rare enough case that I'm OK with making it annoying, if we can't do better. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 16 02:11:29 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Dec 2014 02:11:29 -0000 Subject: [GHC] #9888: Inconsistent type family resolution In-Reply-To: <047.9b85d7d0596e6f9647f234cd7e0a9de4@haskell.org> References: <047.9b85d7d0596e6f9647f234cd7e0a9de4@haskell.org> Message-ID: <062.afeca090040c99412ff027bd66069c48@haskell.org> #9888: Inconsistent type family resolution -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: duplicate | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by crockeea): I get the same error using `(:==$)`: {{{#!hs type family CommonElt xs where CommonElt (x ': xs) = EqResult (And (Map ((:==$) $ x) xs)) x }}} but I think that is related to a `singletons` [https://github.com/goldfirere/singletons/issues/100 ticket] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 16 02:51:20 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Dec 2014 02:51:20 -0000 Subject: [GHC] #9889: Pattern synonym does not work at top level Message-ID: <047.fe6568ce87d5703b3811c455881d3231@haskell.org> #9889: Pattern synonym does not work at top level -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: PatternSynonyms | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- When I say {{{ pattern Id x = x Id x = True }}} I get {{{ Not in scope: data constructor ?Id? }}} This happens with both 7.8.3 and HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 16 02:57:04 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Dec 2014 02:57:04 -0000 Subject: [GHC] #9883: Make OverloadedLists more usable by splitting the class interface In-Reply-To: <046.2f0f8d78805e972b7bee3e325045a73c@haskell.org> References: <046.2f0f8d78805e972b7bee3e325045a73c@haskell.org> Message-ID: <061.97a34d2df50e363934f59f714f1bd6da@haskell.org> #9883: Make OverloadedLists more usable by splitting the class interface -------------------------------------+------------------------------------- Reporter: muesli4 | Owner: Type: feature | Status: new request | Milestone: ? Priority: normal | Version: 7.8.3 Component: External | Keywords: overloaded lists, Core | islist Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: | Blocked By: 7495 None/Unknown | Related Tickets: #7495 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): Maybe I'm missing something basic, but why do we need classes at all here? I propose we just desugar the list to use some functions in scope, and if they don't type-check, that's the programmer's problem. Concretely, here are the 7 expression forms from OverloadedLists, and my proposal for what they desugar to: {{{ [] -- buildList 0 (listStart `listSep` listEnd) [x] -- buildList 1 (listStart `listSep` x `listSep` listEnd) [x,y,z] -- buildList 3 (listStart `listSep` x `listSep` y `listSep` z `listSep` listEnd) [x .. ] -- enumFrom x [x,y ..] -- enumFromThen x y [x .. y] -- enumFromTo x y [x,y .. z] -- enumFromThenTo x y z }}} The `enumXXX` functions would use whatever is in scope -- not necessarily the methods from `Enum`. For regular old lists, we get {{{ buildList _ (_:elts) = elts listStart = undefined listSep = (:) infixr 5 `listSep` listEnd = [] }}} and the `enumXXX` functions are indeed taken from the `Enum` class. Note that I included the fixity declaration for `listSep` above -- there's no reason to disallow a ''left''-associative separator. (Though, all the elements in the list would effectively be wrapped in parentheses; the precedence level of the `listSep` fixity declaration is meaningless in the desugaring.) To me, this seems maximally flexible. With pattern synonyms, we could mimc this behavior in patterns. {{{ [] -- MatchList 0 (ListStart `ListSep` ListEnd) [x] -- MatchList 1 (ListStart `ListSep` x `ListSep` ListEnd) [x,y,z] -- MatchList 3 (ListStart `ListSep` x `ListSep` y `ListSep` z `ListSep` ListEnd) }}} For regular old lists, we get {{{ pattern MatchList n l <- ((\list -> (length list, undefined:list)) -> (n, l)) pattern ListStart <- _ pattern ListSep h t = h : t infixr 5 `ListSep` pattern ListEnd = [] }}} The construction for `MatchList` is painful. Improvements here are welcome. Sorry, @muesli4, I didn't mean to steal your thunder here! I hope you don't mind the debate. :) Thoughts (anyone) on this alternative? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 16 03:17:14 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Dec 2014 03:17:14 -0000 Subject: [GHC] #9883: Make OverloadedLists more usable by splitting the class interface In-Reply-To: <046.2f0f8d78805e972b7bee3e325045a73c@haskell.org> References: <046.2f0f8d78805e972b7bee3e325045a73c@haskell.org> Message-ID: <061.6d3bcbc72c264c8b1859391ce269c792@haskell.org> #9883: Make OverloadedLists more usable by splitting the class interface -------------------------------------+------------------------------------- Reporter: muesli4 | Owner: Type: feature | Status: new request | Milestone: ? Priority: normal | Version: 7.8.3 Component: External | Keywords: overloaded lists, Core | islist Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: | Blocked By: 7495 None/Unknown | Related Tickets: #7495 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): that might work, even for some of my really generic ideas over here https://github.com/cartazio/HetList/blob/master/HetList.hs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 16 03:18:24 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Dec 2014 03:18:24 -0000 Subject: [GHC] #9883: Make OverloadedLists more usable by splitting the class interface In-Reply-To: <046.2f0f8d78805e972b7bee3e325045a73c@haskell.org> References: <046.2f0f8d78805e972b7bee3e325045a73c@haskell.org> Message-ID: <061.75e56a8711cdb25a7b5b5ee4fef8fc0b@haskell.org> #9883: Make OverloadedLists more usable by splitting the class interface -------------------------------------+------------------------------------- Reporter: muesli4 | Owner: Type: feature | Status: new request | Milestone: ? Priority: normal | Version: 7.8.3 Component: External | Keywords: overloaded lists, Core | islist Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: | Blocked By: 7495 None/Unknown | Related Tickets: #7495 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): i'm not sure if the pattern synonyms trick works for Hlist / HRecord style constructions but i'll have to think about it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 16 07:10:07 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Dec 2014 07:10:07 -0000 Subject: [GHC] #9049: Expose srcLoc from the assertion architecture to allow better error messages In-Reply-To: <042.a0d4c757be085a0284ebca147547b4f3@haskell.org> References: <042.a0d4c757be085a0284ebca147547b4f3@haskell.org> Message-ID: <057.8e4251cbc91bdc4a7cb9a2ddb12073ad@haskell.org> #9049: Expose srcLoc from the assertion architecture to allow better error messages -------------------------------------+------------------------------------- Reporter: nh2 | Owner: gridaphobe Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by gridaphobe): * owner: => gridaphobe Comment: I'm starting to work on implementing wiki:ExplicitCallStack/ImplicitLocations. If anyone else has been working on it, please let me know so I don't unnecessarily duplicate work :) simonmar: I agree that the changes to base should be kept to a minimum, at least initially. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 16 08:41:14 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Dec 2014 08:41:14 -0000 Subject: [GHC] #9049: Expose srcLoc from the assertion architecture to allow better error messages In-Reply-To: <042.a0d4c757be085a0284ebca147547b4f3@haskell.org> References: <042.a0d4c757be085a0284ebca147547b4f3@haskell.org> Message-ID: <057.d18ffcf373ddeb75a418f71be6ce12a2@haskell.org> #9049: Expose srcLoc from the assertion architecture to allow better error messages -------------------------------------+------------------------------------- Reporter: nh2 | Owner: gridaphobe Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): gridaphobe, rodlogic, are you willing to reveal your email identities? I'm having trouble connecting up email discussion with Trac personae! Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 16 09:20:04 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Dec 2014 09:20:04 -0000 Subject: [GHC] #9890: RTS -qa option is helpful but under-documented Message-ID: <049.126a2e59b04d15cfa71935d2118594d3@haskell.org> #9890: RTS -qa option is helpful but under-documented -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | Documentation bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The entire documentation for the RTS `-qa` option is Use the OS's affinity facilities to try to pin OS threads to CPU cores. This is an experimental feature, and may or may not be useful. Please let us know whether it helps for you! It does help for us: enabling it on a multithreaded, moderately GC-heavy web server led to a sizeable improvement (~20%) in throughput benchmarks. However, it would be nice if the GHC documentation was a little more descriptive about what exactly this option does and how experimental it is now considered! (Relatedly, perhaps it would be worth adding a single index of RTS options in the user's guide, much like the flag reference for GHC itself.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 16 10:46:00 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Dec 2014 10:46:00 -0000 Subject: [GHC] #9049: Expose srcLoc from the assertion architecture to allow better error messages In-Reply-To: <042.a0d4c757be085a0284ebca147547b4f3@haskell.org> References: <042.a0d4c757be085a0284ebca147547b4f3@haskell.org> Message-ID: <057.4389e9bda1c3a08261b134912416f320@haskell.org> #9049: Expose srcLoc from the assertion architecture to allow better error messages -------------------------------------+------------------------------------- Reporter: nh2 | Owner: gridaphobe Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by gridaphobe): simonpj: This is Eric Seidel (eric at seidel.io). I've told trac my name and email, but it doesn't seem to expose them to others! I'd be happy to tick a "make my name+email public" box if there's one I'm missing somewhere. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 16 11:42:57 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Dec 2014 11:42:57 -0000 Subject: [GHC] #9890: RTS -qa option is helpful but under-documented In-Reply-To: <049.126a2e59b04d15cfa71935d2118594d3@haskell.org> References: <049.126a2e59b04d15cfa71935d2118594d3@haskell.org> Message-ID: <064.ed02db009edbcb84cad33e13bd3dacc0@haskell.org> #9890: RTS -qa option is helpful but under-documented -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: simonmar Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime | Version: 7.8.3 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: Documentation bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonmar): * owner: => simonmar * milestone: => 7.10.1 Comment: I'll improve the docs here. It's still experimental in the sense that you should experiment with it and see if it helps :) Thanks for the feedback. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 16 12:05:30 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Dec 2014 12:05:30 -0000 Subject: [GHC] #9049: Expose srcLoc from the assertion architecture to allow better error messages In-Reply-To: <042.a0d4c757be085a0284ebca147547b4f3@haskell.org> References: <042.a0d4c757be085a0284ebca147547b4f3@haskell.org> Message-ID: <057.aa10040af5b7fd4c2aa714cdaa94e90d@haskell.org> #9049: Expose srcLoc from the assertion architecture to allow better error messages -------------------------------------+------------------------------------- Reporter: nh2 | Owner: gridaphobe Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonmar): Let me elaborate a bit more on my concerns here. We currently have two imperfect ways to get a stack trace: profiling and the new -g in 7.10. This is another imperfect way, with different tradeoffs. In particular, you have to modify the source code to take advantage of it (not true of the other two ways). This is fine when it's your own program, but if implicit locations start to be used in common APIs then I'm not sure the extra clutter and user confusion is worth the benefit. It's also very hard to get rid of: APIs have greater longevity than compiler features. Specifically I'm concerned that 1. Users have three imperfect solutions to choose from, which is confusing. 2. Users will want either (a) `head` to have a implicit location, or (b) for there to be a new `headLocated` function that has an implicit location. Both are bad: (a) because head no longer matches the Prelude definition, and users will be confused, and (b) because there are two versions of head, and users will be confused. Moreover, this is a slippery slope: every package author be getting bug reports wanting implicit location versions of all their partial functions. Some users will like this, others will hate it. There will be no clear policy on what to do, and different libraries will adopt different strategies, leading to yet more confusion. 3. We have one more abstraction that must be eliminated by the simplifier to get reliable performance. People who are really concerned about performance will either avoid it, or use `#ifdef` to ensure that they don't have to worry about it. 4. It relies on a very little-used extension (implicit parameters) so those who want to understand what that strange `?location` means have to go and understand implicit parameters. Were it not for this we might be able to deprecate implicit parameters as a feature that didn't turn out to be that useful. Let's think very carefully before we start down this path. It's a really useful feature for end-user code, but the problems arise when we start using it in library APIs. I'd be perfectly OK with this feature (as I mentioned in my earlier comment) as long as it does not infect library APIs except for things that are explicitly undefined, like error, undefined, and so on. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 16 12:52:06 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Dec 2014 12:52:06 -0000 Subject: [GHC] #9883: Make OverloadedLists more usable by splitting the class interface In-Reply-To: <046.2f0f8d78805e972b7bee3e325045a73c@haskell.org> References: <046.2f0f8d78805e972b7bee3e325045a73c@haskell.org> Message-ID: <061.2a2000f908f47e83ad5c39423b7f7c5c@haskell.org> #9883: Make OverloadedLists more usable by splitting the class interface -------------------------------------+------------------------------------- Reporter: muesli4 | Owner: Type: feature | Status: new request | Milestone: ? Priority: normal | Version: 7.8.3 Component: External | Keywords: overloaded lists, Core | islist Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: | Blocked By: 7495 None/Unknown | Related Tickets: #7495 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by muesli4): Replying to [comment:6 goldfire]: > Maybe I'm missing something basic, but why do we need classes at all here? I propose we just desugar the list to use some functions in scope, and if they don't type-check, that's the programmer's problem. This sounds like something, which should be done with the RebindableSyntax extension. Type classes are useful, because other libraries can easily provide instances for it, without them you have to provide them via some third party library and it seems to me that other uses are more like a corner case. But of course I may be wrong, so I am all for usability and convenience, without excluding special cases (as I said, these could be introduced with the RebindableSyntax extension). > > Concretely, here are the 7 expression forms from OverloadedLists, and my proposal for what they desugar to: > > {{{ > [] -- buildList 0 (listStart `listSep` listEnd) > [x] -- buildList 1 (listStart `listSep` x `listSep` listEnd) > [x,y,z] -- buildList 3 (listStart `listSep` x `listSep` y `listSep` z `listSep` listEnd) > [x .. ] -- enumFrom x > [x,y ..] -- enumFromThen x y > [x .. y] -- enumFromTo x y > [x,y .. z] -- enumFromThenTo x y z > }}} > > The `enumXXX` functions would use whatever is in scope -- not necessarily the methods from `Enum`. > > For regular old lists, we get > > {{{ > buildList _ (_:elts) = elts > listStart = undefined > listSep = (:) > infixr 5 `listSep` > listEnd = [] > }}} > > and the `enumXXX` functions are indeed taken from the `Enum` class. > > Note that I included the fixity declaration for `listSep` above -- there's no reason to disallow a ''left''-associative separator. (Though, all the elements in the list would effectively be wrapped in parentheses; the precedence level of the `listSep` fixity declaration is meaningless in the desugaring.) I like what you could achieve with it, but I don't like how you do it: * The use of {{{undefined}}} seems like a hack to make the types work. * Can you provide some use cases where different associativity is an advantage? * I don't like to use operator syntax here. * Are you able to give definitions for these functions, such that we could use the list syntax for different types in the same module? Let's say heterogenous lists (was that the intention?) and normal lists. > To me, this seems maximally flexible. > > With pattern synonyms, we could mimc this behavior in patterns. > > {{{ > [] -- MatchList 0 (ListStart `ListSep` ListEnd) > [x] -- MatchList 1 (ListStart `ListSep` x `ListSep` ListEnd) > [x,y,z] -- MatchList 3 (ListStart `ListSep` x `ListSep` y `ListSep` z `ListSep` ListEnd) > }}} > > For regular old lists, we get > > {{{ > pattern MatchList n l <- ((\list -> (length list, undefined:list)) -> (n, l)) > pattern ListStart <- _ > pattern ListSep h t = h : t > infixr 5 `ListSep` > pattern ListEnd = [] > }}} > > The construction for `MatchList` is painful. Improvements here are welcome. Can you use different types with the same pattern? The compiler should know the length of the list, so maybe it can be expressed with a type literal (though I have no idea how to do that). > Sorry, @muesli4, I didn't mean to steal your thunder here! I hope you don't mind the debate. :) Of course, that was the reason I started the ticket. I appreciate your contribution, but I think it goes a bit over the top, my proposal was just a slight change in an already existing extension. And I don't know whether you can provide the same functionality, which currently exists. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 16 13:39:45 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Dec 2014 13:39:45 -0000 Subject: [GHC] #9883: Make OverloadedLists more usable by splitting the class interface In-Reply-To: <046.2f0f8d78805e972b7bee3e325045a73c@haskell.org> References: <046.2f0f8d78805e972b7bee3e325045a73c@haskell.org> Message-ID: <061.d56a8a3209abea0a70da272ada318cde@haskell.org> #9883: Make OverloadedLists more usable by splitting the class interface -------------------------------------+------------------------------------- Reporter: muesli4 | Owner: Type: feature | Status: new request | Milestone: ? Priority: normal | Version: 7.8.3 Component: External | Keywords: overloaded lists, Core | islist Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: | Blocked By: 7495 None/Unknown | Related Tickets: #7495 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Replying to [comment:6 goldfire]: > Maybe I'm missing something basic, but why do we need classes at all here? I propose we just desugar the list to use some functions in scope, and if they don't type-check, that's the programmer's problem. What if you wanted to use list syntax for two different types in the same module? You'd need two different `buildList` functions in scope. Aha! Type classes would solve that! What if you wanted to use list syntax for a type constructor that is as- yet abstract. Aha! Type classes can do that too. Maybe you are saying "if you want to use type classes, then just import a module that defines `buildList` in a class". And yes you could do that. But it's not the way ordinary list syntax or list comprehensions or monad do-notation work. There they desugar to some ''specific'' functions; and you use `-XRebindableSyntax` if you want instead to use "whatever is in scope". `-XOverloadedLists` works in a way consistent with that approach. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 16 13:42:03 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Dec 2014 13:42:03 -0000 Subject: [GHC] #2256: Incompleteness of type inference: must quantify over implication constraints In-Reply-To: <046.2c6c7c4440a32ff5fbe5ad1f48bf6276@haskell.org> References: <046.2c6c7c4440a32ff5fbe5ad1f48bf6276@haskell.org> Message-ID: <061.21c54e2cf5dc77c68767fa825b766018@haskell.org> #2256: Incompleteness of type inference: must quantify over implication constraints -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: lowest | Milestone: 7.10.1 Component: Compiler | Version: 6.8.2 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm not against it. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 16 13:46:14 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Dec 2014 13:46:14 -0000 Subject: [GHC] #9123: Need for higher kinded roles In-Reply-To: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> References: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> Message-ID: <061.daabce3ac5c872801cdfa0b853825726@haskell.org> #9123: Need for higher kinded roles -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Project (more Type of failure: | than a week) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Replying to [comment:31 goldfire]: > If, instead, we quantified over the leftover implication, we'd be done, with an inferred implication constraint. Not a good plan. I'm sure you can't be saying * Reject a constraint `C a Int` as "exotic" * Accept a constraint `forall a. C a Int` as fine When would an implication be "exotic"? I think it'd be much better to ask the user to use standalone deriving and write the constraint; but that's going to be jolly scary for users who just want `deriving( Monad )`. Your point that it only affects monad transformers is a good one though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 16 13:46:34 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Dec 2014 13:46:34 -0000 Subject: [GHC] #9889: Pattern synonym does not work at top level In-Reply-To: <047.fe6568ce87d5703b3811c455881d3231@haskell.org> References: <047.fe6568ce87d5703b3811c455881d3231@haskell.org> Message-ID: <062.fe78d701999c1edceaef2a691e92ab20@haskell.org> #9889: Pattern synonym does not work at top level -------------------------------------+------------------------------------- Reporter: goldfire | Owner: cactus Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: PatternSynonyms Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: => cactus Comment: Gergo: for you! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 16 15:07:52 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Dec 2014 15:07:52 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.87922ef4caac0a5deda8ee5c183880de@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Fuuzetsu Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Difficult (2-5 Type of failure: Other | days) Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Fuuzetsu): I certainly plan to investigate each of the cases mentioned in the description but if you have any specific source files you know are likely to change between compilation, I ask that you post them here: I spent quite a lot of time trying to come up with some while I'd rather be fixing the problem instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 16 17:09:37 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Dec 2014 17:09:37 -0000 Subject: [GHC] #9123: Need for higher kinded roles In-Reply-To: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> References: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> Message-ID: <061.c14c193f41d13a522dcfdd349ad2c441@haskell.org> #9123: Need for higher kinded roles -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Project (more Type of failure: | than a week) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:32 simonpj]: > I'm sure you can't be saying > * Reject a constraint `C a Int` as "exotic" > * Accept a constraint `forall a. C a Int` as fine Indeed, I was suggesting that implication constraints could be considered not exotic. Perhaps it would make the most sense to simply recur in the implication case, ruling out the example above, but accepting `(forall a b. Coercible a b => Coercible (m a) (m b))` (although I seem to recall that anything with a repeated variable is considered exotic). In any case, I have very little intuition as to how to set the exotic- checker and could be convinced to do just about anything. Here's a fresh approach to the problem: Don't rule out exotic contexts at all (subject to having the right language extensions on, as with all inferred types). Instead, issue a warning (on by default) when the context is exotic. The warning would exhort programmers to use standalone-deriving to suppress it. (Or, of course, there would be `-fno-warn-exotic-inferred- contexts`.) This should allow strictly more programs to type-check than today, so it's not a regression. And, as I understand it, the Haskell Report doesn't specify this end of the language, so we wouldn't be going against spec. With such a warning mechanism in place, I would favor a more stringent exotic-checker. With this warning behavior, `deriving (Monad)` would work (with `-XImplicationContexts`) and just issue a warning. (Without `-XImplicationContexts`, it would advise turning on `-XImplicationContexts`, of course!) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 17 02:01:09 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Dec 2014 02:01:09 -0000 Subject: [GHC] #8732: Global big object heap allocator lock causes contention In-Reply-To: <044.a362245e1caab544f39c02e92f1f1660@haskell.org> References: <044.a362245e1caab544f39c02e92f1f1660@haskell.org> Message-ID: <059.bf67ac250e74f1db046c125f1dadb28a@haskell.org> #8732: Global big object heap allocator lock causes contention -------------------------------------+------------------------------------- Reporter: tibbe | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime | Version: 7.6.3 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by ihameed): * cc: idhameed@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 17 02:12:16 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Dec 2014 02:12:16 -0000 Subject: [GHC] #8732: Global big object heap allocator lock causes contention In-Reply-To: <044.a362245e1caab544f39c02e92f1f1660@haskell.org> References: <044.a362245e1caab544f39c02e92f1f1660@haskell.org> Message-ID: <059.37d80e6833c3801447be4f0e60d9b90b@haskell.org> #8732: Global big object heap allocator lock causes contention -------------------------------------+------------------------------------- Reporter: tibbe | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime | Version: 7.6.3 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): with the new contiguous heap design for x86_64 systems that just got merged in, do some of the ideas here become easier? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 17 03:24:04 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Dec 2014 03:24:04 -0000 Subject: [GHC] #9891: Fixity declarations for pattern synonyms not persisted Message-ID: <047.aacdfa42ce012caca1b8aa09b153b9ab@haskell.org> #9891: Fixity declarations for pattern synonyms not persisted -------------------------------------+------------------------------------- Reporter: klkblake | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Incorrect Blocked By: | result at runtime Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- It appears fixity declarations for pattern synonyms only affect modules being compiled in the same run as the module the definition is in. For example, take the following files: Foo.hs: {{{#!hs {-# LANGUAGE PatternSynonyms #-} module Foo where data Type = Type Int RawType data RawType = Product Type Type | Num pattern a :*: b <- Type _ (Product a b) infixr 7 :*: }}} Bar.hs: {{{#!hs {-# LANGUAGE PatternSynonyms #-} module Main where import Foo value = Type 0 $ Product (Type 1 Num) $ Type 2 $ Product (Type 3 Num) $ Type 4 Num somethingElse = 23 main = case value of _ :*: _ :*: _ -> putStrLn "Success" _ -> putStrLn "Fail" }}} On the first compile, the executable will print "Success". Modifying Bar and recompiling will result in it printing "Fail". Modifying both and recompiling results in "Success" again. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 17 06:41:50 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Dec 2014 06:41:50 -0000 Subject: [GHC] #9049: Expose srcLoc from the assertion architecture to allow better error messages In-Reply-To: <042.a0d4c757be085a0284ebca147547b4f3@haskell.org> References: <042.a0d4c757be085a0284ebca147547b4f3@haskell.org> Message-ID: <057.c509090a7095e154de669539eb9b68f2@haskell.org> #9049: Expose srcLoc from the assertion architecture to allow better error messages -------------------------------------+------------------------------------- Reporter: nh2 | Owner: gridaphobe Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by gridaphobe): One use-case that the implicit parameters approach supports that neither -prof nor -g really do is reifying the source locations to a data structure that your haskell program can process. I imagine this is a fairly niche scenario, but it's extremely useful for embedded DSLs. I was recently working on tooling support for an EDSL used to write large (10+ kloc) programs, and providing useful diagnostic messages for the DSL was quite difficult, because I only had access to the internal AST, nothing remained of the original haskell program. I ended up writing a Core-to- Core plugin to insert the source locations that I mined from -prof, but it's a bit kludgy. This approach, on the other hand, makes it trivial for a function to get a hold of its call-site. Perhaps it would make sense to discuss the implications of this feature for library authors on the core-libraries list? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 17 06:48:34 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Dec 2014 06:48:34 -0000 Subject: [GHC] #9049: Expose srcLoc from the assertion architecture to allow better error messages In-Reply-To: <042.a0d4c757be085a0284ebca147547b4f3@haskell.org> References: <042.a0d4c757be085a0284ebca147547b4f3@haskell.org> Message-ID: <057.ac66e3d0de66894d54d5864e11a5ce85@haskell.org> #9049: Expose srcLoc from the assertion architecture to allow better error messages -------------------------------------+------------------------------------- Reporter: nh2 | Owner: gridaphobe Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by gridaphobe): I'd also like to add that I think it would be a shame to deprecate ImplicitParams, this feature notwithstanding. ImplicitParams is niche, yes, but it's also super convenient at times, in particular for passing around some configuration without having to restructure your whole program as a reader monad. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 17 07:27:41 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Dec 2014 07:27:41 -0000 Subject: [GHC] #9819: Create typesafe method of obtaining dictionary types from class definitions, and constraint objects from dictionary types In-Reply-To: <050.b04515eaa5272881d87195907090dfe3@haskell.org> References: <050.b04515eaa5272881d87195907090dfe3@haskell.org> Message-ID: <065.926ae03e9cd69703abbb07969fc6ebdc@haskell.org> #9819: Create typesafe method of obtaining dictionary types from class definitions, and constraint objects from dictionary types -------------------------------------+------------------------------------- Reporter: | Owner: spacekitteh | Status: new Type: feature | Milestone: request | Version: Priority: normal | Keywords: Component: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less Operating System: | than a day) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by spacekitteh): Thanks for the advice. It'll come together slowly, I'm afraid; writing isn't exactly my strong point. I'll get working on it! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 17 08:09:50 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Dec 2014 08:09:50 -0000 Subject: [GHC] #9819: Create typesafe method of obtaining dictionary types from class definitions, and constraint objects from dictionary types In-Reply-To: <050.b04515eaa5272881d87195907090dfe3@haskell.org> References: <050.b04515eaa5272881d87195907090dfe3@haskell.org> Message-ID: <065.7d53d3c1cd4f3be47be9900287a1eb91@haskell.org> #9819: Create typesafe method of obtaining dictionary types from class definitions, and constraint objects from dictionary types -------------------------------------+------------------------------------- Reporter: | Owner: spacekitteh | Status: new Type: feature | Milestone: request | Version: Priority: normal | Keywords: Component: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less Operating System: | than a day) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by spacekitteh): I've improved the wiki page a bit; hopefully it's clearer now @simonpj -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 17 08:40:29 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Dec 2014 08:40:29 -0000 Subject: [GHC] #9891: Fixity declarations for pattern synonyms not persisted In-Reply-To: <047.aacdfa42ce012caca1b8aa09b153b9ab@haskell.org> References: <047.aacdfa42ce012caca1b8aa09b153b9ab@haskell.org> Message-ID: <062.feb44777afa13c229e917aa77b9d718f@haskell.org> #9891: Fixity declarations for pattern synonyms not persisted -------------------------------------+------------------------------------- Reporter: klkblake | Owner: cactus Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: => cactus -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 17 08:45:30 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Dec 2014 08:45:30 -0000 Subject: [GHC] #9049: Expose srcLoc from the assertion architecture to allow better error messages In-Reply-To: <042.a0d4c757be085a0284ebca147547b4f3@haskell.org> References: <042.a0d4c757be085a0284ebca147547b4f3@haskell.org> Message-ID: <057.dd53a82ced301566128c26ef342e8213@haskell.org> #9049: Expose srcLoc from the assertion architecture to allow better error messages -------------------------------------+------------------------------------- Reporter: nh2 | Owner: gridaphobe Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Replying to [comment:16 gridaphobe]: > One use-case that the implicit parameters approach supports that neither -prof nor -g really do is reifying the source locations to a data structure that your haskell program can process. Yes. So (importantly) let's not just give access to a `String` but rather to a proper data structure with line number, module, package etc. We should use the same data structures for this purpose as the `StaticPtrInfo` fields in [wiki:StaticPointers/ImplementationPlan]. The latter are not yet well fleshed out, and advertised as subject to change. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 17 08:49:34 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Dec 2014 08:49:34 -0000 Subject: [GHC] #9819: Create typesafe method of obtaining dictionary types from class definitions, and constraint objects from dictionary types In-Reply-To: <050.b04515eaa5272881d87195907090dfe3@haskell.org> References: <050.b04515eaa5272881d87195907090dfe3@haskell.org> Message-ID: <065.967d805f17849bbe908cf9fde5b4952e@haskell.org> #9819: Create typesafe method of obtaining dictionary types from class definitions, and constraint objects from dictionary types -------------------------------------+------------------------------------- Reporter: | Owner: spacekitteh | Status: new Type: feature | Milestone: request | Version: Priority: normal | Keywords: Component: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less Operating System: | than a day) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm concentrating on the section "Base proposal". It says "Expose the constructor of the dictionary datatype created by desugaring typeclasses". But what does that mean? * Is there any new syntax? If so what, precisely? * Are there any new types available? How are they declared and used? * Are there any new functions available? If so which, and with what types? * Does type inference change at all? If so how? * Could you give some examples of usage? I know it's hard, but you can't define a language feature in one paragraph! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 17 09:03:37 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Dec 2014 09:03:37 -0000 Subject: [GHC] #9123: Need for higher kinded roles In-Reply-To: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> References: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> Message-ID: <061.4569153929e9078dc8083fbbe2c32565@haskell.org> #9123: Need for higher kinded roles -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Project (more Type of failure: | than a week) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): I think it'd be better to consider any non-type-variable context as exotic, and reject it. You can always use standalone deriving. The trouble is that it's very easy to get contexts like `(C T)`, which perhaps might be satisfiable at the call site, but not at the `deriving` site, but that is unusual, and the programmer ought to be calling it out explicitly. GHC originally accepted more exotic `deriving` contexts, and moved step by step to the current fairly conservative position. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 17 11:02:40 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Dec 2014 11:02:40 -0000 Subject: [GHC] #9892: Decomposition of AppTy broken Message-ID: <046.6d654643cdc77685f7fb2e80446b2a64@haskell.org> #9892: Decomposition of AppTy broken -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- This program (taken from `lens`) wrongly fails in GHC's HEAD {{{ {-# LANGUAGE UndecidableInstances #-} import Control.Applicative import Control.Category import Prelude hiding ((.),id) newtype FocusingPlus w k s a = FocusingPlus { unfocusingPlus :: k (s, w) a } instance Functor (k (s, w)) => Functor (FocusingPlus w k s) where fmap f (FocusingPlus as) = FocusingPlus (fmap f as) instance Applicative (k (s, w)) => Applicative (FocusingPlus w k s) where pure = FocusingPlus . pure FocusingPlus kf <*> FocusingPlus ka = FocusingPlus (kf <*> ka) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 17 11:03:39 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Dec 2014 11:03:39 -0000 Subject: [GHC] #9819: Create typesafe method of obtaining dictionary types from class definitions, and constraint objects from dictionary types In-Reply-To: <050.b04515eaa5272881d87195907090dfe3@haskell.org> References: <050.b04515eaa5272881d87195907090dfe3@haskell.org> Message-ID: <065.c074e8289d65ab000285a36334f2dcb4@haskell.org> #9819: Create typesafe method of obtaining dictionary types from class definitions, and constraint objects from dictionary types -------------------------------------+------------------------------------- Reporter: | Owner: spacekitteh | Status: new Type: feature | Milestone: request | Version: Priority: normal | Keywords: Component: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less Operating System: | than a day) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by spacekitteh): Sorry, I had much of the information in there but it was scattered. The page is still a WIP. I updated it again to hopefully be in a more readable format. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 17 11:05:38 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Dec 2014 11:05:38 -0000 Subject: [GHC] #9891: Fixity declarations for pattern synonyms not persisted In-Reply-To: <047.aacdfa42ce012caca1b8aa09b153b9ab@haskell.org> References: <047.aacdfa42ce012caca1b8aa09b153b9ab@haskell.org> Message-ID: <062.9766b5ccccccc0ecca6ee9841e764bf4@haskell.org> #9891: Fixity declarations for pattern synonyms not persisted -------------------------------------+------------------------------------- Reporter: klkblake | Owner: cactus Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: pattern synonyms Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by cactus): * keywords: => pattern synonyms -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 17 11:06:42 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Dec 2014 11:06:42 -0000 Subject: [GHC] #9226: Internal error when using equality constraint in pattern synonyms In-Reply-To: <051.9ff7e888b2f688be0dafb9aefbac40b9@haskell.org> References: <051.9ff7e888b2f688be0dafb9aefbac40b9@haskell.org> Message-ID: <066.788f08cb0c8735a0d98703b327524cc7@haskell.org> #9226: Internal error when using equality constraint in pattern synonyms -------------------------------------+------------------------------------- Reporter: | Owner: Iceland_jack | Status: closed Type: bug | Milestone: Priority: lowest | Version: 7.8.2 Component: Compiler | Keywords: renamer, Resolution: duplicate | PatternSynonyms, GADTs Operating System: Linux | Architecture: x86 Type of failure: GHC | Difficulty: Unknown rejects valid program | Blocked By: Test Case: | Related Tickets: #8968 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by cactus): * keywords: renamer, pattern synonyms, GADTs => renamer, PatternSynonyms, GADTs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 17 11:06:52 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Dec 2014 11:06:52 -0000 Subject: [GHC] #9161: Pattern synonyms interact badly with data kinds In-Reply-To: <051.a4bd617eaa1666265ee94e2b2cb7b39f@haskell.org> References: <051.a4bd617eaa1666265ee94e2b2cb7b39f@haskell.org> Message-ID: <066.7211153fa75628f08e5c50764fbbef4a@haskell.org> #9161: Pattern synonyms interact badly with data kinds -------------------------------------+------------------------------------- Reporter: | Owner: cactus Iceland_jack | Status: closed Type: bug | Milestone: 7.8.3 Priority: lowest | Version: 7.8.2 Component: Compiler | Keywords: renamer, (Type checker) | PatternSynonyms, data kinds Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Compile- | Related Tickets: time crash | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by cactus): * keywords: renamer, pattern synonyms, data kinds => renamer, PatternSynonyms, data kinds -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 17 11:07:32 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Dec 2014 11:07:32 -0000 Subject: [GHC] #9891: Fixity declarations for pattern synonyms not persisted In-Reply-To: <047.aacdfa42ce012caca1b8aa09b153b9ab@haskell.org> References: <047.aacdfa42ce012caca1b8aa09b153b9ab@haskell.org> Message-ID: <062.4a960193cdd4154756cdb60b6839b643@haskell.org> #9891: Fixity declarations for pattern synonyms not persisted -------------------------------------+------------------------------------- Reporter: klkblake | Owner: cactus Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: PatternSynonyms Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by cactus): * keywords: pattern synonyms => PatternSynonyms -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 17 11:13:46 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Dec 2014 11:13:46 -0000 Subject: [GHC] #9793: Some as-patterns could be accepted in pattern synonyms In-Reply-To: <045.e251d4b7f57881692430bb7253319357@haskell.org> References: <045.e251d4b7f57881692430bb7253319357@haskell.org> Message-ID: <060.e9ef26714a4efd60bca1960857189d1e@haskell.org> #9793: Some as-patterns could be accepted in pattern synonyms -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: PatternSynonyms (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by cactus): * keywords: pattern synonyms => PatternSynonyms -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 17 11:14:11 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Dec 2014 11:14:11 -0000 Subject: [GHC] #9783: Pattern synonym matcher is unnecessarily strict on unboxed continuations In-Reply-To: <045.fbfedd3216f2b9704ce7d408adca131b@haskell.org> References: <045.fbfedd3216f2b9704ce7d408adca131b@haskell.org> Message-ID: <060.ba68839ac28e7a5fa0bad0263a2f4c13@haskell.org> #9783: Pattern synonym matcher is unnecessarily strict on unboxed continuations -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: bug | Status: merge Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: PatternSynonyms Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: 9732 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by cactus): * keywords: pattern synonyms => PatternSynonyms -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 17 11:14:20 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Dec 2014 11:14:20 -0000 Subject: [GHC] #9732: Pattern synonyms and unboxed values In-Reply-To: <047.98d7de74203e4f381291a803ad282f11@haskell.org> References: <047.98d7de74203e4f381291a803ad282f11@haskell.org> Message-ID: <062.a688259db6eedc9c88ba20589c6da1bc@haskell.org> #9732: Pattern synonyms and unboxed values -------------------------------------+------------------------------------- Reporter: monoidal | Owner: cactus Type: bug | Status: merge Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: PatternSynonyms Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by cactus): * keywords: pattern synonyms => PatternSynonyms -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 17 11:14:36 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Dec 2014 11:14:36 -0000 Subject: [GHC] #9705: Panic on a pattern synonym in a class In-Reply-To: <047.614ec39c173b8238a9064e76b118d842@haskell.org> References: <047.614ec39c173b8238a9064e76b118d842@haskell.org> Message-ID: <062.4d67d2db21fb1fdd1c65a3af120df4a3@haskell.org> #9705: Panic on a pattern synonym in a class -------------------------------------+------------------------------------- Reporter: monoidal | Owner: cactus Type: bug | Status: closed Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: PatternSynonyms Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Compile- | Related Tickets: time crash | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by cactus): * keywords: pattern synonyms => PatternSynonyms -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 17 11:14:42 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Dec 2014 11:14:42 -0000 Subject: [GHC] #9671: Allow expressions in patterns In-Reply-To: <051.5c0ed72ec50bbc2111e7cfd2e5c841ff@haskell.org> References: <051.5c0ed72ec50bbc2111e7cfd2e5c841ff@haskell.org> Message-ID: <066.cde0671817bc9b213e8b5476a5b63004@haskell.org> #9671: Allow expressions in patterns -------------------------------------+------------------------------------- Reporter: | Owner: Iceland_jack | Status: new Type: feature | Milestone: 7.10.1 request | Version: Priority: normal | Keywords: PatternSynonyms Component: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by cactus): * keywords: patterns, pattern synonyms => PatternSynonyms -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 17 11:14:49 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Dec 2014 11:14:49 -0000 Subject: [GHC] #9893: Switching on TypeFamilies extension stops code from typechecking Message-ID: <046.0bc9c656741924464ea1618df8af619c@haskell.org> #9893: Switching on TypeFamilies extension stops code from typechecking -------------------------------------+------------------------------------- Reporter: phischu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: x86_64 (amd64) | Unknown/Multiple Difficulty: Unknown | Type of failure: GHC Blocked By: | rejects valid program Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The following code has the `TypeFamilies` extension enabled but does not use it. It does not typecheck with GHC 7.8.3. If we do not enable `TypeFamilies` (i.e. delete the first line) it typechecks. {{{ {-# LANGUAGE TypeFamilies #-} module ExistentialFamilies where import Control.Monad.ST (runST,ST) un :: () un = runST f where f = return un :: ST s () }}} This happens when trying to compile the program as well as when trying to load it into ghci. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 17 11:15:08 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Dec 2014 11:15:08 -0000 Subject: [GHC] #9514: Haddock panics when exporting a module with pattern synonyms In-Reply-To: <051.724e8731cbd989337a8289cb4a174715@haskell.org> References: <051.724e8731cbd989337a8289cb4a174715@haskell.org> Message-ID: <066.aed2f01682b79bbe343bbd19fd581d40@haskell.org> #9514: Haddock panics when exporting a module with pattern synonyms -------------------------------------+------------------------------------- Reporter: | Owner: cactus Artyom.Kazak | Status: closed Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: haddock, Resolution: duplicate | PatternSynonyms Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile- | Difficulty: Unknown time crash | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by cactus): * keywords: haddock, pattern synonyms => haddock, PatternSynonyms -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 17 11:15:17 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Dec 2014 11:15:17 -0000 Subject: [GHC] #9417: Pattern synonyms across modules broken in Haddock In-Reply-To: <047.b6ac7a5cd3eafafe3f496e209d04da27@haskell.org> References: <047.b6ac7a5cd3eafafe3f496e209d04da27@haskell.org> Message-ID: <062.04e274f3b9036beec0b134df3451b918@haskell.org> #9417: Pattern synonyms across modules broken in Haddock -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: cactus Type: bug | Status: closed Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: PatternSynonyms Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by cactus): * keywords: pattern synonyms => PatternSynonyms -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 17 11:15:25 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Dec 2014 11:15:25 -0000 Subject: [GHC] #8968: Pattern synonyms and GADTs In-Reply-To: <047.5ccbe5e4c936202b9335f498db73d62e@haskell.org> References: <047.5ccbe5e4c936202b9335f498db73d62e@haskell.org> Message-ID: <062.e07f8d1ccf0c7d1aeb4850bc118de671@haskell.org> #8968: Pattern synonyms and GADTs -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: cactus Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.1-rc2 (Type checker) | Keywords: PatternSynonyms Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: 8584 Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by cactus): * keywords: pattern synonyms => PatternSynonyms -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 17 11:15:34 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Dec 2014 11:15:34 -0000 Subject: [GHC] #8779: Exhaustiveness checks for pattern synonyms In-Reply-To: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> References: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> Message-ID: <061.e73de2f7d42af2f39b9f8b42711fd152@haskell.org> #8779: Exhaustiveness checks for pattern synonyms -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Keywords: PatternSynonyms (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by cactus): * keywords: pattern synonyms => PatternSynonyms -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 17 11:15:59 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Dec 2014 11:15:59 -0000 Subject: [GHC] #8761: Make pattern synonyms work with Template Haskell In-Reply-To: <047.c5d8ed063e9e82c354c50c5724ebe787@haskell.org> References: <047.c5d8ed063e9e82c354c50c5724ebe787@haskell.org> Message-ID: <062.779bba0de86777be904d1c28354181e4@haskell.org> #8761: Make pattern synonyms work with Template Haskell -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: Component: Template | Keywords: PatternSynonyms Haskell | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by cactus): * keywords: pattern synonyms => PatternSynonyms -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 17 11:16:06 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Dec 2014 11:16:06 -0000 Subject: [GHC] #8584: Pattern synonym type signatures In-Reply-To: <045.c6cdcd563c8eae8b80969790ee87e736@haskell.org> References: <045.c6cdcd563c8eae8b80969790ee87e736@haskell.org> Message-ID: <060.90976995d526d275055d5ead824e4642@haskell.org> #8584: Pattern synonym type signatures -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: Component: Compiler | Keywords: PatternSynonyms (Type checker) | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Unknown Operating System: | Blocked By: 5144 Unknown/Multiple | Related Tickets: 8581 Type of failure: | None/Unknown | Test Case: | Blocking: 8968 | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by cactus): * keywords: pattern synonyms => PatternSynonyms -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 17 11:16:17 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Dec 2014 11:16:17 -0000 Subject: [GHC] #8583: Associated pattern synonyms In-Reply-To: <045.39184734af9bc44765e305261b59a6ed@haskell.org> References: <045.39184734af9bc44765e305261b59a6ed@haskell.org> Message-ID: <060.ac6d913aa986c98732c8d6d5daba8dad@haskell.org> #8583: Associated pattern synonyms -------------------------------------+------------------------------------- Reporter: cactus | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: Component: Compiler | Keywords: PatternSynonyms Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: 5144 Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by cactus): * keywords: pattern synonyms => PatternSynonyms -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 17 11:16:27 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Dec 2014 11:16:27 -0000 Subject: [GHC] #8581: Add support for explicitly-bidirectional pattern synonyms In-Reply-To: <045.ffb8b433d262c0e3b5b415c2eeca2eee@haskell.org> References: <045.ffb8b433d262c0e3b5b415c2eeca2eee@haskell.org> Message-ID: <060.b011a2fefd20b00fb5bcf489b7599238@haskell.org> #8581: Add support for explicitly-bidirectional pattern synonyms -------------------------------------+------------------------------------- Reporter: cactus | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: Component: Compiler | Keywords: PatternSynonyms Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: 5144 Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by cactus): * keywords: pattern synonyms => PatternSynonyms -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 17 11:16:33 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Dec 2014 11:16:33 -0000 Subject: [GHC] #5144: Pattern synonyms In-Reply-To: <046.358306463908294bbc35edfc129eeda7@haskell.org> References: <046.358306463908294bbc35edfc129eeda7@haskell.org> Message-ID: <061.855d049ca4e9b00d1adae57a8b1c0088@haskell.org> #5144: Pattern synonyms -------------------------------------+------------------------------------- Reporter: simonpj | Owner: cactus Type: feature | Status: closed request | Milestone: 7.8.1 Priority: normal | Version: Component: Compiler | Keywords: PatternSynonyms Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: 8581, | 8582, 8583, 8584 | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by cactus): * keywords: pattern synonyms => PatternSynonyms -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 17 11:17:07 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Dec 2014 11:17:07 -0000 Subject: [GHC] #9867: PatternSynonyms + ScopedTypeVariables triggers an internal error In-Reply-To: <046.5cdd1cb9d606767d1869bca60906658f@haskell.org> References: <046.5cdd1cb9d606767d1869bca60906658f@haskell.org> Message-ID: <061.4a0370a5c893fb0ff267006510c2b9bf@haskell.org> #9867: PatternSynonyms + ScopedTypeVariables triggers an internal error -------------------------------------+------------------------------------- Reporter: antalsz | Owner: cactus Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: PatternSynonyms Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Compile- | Related Tickets: time crash | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by cactus): * keywords: pattern synonyms => PatternSynonyms -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 17 12:18:26 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Dec 2014 12:18:26 -0000 Subject: [GHC] #9891: Fixity declarations for pattern synonyms not persisted In-Reply-To: <047.aacdfa42ce012caca1b8aa09b153b9ab@haskell.org> References: <047.aacdfa42ce012caca1b8aa09b153b9ab@haskell.org> Message-ID: <062.656889324d980aa30bd3c4159ce0b9a3@haskell.org> #9891: Fixity declarations for pattern synonyms not persisted -------------------------------------+------------------------------------- Reporter: klkblake | Owner: cactus Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: PatternSynonyms Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by cactus): I can't reproduce it on either GHC 7.8.3 or `0ac059`: {{{ $ ghc --make Bar.hs [1 of 2] Compiling Foo ( Foo.hs, Foo.o ) [2 of 2] Compiling Main ( Bar.hs, Bar.o ) Linking Bar ... $ ./Bar Success $ touch Bar.hs $ ghc --make Bar.hs [2 of 2] Compiling Main ( Bar.hs, Bar.o ) Linking Bar ... $ ./Bar Success }}} {{{ $ ~/prog/haskell/ghc/ghc-build/inplace/bin/ghc-stage2 --make Bar.hs [1 of 2] Compiling Foo ( Foo.hs, Foo.o ) [2 of 2] Compiling Main ( Bar.hs, Bar.o ) WARNING: file compiler/stgSyn/CoreToStg.hs, line 270 somethingElse True False Linking Bar ... $ ./Bar Success $ touch Bar.hs $ ~/prog/haskell/ghc/ghc-build/inplace/bin/ghc-stage2 --make Bar.hs [2 of 2] Compiling Main ( Bar.hs, Bar.o ) WARNING: file compiler/stgSyn/CoreToStg.hs, line 270 somethingElse True False Linking Bar ... $ ./Bar Success }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 17 12:18:39 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Dec 2014 12:18:39 -0000 Subject: [GHC] #9891: Fixity declarations for pattern synonyms not persisted In-Reply-To: <047.aacdfa42ce012caca1b8aa09b153b9ab@haskell.org> References: <047.aacdfa42ce012caca1b8aa09b153b9ab@haskell.org> Message-ID: <062.1c0a159cec67b03f2f91d38d0182b4e9@haskell.org> #9891: Fixity declarations for pattern synonyms not persisted -------------------------------------+------------------------------------- Reporter: klkblake | Owner: cactus Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: PatternSynonyms Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by cactus): * status: new => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 17 12:24:05 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Dec 2014 12:24:05 -0000 Subject: [GHC] #9889: Pattern synonym does not work in top-level pattern bind (was: Pattern synonym does not work at top level) In-Reply-To: <047.fe6568ce87d5703b3811c455881d3231@haskell.org> References: <047.fe6568ce87d5703b3811c455881d3231@haskell.org> Message-ID: <062.b0309e4ce2abf5ac9794fcb1b2dab50a@haskell.org> #9889: Pattern synonym does not work in top-level pattern bind -------------------------------------+------------------------------------- Reporter: goldfire | Owner: cactus Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 (Type checker) | Keywords: PatternSynonyms Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by cactus): * failure: None/Unknown => GHC rejects valid program * component: Compiler => Compiler (Type checker) Old description: > When I say > > {{{ > pattern Id x = x > > Id x = True > }}} > > I get > > {{{ > Not in scope: data constructor ?Id? > }}} > > This happens with both 7.8.3 and HEAD. New description: When I say {{{ {-# LANGUAGE PatternSynonyms #-} pattern Id x = x Id x = True }}} I get {{{ Not in scope: data constructor ?Id? }}} This happens with both 7.8.3 and HEAD. -- Comment: Note that pattern binds, in general, don't have this problem, only at the top level; e.g. the following works as expected: {{{ {-# LANGUAGE PatternSynonyms #-} pattern Id x = x foo = x where Id x = True }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 17 12:31:00 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Dec 2014 12:31:00 -0000 Subject: [GHC] #5108: Allow unicode sub/superscript symbols in both identifiers and operators In-Reply-To: <057.b2c48f6dcee48c8d27365f9afce8a850@haskell.org> References: <057.b2c48f6dcee48c8d27365f9afce8a850@haskell.org> Message-ID: <072.f390e2c7ed9b6105dbd07e929c31b5ea@haskell.org> #5108: Allow unicode sub/superscript symbols in both identifiers and operators -------------------------------------+------------------------------------- Reporter: | Owner: mikhail.vorozhtsov | Status: infoneeded Type: feature | Milestone: 7.10.1 request | Version: 7.1 Priority: normal | Keywords: lexer unicode Component: Compiler | Architecture: Unknown/Multiple (Parser) | Difficulty: Unknown Resolution: | Blocked By: Operating System: | Related Tickets: Unknown/Multiple | Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by zardoz): I also stumbled into this when trying to use the modifier letter prime (U+02B9) and related modifiers. Supporting them in identifiers would be awesome. As for operators I don?t feel strongly either way. I was just confused about modifiers not working in identifiers, because they are classified as alphanumeric in the Unicode properties. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 17 12:46:33 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Dec 2014 12:46:33 -0000 Subject: [GHC] #3693: Show stack traces In-Reply-To: <043.7c288f8e774d3806292d73b1513892ec@haskell.org> References: <043.7c288f8e774d3806292d73b1513892ec@haskell.org> Message-ID: <058.9a19e0ad6d673c30110fd3c7f0d7a095@haskell.org> #3693: Show stack traces -------------------------------------+------------------------------------- Reporter: jpet | Owner: Tarrasch Type: feature | Status: new request | Milestone: 7.12.1 Priority: normal | Version: 6.10.4 Component: Runtime | Keywords: System | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by Tarrasch): * milestone: 7.10.1 => 7.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 17 12:54:38 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Dec 2014 12:54:38 -0000 Subject: [GHC] #3693: Show stack traces In-Reply-To: <043.7c288f8e774d3806292d73b1513892ec@haskell.org> References: <043.7c288f8e774d3806292d73b1513892ec@haskell.org> Message-ID: <058.8561c0650c941baba53184a3c9bd2636@haskell.org> #3693: Show stack traces -------------------------------------+------------------------------------- Reporter: jpet | Owner: Tarrasch Type: feature | Status: new request | Milestone: 7.12.1 Priority: normal | Version: 6.10.4 Component: Runtime | Keywords: System | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Tarrasch): Now both the source note patches[1] and DWARF emitting patches[2] have been merged, and will be included in GHC 7.10. That means (afaik) that you should be able to get stack traces when you run your program with a debugger. As the feature freeze for 7.10 was quite a while ago, Haskell-land stack traces can't be merged for 7.10 unfortunately. What's currently missing is a DWARF-reading library in the RTS that we're happy with and then the actual stack trace implementation. [1]: https://phabricator.haskell.org/D169 [2]: https://phabricator.haskell.org/D396 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 17 13:11:40 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Dec 2014 13:11:40 -0000 Subject: [GHC] #9894: Presence of DWARF debug symbols doesn't result in working backtraces in GDB Message-ID: <044.2b175213c6f45c4fd4087c47df418ce5@haskell.org> #9894: Presence of DWARF debug symbols doesn't result in working backtraces in GDB ----------------------------------+--------------------------------------- Reporter: tibbe | Owner: scpmw Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------+--------------------------------------- Now when GHC can output DWARF debug symbols we need to take the remaining steps needed to get downstream tool like GDB to do something useful with it. As of today GDB cannot produce a valid stack trace for this code: {{{#!hs module Main where import System.IO f name = print $ "Hello, " ++ name {-# NOINLINE f #-} g name = f name {-# NOINLINE g #-} main = do name <- getLine g name }}} when a breakpoint is set on the line that defines `f` before the program is run. The resulting backtrace looks like: {{{ (gdb) bt #0 Main_f_info () at /tmp/Test.hs:5 #1 0x0000000000481a00 in ?? () Backtrace stopped: frame did not save the PC }}} This bug tracks the remaining work that needs to be done before this will work. Peter, what is the remaining work here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 17 13:19:18 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Dec 2014 13:19:18 -0000 Subject: [GHC] #9894: Presence of DWARF debug symbols doesn't result in working backtraces in GDB In-Reply-To: <044.2b175213c6f45c4fd4087c47df418ce5@haskell.org> References: <044.2b175213c6f45c4fd4087c47df418ce5@haskell.org> Message-ID: <059.159ac91aa41aee260438bb6017ce33ba@haskell.org> #9894: Presence of DWARF debug symbols doesn't result in working backtraces in GDB ---------------------------------------+---------------------------------- Reporter: tibbe | Owner: scpmw Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ---------------------------------------+---------------------------------- Changes (by tibbe): * cc: Tarrasch (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 17 13:35:27 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Dec 2014 13:35:27 -0000 Subject: [GHC] #9894: Presence of DWARF debug symbols doesn't result in working backtraces in GDB In-Reply-To: <044.2b175213c6f45c4fd4087c47df418ce5@haskell.org> References: <044.2b175213c6f45c4fd4087c47df418ce5@haskell.org> Message-ID: <059.868a7e2bd876ee5fc6c4eaad2f8b4f3f@haskell.org> #9894: Presence of DWARF debug symbols doesn't result in working backtraces in GDB ---------------------------------------+---------------------------------- Reporter: tibbe | Owner: scpmw Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ---------------------------------------+---------------------------------- Comment (by tibbe): Peter tells me that I need to add {{{ GhcRtsHcOpts += -g GhcLibHcOpts += -g }}} at the bottom of mk/build.mk to get debug symbols working. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 17 14:13:42 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Dec 2014 14:13:42 -0000 Subject: [GHC] #9889: Pattern synonym does not work in top-level pattern bind In-Reply-To: <047.fe6568ce87d5703b3811c455881d3231@haskell.org> References: <047.fe6568ce87d5703b3811c455881d3231@haskell.org> Message-ID: <062.e0b2860c0fa047b639bc07afb5f52f47@haskell.org> #9889: Pattern synonym does not work in top-level pattern bind -------------------------------------+------------------------------------- Reporter: goldfire | Owner: cactus Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.9 (Type checker) | Keywords: PatternSynonyms Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by cactus): * status: new => patch Comment: I've pushed a proposed fix for this to the `wip/T9889` branch, but it might be a bit of a sensitive change, since it requires introducing pattern synonym names in the renamer in a separate pass between renaming `TyClDecl`s and `HsValBind`s. Simon, please review. {{{ commit e5f429cbc02df745df1517d53c8ca170de41757b Author: Dr. ERDI Gergo Date: Wed Dec 17 22:09:06 2014 +0800 Pattern synonym names need to be in scope before renaming bindings (#9889) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 17 14:18:00 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Dec 2014 14:18:00 -0000 Subject: [GHC] #9894: Presence of DWARF debug symbols doesn't result in working backtraces in GDB In-Reply-To: <044.2b175213c6f45c4fd4087c47df418ce5@haskell.org> References: <044.2b175213c6f45c4fd4087c47df418ce5@haskell.org> Message-ID: <059.e818e4b532f6066601d89e7c7c3672c8@haskell.org> #9894: Presence of DWARF debug symbols doesn't result in working backtraces in GDB ---------------------------------------+---------------------------------- Reporter: tibbe | Owner: scpmw Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ---------------------------------------+---------------------------------- Comment (by Tarrasch): Indeed. I don't remember why, but I also found that I have {{{GhcStage2HcOpts += -g}}} in my mk/build.mk as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 17 14:45:35 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Dec 2014 14:45:35 -0000 Subject: [GHC] #9424: ghc-api/T8628 fails assert on debugged ghc In-Reply-To: <045.40c90e35dc60386a27fb2e3ed744169b@haskell.org> References: <045.40c90e35dc60386a27fb2e3ed744169b@haskell.org> Message-ID: <060.dc8b3be3ed56b68eff973f7d3ad943ae@haskell.org> #9424: ghc-api/T8628 fails assert on debugged ghc -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"67a0cab6b501e2d6280b51655af66ad448b3deef/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="67a0cab6b501e2d6280b51655af66ad448b3deef" Fix GHCi/GHC-API tidying and modules (Trac #9424, #9426) There were two related bugs here Trac #9426 We must increment the ic_mod_index field of the InteractiveContext if we have new instances, because we maek DFunIds that should be distinct from previous ones. Previously we were only incrementing when defining new user-visible Ids. The main change is in HscTypes.extendInteractiveContext, which now alwyas bumps the ic_mod_index. I also added a specialised extendInteractiveContextWithIds for the case where we are *only* adding new user-visible Ids. Trac #9424 In HscMain.hscDeclsWithLocations we were failing to use the *tidied* ClsInsts; but the un-tidied ones are LocalIds which causes a later ASSERT error. On the way I realised that, to behave consistently, the tcg_insts and tcg_fam_insts field of TcGblEnv should really only contain instances from the current GHCi command, not all the ones to date. That in turn meant I had to move the code for deleting replacement instances from addLocalInst, addLocalFamInst to HscTypes.extendInteractiveContext }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 17 14:45:35 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Dec 2014 14:45:35 -0000 Subject: [GHC] #5267: Missing type checks for arrow command combinators In-Reply-To: <044.163efcb7d580ba127cae71d7f722a189@haskell.org> References: <044.163efcb7d580ba127cae71d7f722a189@haskell.org> Message-ID: <059.0dc445c7a361512e006c310314cbd9ef@haskell.org> #5267: Missing type checks for arrow command combinators ------------------------------------------------+-------------------------- Reporter: peteg | Owner: ross Type: bug | Status: new Priority: low | Milestone: 7.10.1 Component: Compiler (Type checker) | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts invalid program | Unknown/Multiple Test Case: | Difficulty: Blocking: | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by Simon Peyton Jones ): In [changeset:"f50d62bb6c0357991fabf938bc971d528bbf5cc4/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="f50d62bb6c0357991fabf938bc971d528bbf5cc4" Fix the scope-nesting for arrows Previously we were capturing the *entire environment* when moving under a 'proc', for the newArrowScope/escapeArrowScope thing. But that a blunderbuss, and in any case isn't right (the untouchable-type-varaible invariant gets invalidated). So I fixed it to be much more refined: just the LocalRdrEnv and constraints are captured. I think this is right; but if not we should just add more fields to ArrowCtxt, not return to the blunderbuss. This patch fixes the ASSERT failure in Trac #5267 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 17 14:45:36 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Dec 2014 14:45:36 -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.2f5f1c50581828346baff7e4291c39eb@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 Simon Peyton Jones ): In [changeset:"6b11bab6961a1518a15eaa3d3b4ce40702724ca5/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="6b11bab6961a1518a15eaa3d3b4ce40702724ca5" Improve TidyPgm.hasCafRefs to account for Integer literals (Trac #8525) See Note [Disgusting computation of CafRefs] in TidyPgm. Also affects CoreUtils.rhsIsStatic. The real solution here is to compute CAF and arity information from the STG-program, and feed it back to tidied program for the interface file and later GHCi clients. A battle for another day. But at least this commit reduces the number of gratuitous CAFs, and hence SRT entries. And kills off a batch of ASSERT failures. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 17 14:45:35 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Dec 2014 14:45:35 -0000 Subject: [GHC] #9426: ghci triggers 'ASSERT failed! file compiler/ghci/Linker.lhs, line 906' In-Reply-To: <045.4a6b72a25dd245d66de01ff299d3a844@haskell.org> References: <045.4a6b72a25dd245d66de01ff299d3a844@haskell.org> Message-ID: <060.3ad33702f0f2842e54bf0390bbc6a347@haskell.org> #9426: ghci triggers 'ASSERT failed! file compiler/ghci/Linker.lhs, line 906' -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: ghci044 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"67a0cab6b501e2d6280b51655af66ad448b3deef/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="67a0cab6b501e2d6280b51655af66ad448b3deef" Fix GHCi/GHC-API tidying and modules (Trac #9424, #9426) There were two related bugs here Trac #9426 We must increment the ic_mod_index field of the InteractiveContext if we have new instances, because we maek DFunIds that should be distinct from previous ones. Previously we were only incrementing when defining new user-visible Ids. The main change is in HscTypes.extendInteractiveContext, which now alwyas bumps the ic_mod_index. I also added a specialised extendInteractiveContextWithIds for the case where we are *only* adding new user-visible Ids. Trac #9424 In HscMain.hscDeclsWithLocations we were failing to use the *tidied* ClsInsts; but the un-tidied ones are LocalIds which causes a later ASSERT error. On the way I realised that, to behave consistently, the tcg_insts and tcg_fam_insts field of TcGblEnv should really only contain instances from the current GHCi command, not all the ones to date. That in turn meant I had to move the code for deleting replacement instances from addLocalInst, addLocalFamInst to HscTypes.extendInteractiveContext }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 17 14:45:36 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Dec 2014 14:45:36 -0000 Subject: [GHC] #9892: Decomposition of AppTy broken In-Reply-To: <046.6d654643cdc77685f7fb2e80446b2a64@haskell.org> References: <046.6d654643cdc77685f7fb2e80446b2a64@haskell.org> Message-ID: <061.fdd472f147e29a9cbd6de850d9d1a26b@haskell.org> #9892: Decomposition of AppTy broken -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"517908fce0cdae9d0ae987fa7474ee235533c77a/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="517908fce0cdae9d0ae987fa7474ee235533c77a" Fix egregious bug in the new canonicalisation code for AppTy Fixes Trac #9892. Must form part of 7.10.1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 17 14:56:49 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Dec 2014 14:56:49 -0000 Subject: [GHC] #9893: Switching on TypeFamilies extension stops code from typechecking In-Reply-To: <046.0bc9c656741924464ea1618df8af619c@haskell.org> References: <046.0bc9c656741924464ea1618df8af619c@haskell.org> Message-ID: <061.e75529a0bf780855da9a067cb617baf3@haskell.org> #9893: Switching on TypeFamilies extension stops code from typechecking -------------------------------------+------------------------------------- Reporter: phischu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: x86_64 (amd64) Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Description changed by phischu: Old description: > The following code has the `TypeFamilies` extension enabled but does not > use it. It does not typecheck with GHC 7.8.3. If we do not enable > `TypeFamilies` (i.e. delete the first line) it typechecks. > > {{{ > {-# LANGUAGE TypeFamilies #-} > module ExistentialFamilies where > > import Control.Monad.ST (runST,ST) > > un :: () > un = runST f where > f = return un :: ST s () > }}} > This happens when trying to compile the program as well as when trying to > load it into ghci. New description: The following code has the `TypeFamilies` extension enabled but does not use it. It does not typecheck with GHC 7.8.3. If we do not enable `TypeFamilies` (i.e. delete the first line) it typechecks. {{{ {-# LANGUAGE TypeFamilies #-} module ExistentialFamilies where import Control.Monad.ST (runST,ST) un :: () un = runST f where f = return un :: ST s () }}} This happens when trying to compile the program as well as when trying to load it into ghci. The error message when `TypeFamilies` is on is {{{ > ghc ExistentialFamilies.hs [1 of 1] Compiling ExistentialFamilies ( ExistentialFamilies.hs, ExistentialFamilies.o ) ExistentialFamilies.hs:7:12: Couldn't match type ?s0? with ?s? because type variable ?s? would escape its scope This (rigid, skolem) type variable is bound by a type expected by the context: ST s () at ExistentialFamilies.hs:7:6-12 Expected type: ST s () Actual type: ST s0 () Relevant bindings include f :: ST s0 () (bound at ExistentialFamilies.hs:8:5) In the first argument of ?runST?, namely ?f? In the expression: runST f }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 17 15:00:42 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Dec 2014 15:00:42 -0000 Subject: [GHC] #9424: ghc-api/T8628 fails assert on debugged ghc In-Reply-To: <045.40c90e35dc60386a27fb2e3ed744169b@haskell.org> References: <045.40c90e35dc60386a27fb2e3ed744169b@haskell.org> Message-ID: <060.a5958b2d1796eb295eb6f9217a6a0ef2@haskell.org> #9424: ghc-api/T8628 fails assert on debugged ghc -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 17 15:00:59 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Dec 2014 15:00:59 -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.269b09a75d6eacb1dea8b9a467423c9c@haskell.org> #8525: lib/integer/integerConstantFolding fails with -DDEBUG -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Test Suite | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | integerConstantFolding | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 17 15:01:41 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Dec 2014 15:01:41 -0000 Subject: [GHC] #9892: Decomposition of AppTy broken In-Reply-To: <046.6d654643cdc77685f7fb2e80446b2a64@haskell.org> References: <046.6d654643cdc77685f7fb2e80446b2a64@haskell.org> Message-ID: <061.83f745db4ea1c0b9ba5321c124f74638@haskell.org> #9892: Decomposition of AppTy broken -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 17 15:03:58 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Dec 2014 15:03:58 -0000 Subject: [GHC] #5267: Missing type checks for arrow command combinators In-Reply-To: <044.163efcb7d580ba127cae71d7f722a189@haskell.org> References: <044.163efcb7d580ba127cae71d7f722a189@haskell.org> Message-ID: <059.de2e8b6934013229e912ad2bf3e18760@haskell.org> #5267: Missing type checks for arrow command combinators -------------------------------------+------------------------------------- Reporter: peteg | Owner: ross Type: bug | Status: new Priority: low | Milestone: 7.10.1 Component: Compiler | Version: 7.0.3 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: accepts invalid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * difficulty: => Unknown Comment: There *is* something to do in the type checker, namely to plumb the type constraints correctly. See the changes to `newArrowScope` and `escapeArrowScope` in the above patch. This fixes the assertion failure. I'm still not confident about all this, and I'd love someone who understands arrows to review the type inference code for arrows. So I'll leave the ticket open. But it's better, I think. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 17 15:09:16 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Dec 2014 15:09:16 -0000 Subject: [GHC] #9893: Switching on TypeFamilies extension stops code from typechecking In-Reply-To: <046.0bc9c656741924464ea1618df8af619c@haskell.org> References: <046.0bc9c656741924464ea1618df8af619c@haskell.org> Message-ID: <061.f49b8944c7eccce2c9bf5c9ccc129c1b@haskell.org> #9893: Switching on TypeFamilies extension stops code from typechecking -------------------------------------+------------------------------------- Reporter: phischu | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: invalid | Keywords: Operating System: | Architecture: x86_64 (amd64) Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => invalid Comment: This is confusing, but it's by design. With `TypeFamilies` we also get `MonoLocalBinds`, so that `f`'s definition (which is local) is not generalised. But `runST` requires a polymorphic `f`; and a monomorphic `f` isn't good enough. Hence the error. Giving a type signature to `f` is enough. (Giving a type signature to its right hand side, on the other hand, is not enough Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 17 19:35:18 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Dec 2014 19:35:18 -0000 Subject: [GHC] #9878: Static pointers in GHCi cause panic In-Reply-To: <047.a0b4c5e0dee3f65cf24b644a915474ce@haskell.org> References: <047.a0b4c5e0dee3f65cf24b644a915474ce@haskell.org> Message-ID: <062.b2fb0b10498a99ba8ad26ff2d4d58d46@haskell.org> #9878: Static pointers in GHCi cause panic -------------------------------------+------------------------------------- Reporter: monoidal | Owner: facundo.dominguez Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHCi crash | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by facundo.dominguez): I have just discovered that hpc suffers of the same illness reported above: {{{ $ cat t.hs g :: Int g = 1 + 1 facundo at fd-tweag:~/tweag/tmp$ ghc-stage2 --interactive t.hs -fhpc GHCi, version 7.9.20141217: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( t.hs, interpreted ) Ok, modules loaded: Main. *Main> g ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.9.20141217 for x86_64-unknown-linux): Loading temp shared object failed: /tmp/ghc25774_0/ghc25774_5.so: undefined symbol: _hpc_tickboxes_Main_hpc Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 17 22:22:39 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Dec 2014 22:22:39 -0000 Subject: [GHC] #9040: HPC doesnt work as expected on mac In-Reply-To: <045.879578abba86d88f677377cd5560066c@haskell.org> References: <045.879578abba86d88f677377cd5560066c@haskell.org> Message-ID: <060.2ab6464d1a3c3e742d80b9a56ba0abbf@haskell.org> #9040: HPC doesnt work as expected on mac -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Code | Version: 7.8.2 Coverage | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: MacOS X | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by ttuegel): This turns out to be a bug in Cabal, so it should be closed. Cabal doesn't separate the HPC module interfaces for each build way. Carter has library profiling enabled, so the library is built twice and only the profiled module interfaces are kept. But, the test executable is compiled with profiling disabled, so the module interface hashes don't match! See [https://github.com/haskell/cabal/issues/2281]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 17 22:31:19 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Dec 2014 22:31:19 -0000 Subject: [GHC] #9040: HPC doesnt work as expected on mac In-Reply-To: <045.879578abba86d88f677377cd5560066c@haskell.org> References: <045.879578abba86d88f677377cd5560066c@haskell.org> Message-ID: <060.e9272a0cd2b92ed0e9e4bc3512188ebb@haskell.org> #9040: HPC doesnt work as expected on mac -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Code | Version: 7.8.2 Coverage | Keywords: Resolution: invalid | Architecture: Unknown/Multiple Operating System: MacOS X | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 17 23:25:58 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Dec 2014 23:25:58 -0000 Subject: [GHC] #9426: ghci triggers 'ASSERT failed! file compiler/ghci/Linker.lhs, line 906' In-Reply-To: <045.4a6b72a25dd245d66de01ff299d3a844@haskell.org> References: <045.4a6b72a25dd245d66de01ff299d3a844@haskell.org> Message-ID: <060.1cee2da5ae9857367d9e3eda0437fc44@haskell.org> #9426: ghci triggers 'ASSERT failed! file compiler/ghci/Linker.lhs, line 906' -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: ghci044 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by slyfox): * status: new => closed * resolution: => fixed Comment: Looks fixed. Thank you! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 18 02:50:29 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Dec 2014 02:50:29 -0000 Subject: [GHC] #9891: Fixity declarations for pattern synonyms not persisted In-Reply-To: <047.aacdfa42ce012caca1b8aa09b153b9ab@haskell.org> References: <047.aacdfa42ce012caca1b8aa09b153b9ab@haskell.org> Message-ID: <062.c701f975a82c328d1cfe737847fdc3da@haskell.org> #9891: Fixity declarations for pattern synonyms not persisted -------------------------------------+------------------------------------- Reporter: klkblake | Owner: cactus Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: PatternSynonyms Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by klkblake): This is odd. I could reliably reproduce the issue using the testcase three days ago, but now I can no longer reproduce it in both the testcase and the actual program that I was working on when I discovered it. I haven't updated any software or anything. I guess it depended on files left behind from previous incomplete builds, so a clean from scratch build solves it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 18 03:12:09 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Dec 2014 03:12:09 -0000 Subject: [GHC] #9878: Static pointers in GHCi cause panic In-Reply-To: <047.a0b4c5e0dee3f65cf24b644a915474ce@haskell.org> References: <047.a0b4c5e0dee3f65cf24b644a915474ce@haskell.org> Message-ID: <062.026e2dbcb3a7e97f84a556af71cac293@haskell.org> #9878: Static pointers in GHCi cause panic -------------------------------------+------------------------------------- Reporter: monoidal | Owner: facundo.dominguez Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHCi crash | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): I'm personally very uncomfortable with GHC features not being supported by GHCI. Any such feature winds up being fundamentally second class. Eg many industrial users of GHC test run their large applications via GHCi to side step long compilations for quickly testing out changes. a) is actually adding support for GHCI and HPC challenging? (if so whats the challenge? Let us help!) b) or was it simply not done yet? If so, how can we help get this fixed before the 7.10 release -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 18 04:04:36 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Dec 2014 04:04:36 -0000 Subject: [GHC] #9895: No -mtriple param being passed to opt/llc when cross compiling Message-ID: <044.a3f80c6c0a5d3377f5d023665058edc9@haskell.org> #9895: No -mtriple param being passed to opt/llc when cross compiling -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less | Type of failure: than a day) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Currently trying to build an x86_64-linu to arm64-linux cross-compiler. After fixing some code in `rts/StgCRun.c` i ran into an issue where ghc was calling `llc` and generating `x86_64` assembly instead of `aarch64` assembly. For now, I've hacked `compiler/main/SysTools.hs` to add `-mtriple=aarch64 -linux-gnu` to the `opt` and `llc` command lines and that allows me to get a bit further in the compile process. For cross-compiling, passing something like this `-mtriple=...` is pretty much mandatory. I suggest adding it by doing the following: * Add a `crossCompiling :: Bool` field to `DynFlags`. * Add the `-mtriple=...` string to the `sOpt_lo` and `sOpt_lc` fields of `Settings` when we are cross-compiling. * Possibly also store the triple string in the `Platform` struct. Comments? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 18 04:14:26 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Dec 2014 04:14:26 -0000 Subject: [GHC] #9895: No -mtriple param being passed to opt/llc when cross compiling In-Reply-To: <044.a3f80c6c0a5d3377f5d023665058edc9@haskell.org> References: <044.a3f80c6c0a5d3377f5d023665058edc9@haskell.org> Message-ID: <059.ace3d3a23b326d3ea2070a795db213e1@haskell.org> #9895: No -mtriple param being passed to opt/llc when cross compiling -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by erikd): Luite clued me in on the existance of a "settings" file which is read by the function `initSysTools` in the `SysTools` module. Currently the extra options for LLVM's `opt` and `llc` are initialized as: {{{#!hs sOpt_lo = [], sOpt_lc = [], }}} Adding the `-mtriple=...` option here seems the obvious place. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 18 04:23:34 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Dec 2014 04:23:34 -0000 Subject: [GHC] #9895: No -mtriple param being passed to opt/llc when cross compiling In-Reply-To: <044.a3f80c6c0a5d3377f5d023665058edc9@haskell.org> References: <044.a3f80c6c0a5d3377f5d023665058edc9@haskell.org> Message-ID: <059.f150ba71b66bcf76a5404d8dce576e26@haskell.org> #9895: No -mtriple param being passed to opt/llc when cross compiling -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by erikd): Checking the LLVM docs, it seems that `-mtriple=....` is supported at least as far back as LLVM 3.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 18 04:30:34 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Dec 2014 04:30:34 -0000 Subject: [GHC] #9896: panic: wrongKindOfFamily Message-ID: <044.bb60788a54426042f8914c0adf6a6f61@haskell.org> #9896: panic: wrongKindOfFamily -------------------------------------+------------------------------------- Reporter: luite | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The following code panics with GHC HEAD: {{{#!hs {-# LANGUAGE TypeFamilies #-} class Test a where type TestT a :: * instance Test Bool where newtype TestT Bool = Int }}} {{{ $ ghc Panic2.hs [1 of 1] Compiling Main ( Panic2.hs, Panic2.o ) Panic2.hs:7:3:ghc.exe: panic! (the 'impossible' happened) (GHC version 7.9.20141217 for i386-unknown-mingw32): wrongKindOfFamily TestT Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 18 04:55:46 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Dec 2014 04:55:46 -0000 Subject: [GHC] #9897: Couldn't match type `Id (Id Char)' with `Char' Message-ID: <045.2e8944302600e572819c5dcbdcb01e7c@haskell.org> #9897: Couldn't match type `Id (Id Char)' with `Char' -------------------------------------+------------------------------------- Reporter: erisco | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Operating System: Windows Keywords: | Type of failure: GHC Architecture: x86_64 (amd64) | rejects valid program Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- 'foo' is expected to type check given that 'bar' and 'qux' type check. {{{ ghc_bug.hs:21:7: Couldn't match type `Id (Id Char)' with `Char' Expected type: (:.:) Id Id Char Actual type: Char In the expression: 'x' In an equation for `foo': foo = 'x' }}} {{{#!hs {-# LANGUAGE TypeOperators, TypeFamilies #-} module Main where type family (:.:) g f a where (:.:) g f a = g (f a) -- type family Id x where Id x = x -- -- Type checks bar :: Id (Id Char) bar = 'x' -- Type checks qux = 'x' :: (Id :.: Id) Char -- Couldn't match type `Id (Id Char)' with `Char' foo :: (Id :.: Id) Char foo = 'x' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 18 05:02:56 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Dec 2014 05:02:56 -0000 Subject: [GHC] #9898: Couldn't match type `(Char, ())' with `()' Message-ID: <045.8f7b834957773169b7810af17c757a81@haskell.org> #9898: Couldn't match type `(Char, ())' with `()' -------------------------------------+------------------------------------- Reporter: erisco | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Operating System: Windows Keywords: | Type of failure: GHC Architecture: x86_64 (amd64) | rejects valid program Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- 'test3' is expected to type check given that 'test1' and 'test2' type check. 'test4' is not expected to type check. {{{ ghc_bug2.hs:24:9: Couldn't match type `(Char, ())' with `()' Expected type: Filter (Equal Int) (Char, Filter (Equal Int) ()) Actual type: () In the expression: () :: Filter (Equal Int) (Char, Filter (Equal Int) ()) In an equation for `test2': test2 = () :: Filter (Equal Int) (Char, Filter (Equal Int) ()) ghc_bug2.hs:28:9: Couldn't match type `(Char, ())' with `()' Expected type: Filter (Equal Int) (Char, ()) Actual type: () In the expression: () In an equation for `test3': test3 = () }}} {{{#!hs {-# LANGUAGE TypeFamilies, UndecidableInstances, DataKinds #-} module Main where type family Filter f xs where Filter f (x, xs) = ApplyFilter (f x) (x, Filter f xs) Filter f () = () -- type family ApplyFilter p xs where ApplyFilter False (x, xs) = xs ApplyFilter p xs = xs -- type family Equal x y where Equal x x = True Equal x y = False -- -- Type checks test1 :: ApplyFilter ((Equal Int) Char) (Char, Filter (Equal Int) ()) test1 = () -- Couldn't match type `(Char, ())' with `()' test2 = () :: Filter (Equal Int) (Char, Filter (Equal Int) ()) -- Couldn't match type `(Char, ())' with `()' test3 :: Filter (Equal Int) (Char, ()) test3 = () -- Type checks, should not test4 :: Filter (Equal Int) (Char, ()) test4 = ('x', ()) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 18 07:19:48 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Dec 2014 07:19:48 -0000 Subject: [GHC] #9878: Static pointers in GHCi cause panic In-Reply-To: <047.a0b4c5e0dee3f65cf24b644a915474ce@haskell.org> References: <047.a0b4c5e0dee3f65cf24b644a915474ce@haskell.org> Message-ID: <062.39652cfaf5064e667440c971ee2df612@haskell.org> #9878: Static pointers in GHCi cause panic -------------------------------------+------------------------------------- Reporter: monoidal | Owner: facundo.dominguez Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHCi crash | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by mboes): > a) is actually adding support for GHCi and HPC challenging? (if so whats the challenge? Let us help!) This tells me there might be a slight misinterpretation of Facundo's last comment. The point is, -XStaticPointers uses the exact same strategy as hpc for initializing the static pointer table. Insofar as there -XStaticPointers doesn't work in GHCi, it seems to not work for the same reason that hpc does not work. I very much suspect that whatever fix to this issue we find will equally apply to hpc. Should we nonetheless still file a separate bug report for the fact that HPC fails in the same way -XStaticPointers does at the GHCi prompt? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 18 08:19:34 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Dec 2014 08:19:34 -0000 Subject: [GHC] #9896: panic: wrongKindOfFamily In-Reply-To: <044.bb60788a54426042f8914c0adf6a6f61@haskell.org> References: <044.bb60788a54426042f8914c0adf6a6f61@haskell.org> Message-ID: <059.1264ce0f5f0d225dfe2d85c8da6c948b@haskell.org> #9896: panic: wrongKindOfFamily -------------------------------------+------------------------------------- Reporter: luite | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek): A simple fix for this can go into the `Parser.y` by changing second production in `at_decl_inst` from: {{{ -- data/newtype instance declaration | data_or_newtype capi_ctype tycl_hdr constrs deriving {% amms (mkDataFamInst (comb4 $1 $3 $4 $5) (snd $ unLoc $1) $2 $3 Nothing (reverse (snd $ unLoc $4)) (unLoc $5)) ((fst $ unLoc $1):(fst $ unLoc $4)) } }}} to {{{ -- data/newtype instance declaration | 'data' capi_ctype tycl_hdr constrs deriving {% amms (mkDataFamInst (comb4 $1 $3 $4 $5) DataType $2 $3 Nothing (reverse (snd $ unLoc $4)) (unLoc $5)) ((mj AnnData $1):(fst $ unLoc $4)) } }}} Then your definition would be rejected as a parse error. However, on my branch this change drastically increases the number of reduce/reduce conflicts so perhaps a different solution would be better. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 18 10:17:57 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Dec 2014 10:17:57 -0000 Subject: [GHC] #9898: Wanted: higher-order type-level programming (was: Couldn't match type `(Char, ())' with `()') In-Reply-To: <045.8f7b834957773169b7810af17c757a81@haskell.org> References: <045.8f7b834957773169b7810af17c757a81@haskell.org> Message-ID: <060.925796bec163d725a1525398df809eb5@haskell.org> #9898: Wanted: higher-order type-level programming -------------------------------------+------------------------------------- Reporter: erisco | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: (Type checker) | Architecture: x86_64 (amd64) Resolution: | Difficulty: Unknown Operating System: Windows | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * type: bug => feature request Comment: HEAD correctly says {{{ T9898.hs:20:10: Type family ?Equal? should have 2 arguments, but has been given 1 In the type signature for ?test1?: test1 :: ApplyFilter ((Equal Int) Char) (Char, Filter (Equal Int) ()) T9898.hs:27:10: Type family ?Equal? should have 2 arguments, but has been given 1 In the type signature for ?test3?: test3 :: Filter (Equal Int) (Char, ()) T9898.hs:31:10: Type family ?Equal? should have 2 arguments, but has been given 1 In the type signature for ?test4?: test4 :: Filter (Equal Int) (Char, ()) }}} You can't partially apply a type function, I'm afraid. Yes, that limits higher-order programming. Better solutions (that still support type inference) most welcome. I'll leave this open as a feature request for higher order type level programming. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 18 10:19:54 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Dec 2014 10:19:54 -0000 Subject: [GHC] #9897: Couldn't match type `Id (Id Char)' with `Char' In-Reply-To: <045.2e8944302600e572819c5dcbdcb01e7c@haskell.org> References: <045.2e8944302600e572819c5dcbdcb01e7c@haskell.org> Message-ID: <060.e5bb3bb189e2cdf5595186ecd1d6a53f@haskell.org> #9897: Couldn't match type `Id (Id Char)' with `Char' -------------------------------------+------------------------------------- Reporter: erisco | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: Resolution: duplicate | Architecture: x86_64 (amd64) Operating System: Windows | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => duplicate Comment: Same as #9898 I'm afraid. HEAD says {{{ T9897.hs:20:8: Type family ?Id? should have 1 argument, but has been given none In the type signature for ?foo?: foo :: (Id :.: Id) Char }}} So I'll close this as a dup of #9898. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 18 10:24:19 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Dec 2014 10:24:19 -0000 Subject: [GHC] #9899: HEAD: make clean fails to delete libraries/bootstrapping.conf (directory) Message-ID: <048.b22670e5d522ad65bd728cccad384d67@haskell.org> #9899: HEAD: make clean fails to delete libraries/bootstrapping.conf (directory) -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Build System | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- {{{ "rm" -f libraries/bootstrapping.conf libraries/integer- gmp/cbits/GmpDerivedConstants.h libraries/integer- gmp/include/HsIntegerGmp.h libraries/integer-gmp2/include/HsIntegerGmp.h libraries/base/include/EventConfig.h mk/config.mk.old mk/project.mk.old compiler/ghc.cabal.old includes/GHCConstants.h includes/DerivedConstants.h includes/ghcautoconf.h includes/ghcplatform.h includes/ghcversion.h utils /ghc-pkg/Version.hs compiler/prelude/primops.txt rm: cannot remove `libraries/bootstrapping.conf': Is a directory make[1]: *** [clean_files] Error 1 }}} Then I do {{{ rm -r libraries/bootstrapping.conf make clean }}} and this succeeds. Now I build again: {{{ make }}} and get an error: {{{ "inplace/bin/ghc-cabal" configure libraries/binary dist-boot "" --with- ghc="/home/ggreif/bin/ghc" --with-ghc-pkg="/home/ggreif/bin/ghc-pkg" --package-db=/home/ggreif/%NoBackup%/ghc7/ghc-head- x86_64/libraries/bootstrapping.conf --disable-library-for-ghci --enable- library-vanilla --disable-library-profiling --disable-shared --configure- option=CFLAGS=" -fno-stack-protector " --configure-option=LDFLAGS=" " --configure-option=CPPFLAGS=" " --gcc-options=" -fno-stack-protector " --configure-option=--with-gmp-includes="/home/ggreif/include" --constraint "binary == 0.7.2.3" --constraint "Cabal == 1.21.1.0" --constraint "hpc == 0.6.0.2" --constraint "bin-package-db == 0.0.0.0" --constraint "hoopl == 3.10.0.2" --constraint "transformers == 0.4.2.0" --constraint "terminfo == 0.4.0.1" --with-gcc="/usr/bin/gcc" --configure- option=--with-cc="/usr/bin/gcc" --with-ar="/usr/bin/ar" --with- alex="/home/ggreif/bin/alex" --with-happy="/home/ggreif/bin/happy" Configuring binary-0.7.2.3... ghc-cabal: '/home/ggreif/bin/ghc-pkg' exited with an error: ghc-pkg: ghc no longer supports single-file style package databases (/home/ggreif/%NoBackup%/ghc7/ghc-head- x86_64/libraries/bootstrapping.conf) use 'ghc-pkg init' to create the database with the correct format. make[1]: *** [libraries/binary/dist-boot/package-data.mk] Error 1 }}} But the thing is created as a file now: {{{ $ ls -l libraries/bootstrapping.conf -rw-r--r-- 1 ggreif grp 3 Dec 18 11:17 libraries/bootstrapping.conf }}} I can recreate it manually: {{{ $ rm libraries/bootstrapping.conf $ /home/ggreif/bin/ghc-pkg init libraries/bootstrapping.conf $ ls -ld libraries/bootstrapping.conf drwxr-xr-x 2 ggreif grp 96 Dec 18 11:23 libraries/bootstrapping.conf }}} And now `make` works... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 18 11:18:59 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Dec 2014 11:18:59 -0000 Subject: [GHC] #9896: panic: wrongKindOfFamily In-Reply-To: <044.bb60788a54426042f8914c0adf6a6f61@haskell.org> References: <044.bb60788a54426042f8914c0adf6a6f61@haskell.org> Message-ID: <059.c4ae689ff64bda93fd1ce14aefd07dd8@haskell.org> #9896: panic: wrongKindOfFamily -------------------------------------+------------------------------------- Reporter: luite | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"6ec9e958d6a6693dedbcbfc74f164d38e5fb5381/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="6ec9e958d6a6693dedbcbfc74f164d38e5fb5381" Fix wrong-kind-of-family error message (Trac #9896) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 18 11:19:39 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Dec 2014 11:19:39 -0000 Subject: [GHC] #9896: panic: wrongKindOfFamily In-Reply-To: <044.bb60788a54426042f8914c0adf6a6f61@haskell.org> References: <044.bb60788a54426042f8914c0adf6a6f61@haskell.org> Message-ID: <059.50ccaed345d06b49db0648480e731baa@haskell.org> #9896: panic: wrongKindOfFamily -------------------------------------+------------------------------------- Reporter: luite | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: indexed- | types/should_fail/T9896 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => indexed-types/should_fail/T9896 * resolution: => fixed Comment: Thanks for reporting this; fixed. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 18 11:35:40 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Dec 2014 11:35:40 -0000 Subject: [GHC] #8749: Pattern synonyms crash GHCi In-Reply-To: <047.f9f9afc9234eb5051ef30112793358b3@haskell.org> References: <047.f9f9afc9234eb5051ef30112793358b3@haskell.org> Message-ID: <062.a29cf7fdf7ba0cc3813030cd841b094e@haskell.org> #8749: Pattern synonyms crash GHCi -------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: fixed | Keywords: PatternSynonyms Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: 8757 None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by cactus): * keywords: => PatternSynonyms -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 18 11:37:15 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Dec 2014 11:37:15 -0000 Subject: [GHC] #9900: Support pattern synonyms in GHCi Message-ID: <045.62d6509e4b0cfc58e8f6254c0f951369@haskell.org> #9900: Support pattern synonyms in GHCi -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: GHCi | Version: 7.8.3 Keywords: PatternSynonyms | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: 8749, 7253 | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Pattern synonyms are not parsed in GHCi: {{{ ?? :set -XPatternSynonyms ?? pattern P x = x :5:1: parse error on input ?pattern? }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 18 11:37:38 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Dec 2014 11:37:38 -0000 Subject: [GHC] #9900: Support pattern synonyms in GHCi In-Reply-To: <045.62d6509e4b0cfc58e8f6254c0f951369@haskell.org> References: <045.62d6509e4b0cfc58e8f6254c0f951369@haskell.org> Message-ID: <060.7c876192dbcabbfb1b926ee93761091e@haskell.org> #9900: Support pattern synonyms in GHCi -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.8.3 Component: GHCi | Keywords: PatternSynonyms Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: 8749 7253 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by cactus): * related: 8749, 7253 => 8749 7253 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 18 11:37:51 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Dec 2014 11:37:51 -0000 Subject: [GHC] #9900: Support pattern synonyms in GHCi In-Reply-To: <045.62d6509e4b0cfc58e8f6254c0f951369@haskell.org> References: <045.62d6509e4b0cfc58e8f6254c0f951369@haskell.org> Message-ID: <060.8ce0951dd279fff345c05457ed48557a@haskell.org> #9900: Support pattern synonyms in GHCi -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.8.3 Component: GHCi | Keywords: PatternSynonyms Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #8749, #7253 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by cactus): * related: 8749 7253 => #8749, #7253 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 18 12:38:43 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Dec 2014 12:38:43 -0000 Subject: [GHC] #9898: Wanted: higher-order type-level programming In-Reply-To: <045.8f7b834957773169b7810af17c757a81@haskell.org> References: <045.8f7b834957773169b7810af17c757a81@haskell.org> Message-ID: <060.ad0afc64b8ae094f48293e3a89c107ce@haskell.org> #9898: Wanted: higher-order type-level programming -------------------------------------+------------------------------------- Reporter: erisco | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: (Type checker) | Architecture: x86_64 (amd64) Resolution: | Difficulty: Unknown Operating System: Windows | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by erisco): Thanks Simon. I was mislead by the problem reported in issue #9433. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 18 12:52:02 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Dec 2014 12:52:02 -0000 Subject: [GHC] #9901: Error message: f is applied to two arguments, but its type has only two (sic) Message-ID: <045.20460e93a0bca4214189c85bc9425d02@haskell.org> #9901: Error message: f is applied to two arguments, but its type has only two (sic) -------------------------------------+------------------------------------- Reporter: zardoz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I occasionally get type errors where the error message refers to a function?s arity in a contradictory way: > The function ?X? is applied to two arguments, [?] but its type has only two. Here?s a full error message of this kind: lenstest.hs:89:12: Couldn't match type ?Either String Int? with ?Maybe b0? Expected type: [Char] -> Either String Int Actual type: [Char] -> Maybe b0 The function ?preview? is applied to two arguments, but its type ?Getting (Data.Monoid.First b0) (Either b0 c0) b0 -> [Char] -> Maybe b0? has only two In the second argument of ?($)?, namely ?(preview _Left "abc" :: Either String Int)? In a stmt of a 'do' block: print $ (preview _Left "abc" :: Either String Int) Failed, modules loaded: none. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 18 14:46:40 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Dec 2014 14:46:40 -0000 Subject: [GHC] #9901: Error message: f is applied to two arguments, but its type has only two (sic) In-Reply-To: <045.20460e93a0bca4214189c85bc9425d02@haskell.org> References: <045.20460e93a0bca4214189c85bc9425d02@haskell.org> Message-ID: <060.311e7d0fb885bf9cc344c06725b15b37@haskell.org> #9901: Error message: f is applied to two arguments, but its type has only two (sic) -------------------------------------+------------------------------------- Reporter: zardoz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Would you care to give a test case? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 18 14:59:16 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Dec 2014 14:59:16 -0000 Subject: [GHC] #9901: Error message: f is applied to two arguments, but its type has only two (sic) In-Reply-To: <045.20460e93a0bca4214189c85bc9425d02@haskell.org> References: <045.20460e93a0bca4214189c85bc9425d02@haskell.org> Message-ID: <060.9af736129de94b903eb445dcd180e7e9@haskell.org> #9901: Error message: f is applied to two arguments, but its type has only two (sic) -------------------------------------+------------------------------------- Reporter: zardoz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Yuras): It is hard to tell exactly without test case, but I'm almost sure it is a duplicate of #9605 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 18 16:37:08 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Dec 2014 16:37:08 -0000 Subject: [GHC] #9902: Type family, pattern not matching Message-ID: <045.b6886228ede24485f69f48c677b83a9f@haskell.org> #9902: Type family, pattern not matching -------------------------------------+------------------------------------- Reporter: erisco | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Operating System: MacOS X Keywords: | Type of failure: GHC Architecture: x86_64 (amd64) | rejects valid program Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- This is a follow up to issue #9898. The partially applied type families have been eliminated yet type checking is still failing. It is expected that 'test1' infer as `(Char, ())` but it does not. It seems that GHC is not matching the correct pattern on `:$:`. 'test3' and 'test4' indicate that GHC sometimes matches the correct pattern. 'test2' demonstrates an inconsistency between type checking with GHC and the type checking that occurs when the same expression is entered in GHCi. I do not know if this is a related problem. Enabling AllowAmbiguousTypes suggests it might be related because the compiler then complains `ApplyFilter (ToBool ((:.:) Not (Equal Char) Char)) (Char, ())` cannot be unified with `()` (With the second `:$:` rule enabled). Reported type of 'test1' with second rule removed {{{ test1 :: (Char, ApplyFilter (ToBool ((Not :.: Equal Char) :$: Char)) (Char, ())) }}} Reported type of 'test1' with second rule added {{{ test1 :: (Char, ApplyFilter (ToBool ((:.:) Not (Equal Char) Char)) (Char, ())) }}} test2 type check error {{{ ghc_bug3.hs:38:15: Couldn't match expected type ?ApplyFilter (ToBool ((Not :.: Equal Char) :$: Char)) (Char, ())? with actual type ?ApplyFilter (ToBool ((Not :.: Equal Char) :$: Char)) (Char, ())? NB: ?ApplyFilter? is a type function, and may not be injective The type variables ?k0?, ?k1?, ?k2? are ambiguous In the ambiguity check for: forall (k :: BOX) (k1 :: BOX) (k2 :: BOX). ApplyFilter (ToBool ((Not :.: Equal Char) :$: Char)) (Char, ()) To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In an expression type signature: ApplyFilter (ToBool ((Not :.: Equal Char) :$: Char)) (Char, ()) In the expression: () :: ApplyFilter (ToBool ((Not :.: Equal Char) :$: Char)) (Char, ()) }}} {{{#!hs {-# LANGUAGE TypeFamilies, GADTs, DataKinds, UndecidableInstances, TypeOperators, PolyKinds #-} module Main where data Equal x y data Not x type family ToBool x where ToBool (Equal x x) = True ToBool (Equal x y) = False ToBool (Not True) = False ToBool (Not False) = True ToBool (Not p) = ToBool (Not (ToBool p)) data (:.:) g f x infixr 9 :.: type family f :$: x where (g :.: f) :$: x = g (f x) -- Uncomment to see change in 'test1' -- f :$: x = f x type family Filter f l where Filter f (x, xs) = ApplyFilter (ToBool (f :$: x)) (x, Filter f xs) Filter f () = () type family ApplyFilter p xs where ApplyFilter False (x, xs) = xs ApplyFilter p xs = xs type family xs :+: ys where (x, xs) :+: ys = (x, xs :+: Filter (Not :.: Equal x) ys) () :+: ys = ys infixl 5 :+: test1 = undefined :: (Char, ()) :+: (Char, ()) -- Typing this into GHCi works fine, but here does not type check. test2 = () :: ApplyFilter (ToBool ((Not :.: Equal Char) :$: Char)) (Char, ()) -- Type checks (with second rule added) test3 :: Maybe :$: Int test3 = Just 5 -- Type checks test4 :: (Maybe :.: Maybe) :$: Int test4 = Just (Just 5) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 18 17:25:49 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Dec 2014 17:25:49 -0000 Subject: [GHC] #9902: Type family, pattern not matching In-Reply-To: <045.b6886228ede24485f69f48c677b83a9f@haskell.org> References: <045.b6886228ede24485f69f48c677b83a9f@haskell.org> Message-ID: <060.015c36d49800cdd3c05ba8c30886e64e@haskell.org> #9902: Type family, pattern not matching -------------------------------------+------------------------------------- Reporter: erisco | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: Resolution: invalid | Architecture: x86_64 (amd64) Operating System: MacOS X | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => invalid Comment: Your problem is that `(:.:)` is too polymorphic. Try this: {{{ data (:.:) (g :: kb -> *) (f :: ka -> kb) (x :: ka) }}} Then I think everything works. As you have it, `(:.:)` has kind {{{ (:.:) :: forall k1 k1 k3. k1 -> k2 -> k3 -> * }}} When you use it on the RHS of the first equation of `(:+:)`, the kinds of the RHS are not fully determined, so you get `AnyK`. Try using `-fprint-explicit-kinds` to see all this. Do re-open if you think there's a bug. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 18 17:55:54 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Dec 2014 17:55:54 -0000 Subject: [GHC] #9898: Wanted: higher-order type-level programming In-Reply-To: <045.8f7b834957773169b7810af17c757a81@haskell.org> References: <045.8f7b834957773169b7810af17c757a81@haskell.org> Message-ID: <060.2da8c2bf4c6c4ecf89122d3e41925d23@haskell.org> #9898: Wanted: higher-order type-level programming -------------------------------------+------------------------------------- Reporter: erisco | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: (Type checker) | Architecture: x86_64 (amd64) Resolution: | Difficulty: Unknown Operating System: Windows | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): Though I'm all for fixing this so that it's possible in GHC, you may also want to check out the `singletons` package, which goes to lengths to emulate this feature. See also the related paper [http://www.cis.upenn.edu/~eir/papers/2014/promotion/promotion.pdf here]. One of these years, I hope to push for adoption of some of the ideas from that paper into GHC proper -- without defunctionalization, for sure. See sections 7.2 and 7.5. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 18 18:25:58 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Dec 2014 18:25:58 -0000 Subject: [GHC] #9902: Type family, pattern not matching In-Reply-To: <045.b6886228ede24485f69f48c677b83a9f@haskell.org> References: <045.b6886228ede24485f69f48c677b83a9f@haskell.org> Message-ID: <060.86db2380e5e34e9fcfd4df8ae0ce4bfc@haskell.org> #9902: Type family, pattern not matching -------------------------------------+------------------------------------- Reporter: erisco | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: Resolution: invalid | Architecture: x86_64 (amd64) Operating System: MacOS X | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by erisco): Thanks Simon I see the issue now. Sorry to be using the bug tracker as a Q&A rather than reporting real bugs. There seems to be a limited number of people with knowledge of type level programming on #haskell which is where I go for help. Also, it has been too easy to mistakenly apply familiarities seen at the value level and has resulted in much of the confusion. I was under the impression that the correct kinds for `:.:` would be inferred because a solution exists, rather than giving an error, but that does not appear to be the case then. Will inference generally happen from innermost to outermost without backtracking? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 18 19:57:06 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Dec 2014 19:57:06 -0000 Subject: [GHC] #8732: Global big object heap allocator lock causes contention In-Reply-To: <044.a362245e1caab544f39c02e92f1f1660@haskell.org> References: <044.a362245e1caab544f39c02e92f1f1660@haskell.org> Message-ID: <059.4b8662b1ffa9c3878e9bd564ddcd2de1@haskell.org> #8732: Global big object heap allocator lock causes contention -------------------------------------+------------------------------------- Reporter: tibbe | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime | Version: 7.6.3 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by ezyang): carter: contiguous heap has not been merged in, and it doesn't really help for this problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 18 22:24:08 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Dec 2014 22:24:08 -0000 Subject: [GHC] #9895: No -mtriple param being passed to opt/llc when cross compiling In-Reply-To: <044.a3f80c6c0a5d3377f5d023665058edc9@haskell.org> References: <044.a3f80c6c0a5d3377f5d023665058edc9@haskell.org> Message-ID: <059.10303af154e6c17808b71b80e2f46721@haskell.org> #9895: No -mtriple param being passed to opt/llc when cross compiling -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: D576 | -------------------------------------+------------------------------------- Changes (by erikd): * status: new => patch * differential: => D576 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 19 01:55:40 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Dec 2014 01:55:40 -0000 Subject: [GHC] #9898: Wanted: higher-order type-level programming In-Reply-To: <045.8f7b834957773169b7810af17c757a81@haskell.org> References: <045.8f7b834957773169b7810af17c757a81@haskell.org> Message-ID: <060.4f193b5356fc2e5062588fd0babeac66@haskell.org> #9898: Wanted: higher-order type-level programming -------------------------------------+------------------------------------- Reporter: erisco | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: (Type checker) | Architecture: x86_64 (amd64) Resolution: | Difficulty: Unknown Operating System: Windows | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by erisco): Does applying a type family to no arguments count as being partially applied? i.e. will such usage be banned n 7.8.4? So far 7.8.3 seems to make correct inferences in such cases. If this breaks in 7.8.4 I would like to know so that I do not write a lot of code that depends on it. Compiling GHC does not appear to be a small task otherwise I would test it myself. Here is an example where it is relevant. Maybe there is a better implementation. A usage may be `F EvalEqual :. F (Equal Int) :: Fun * Bool` which can then be used as a predicate for filtering a type list, for example. Of course a possible problem is that `EvalEqual` may be considered partially applied and rejected by 7.8.4 even though this appears to work fine in 7.8.3 (i.e. inference appears to be working fine). {{{ data Equal' where Equal :: x -> y -> Equal' type family EvalEqual (x :: Equal') :: Bool where EvalEqual (Equal x x) = True EvalEqual (Equal x y) = False }}} For completeness here are the other definitions, and I include `:$` as well. Not sure if this is the way to do function composition but this is the best I have after a few failed attempts. {{{ data Fun a b where F :: (a -> b) -> Fun a b (.:) :: Fun b c -> Fun a b -> Fun a c type family (f :: Fun ka kb) :$ (x :: ka) where (f .: g) :$ x = g :$ (f :$ x) (F f) :$ x = f x }}} What is a good place for Q&A on type level programming in Haskell? Obviously the GHC bug tracker is not it. I have tried the #haskell IRC channel but there are only a few people there that understand this area and I can seldom get their attention. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 19 01:57:24 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Dec 2014 01:57:24 -0000 Subject: [GHC] #9878: Static pointers in GHCi cause panic In-Reply-To: <047.a0b4c5e0dee3f65cf24b644a915474ce@haskell.org> References: <047.a0b4c5e0dee3f65cf24b644a915474ce@haskell.org> Message-ID: <062.87629590c2df7455e51b51bf55abf1a5@haskell.org> #9878: Static pointers in GHCi cause panic -------------------------------------+------------------------------------- Reporter: monoidal | Owner: facundo.dominguez Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHCi crash | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by facundo.dominguez): My plan to address this issue would be as follows: * In the renamer, try to infer from dflags whether ghci is compiling bytecode and reject the static form. * Integrate Alexander's patch to fix {{{hs_spt_keys}}}. * Document the unavailability of static forms for bytecode. The API in GHC.StaticPtr is not designed to support dynamic loading. We would need to make lookups and staticPtrKeys monadic. It's doable but it needs green lights from SPJ and Mathieu. Then we need to decide what to do with the SPT implementation. To make it thread-safe we can use a readers-writer lock implemented with mutexes, or maybe someone can suggest a better alternative. -- end of plan -- In addition, if you really want to support static pointers when compiling bytecode, then the question is how to link the {{{_stubs.c}}} files produced by StaticPointers which contain external symbols expected to be defined as top-level values in the corresponding modules. One possibility is to discard the stub file when in GHCi, and have GHCi call hs_spt_insert directly after linking a module. Another alternative is to modify the stub to get the pointers to the top- level functions of the module in some other way. I know nothing of how GHCi links the bytecode. Someone else would have to comment if these ideas have any legs. -- end of comments for StaticPointers -- HPC may need a different solution. The external symbol which appears in {{{stub.c}}} is produced at the C-- level, so it would not have a byte- code incarnation as top-level values do for StaticPointers. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 19 02:10:25 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Dec 2014 02:10:25 -0000 Subject: [GHC] #9903: GHCi produces a cryptic message when using HPC Message-ID: <056.3163ec769e71b713310f29b6c2e4fa48@haskell.org> #9903: GHCi produces a cryptic message when using HPC -------------------------------------+------------------------------------- Reporter: facundo.dominguez | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.9 Keywords: hpc | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: GHCi crash Blocked By: | Test Case: Related Tickets: #9878, #9762 ? | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The following test produces an impolite response from GHCi {{{ $ cat t.hs g :: Int g = 1 + 1 $ ghc-stage2 --interactive t.hs -fhpc GHCi, version 7.9.20141217: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( t.hs, interpreted ) Ok, modules loaded: Main. *Main> g ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.9.20141217 for x86_64-unknown-linux): Loading temp shared object failed: /tmp/ghc25774_0/ghc25774_5.so: undefined symbol: _hpc_tickboxes_Main_hpc Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} It has been noted elsewhere (#9878) that these kinds of messages are better avoided. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 19 05:18:16 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Dec 2014 05:18:16 -0000 Subject: [GHC] #9904: ghc: out of memory, requested 1048576 bytes on openbsd Message-ID: <045.d32cbdc44e8af12b00d61e76d86031a6@haskell.org> #9904: ghc: out of memory, requested 1048576 bytes on openbsd ------------------------------------+---------------------------------- Reporter: vu3rdd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: cabal-install | Operating System: OpenBSD Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ------------------------------------+---------------------------------- Hi, I freshly installed OpenBSD 5.6 on an AMD64 system. I also installed ghc and cabal-install from the OpenBSD package system. The version in OpenBSD 5.6 package tree is: $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.6.3 $ cabal --version cabal-install version 1.16.0.2 using version 1.16.0 of the Cabal library Now, I do a `cabal update' and `cabal install cabal-install'. I get this error: ghc: out of memory, requested 1048576 bytes I am not sure if it is a cabal-install bug or a ghc bug or an OpenBSD bug. So, if you think it is not a ghc bug, please go ahead and close this bug (and accept my apologies..), I will open it against cabal-install or openbsd instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 19 05:47:53 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Dec 2014 05:47:53 -0000 Subject: [GHC] #9049: Expose srcLoc from the assertion architecture to allow better error messages In-Reply-To: <042.a0d4c757be085a0284ebca147547b4f3@haskell.org> References: <042.a0d4c757be085a0284ebca147547b4f3@haskell.org> Message-ID: <057.f22c2a56ddbc9d3c6f99a6d7ffa2745f@haskell.org> #9049: Expose srcLoc from the assertion architecture to allow better error messages -------------------------------------+------------------------------------- Reporter: nh2 | Owner: gridaphobe Type: feature | Status: patch request | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D578 | -------------------------------------+------------------------------------- Changes (by gridaphobe): * status: new => patch * differential: => Phab:D578 Comment: I've sent a patch that implements [wiki:ExplicitCallStack/ImplicitLocations] to Phab (https://phabricator.haskell.org/D578). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 19 06:44:38 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Dec 2014 06:44:38 -0000 Subject: [GHC] #9865: Comonads in base library In-Reply-To: <050.1aeed8f93bd414fa38dcb5213e8076cb@haskell.org> References: <050.1aeed8f93bd414fa38dcb5213e8076cb@haskell.org> Message-ID: <065.915fc7e96315fa4096712927780898ea@haskell.org> #9865: Comonads in base library -------------------------------------+------------------------------------- Reporter: | Owner: ekmett spacekitteh | Status: new Type: feature | Milestone: 7.12.1 request | Version: Priority: normal | Keywords: Component: Core | Architecture: Unknown/Multiple Libraries | Difficulty: Easy (less than 1 Resolution: | hour) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by ekmett): This really should be submitted to the libraries at haskell.org mailing list as a formal proposal if you want to see it move forward. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 19 06:58:37 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Dec 2014 06:58:37 -0000 Subject: [GHC] #9905: ghc-7.8.x command line error Message-ID: <049.b40fd88ea54ea4f681922f4cf3395d55@haskell.org> #9905: ghc-7.8.x command line error -------------------------------------+------------------------------------- Reporter: zRecursive | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: FreeBSD Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- `$ghc -e "import Data.List" -e "print 9"` will not output 9 but `ghc -e "print 9"` works normally. However, both commands work on ghc-7.6.x. Regards! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 19 08:41:21 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Dec 2014 08:41:21 -0000 Subject: [GHC] #9878: Static pointers in GHCi cause panic In-Reply-To: <047.a0b4c5e0dee3f65cf24b644a915474ce@haskell.org> References: <047.a0b4c5e0dee3f65cf24b644a915474ce@haskell.org> Message-ID: <062.ef76d407169168e692589f5f37829980@haskell.org> #9878: Static pointers in GHCi cause panic -------------------------------------+------------------------------------- Reporter: monoidal | Owner: facundo.dominguez Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHCi crash | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by mboes): > Then we need to decide what to do with the SPT implementation. To make it thread-safe we can use a readers-writer lock implemented with mutexes, or maybe someone can suggest a better alternative. -XStaticPointers is limited to the following use case: the universe of static forms that exist in the program is fixed at compile time and constant throughout the lifetime of the program. Using the `static` keyword inside GHCi does not fit this assumption, nor does dynamic (runtime) code linking. So the more pressing question is, in the original intended use case, are there ever concurrent updates to the SPT? That is, does module initialization happen concurrently at runtime? If not, then let's keep it simple... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 19 09:05:14 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Dec 2014 09:05:14 -0000 Subject: [GHC] #9878: Static pointers in GHCi cause panic In-Reply-To: <047.a0b4c5e0dee3f65cf24b644a915474ce@haskell.org> References: <047.a0b4c5e0dee3f65cf24b644a915474ce@haskell.org> Message-ID: <062.b84f8cdc34ed13b7ba0858121da19839@haskell.org> #9878: Static pointers in GHCi cause panic -------------------------------------+------------------------------------- Reporter: monoidal | Owner: facundo.dominguez Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHCi crash | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by mboes): > the universe of static forms that exist in the program is fixed at compile time and constant throughout the lifetime of the program. BTW, the current type for `deRefStaticPtr` is borne out of this assumption. If this assumption must be dropped, then `deRefStaticPtr` must be put in the `IO` monad. That is, its type should become: {{{ deRefStaticPtr :: ... -> IO (StaticPtr a) }}} I'm not sure this is desirable. As I recall Simon PJ was also keen to keep `deRefStaticPtr` pure. So this design decision could be revised, but I for one would prefer to see how people really use the extension first. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 19 09:36:11 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Dec 2014 09:36:11 -0000 Subject: [GHC] #9905: ghc-7.8.x command line error In-Reply-To: <049.b40fd88ea54ea4f681922f4cf3395d55@haskell.org> References: <049.b40fd88ea54ea4f681922f4cf3395d55@haskell.org> Message-ID: <064.d22a181e62a0347a596003054d2df002@haskell.org> #9905: ghc-7.8.x command line error -------------------------------------+------------------------------------- Reporter: zRecursive | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: FreeBSD | Architecture: Unknown/Multiple Type of failure: | Difficulty: Unknown None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by pgj): Is this unique to FreeBSD? Does not the same happens on other platforms? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 19 09:39:20 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Dec 2014 09:39:20 -0000 Subject: [GHC] #9906: Warning generated by hscpp code have unhelpful file names Message-ID: <044.c0b2b77cfbe1caa145f66f9718cb9575@haskell.org> #9906: Warning generated by hscpp code have unhelpful file names -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I've started seeing this when compiling cabal with 7.8.3: {{{ [64 of 80] Compiling Distribution.Simple.GHC ( Distribution/Simple/GHC.hs, dist/build/Distribution/Simple/GHC.o ) /var/folders/00/0__yr000h01000cxqpysvccm0019bv/T/ghc43003_0/ghc43003_30.hscpp:270:1: Warning: The import of ?LibraryName? from module ?Distribution.Simple.LocalBuildInfo? is redundant /var/folders/00/0__yr000h01000cxqpysvccm0019bv/T/ghc43003_0/ghc43003_30.hscpp:308:1: Warning: The import of ?Language? from module ?Language.Haskell.Extension? is redundant /var/folders/00/0__yr000h01000cxqpysvccm0019bv/T/ghc43003_0/ghc43003_30.hscpp:318:1: Warning: The import of ?getTemporaryDirectory, getDirectoryContents? from module ?System.Directory? is redundant /var/folders/00/0__yr000h01000cxqpysvccm0019bv/T/ghc43003_0/ghc43003_30.hscpp:325:1: Warning: The import of ?System.IO? is redundant except perhaps to import instances from ?System.IO? To import instances alone, use: import System.IO() /var/folders/00/0__yr000h01000cxqpysvccm0019bv/T/ghc43003_0/ghc43003_30.hscpp:1092:5: Warning: Pattern match(es) are non-exhaustive In an equation for ?supportRPaths?: Patterns not matched: Ghcjs [65 of 80] Compiling Distribution.Simple.GHCJS ( Distribution/Simple/GHCJS.hs, dist/build/Distribution/Simple/GHCJS.o ) }}} The `/var/folders/00/0__yr000h01000cxqpysvccm0019bv/T/ghc43003_0/ghc43003_30.hscpp` file name isn't really helpful. I haven't seen this before so I'm guessing this is a regression. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 19 09:48:21 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Dec 2014 09:48:21 -0000 Subject: [GHC] #9878: Static pointers in GHCi cause panic In-Reply-To: <047.a0b4c5e0dee3f65cf24b644a915474ce@haskell.org> References: <047.a0b4c5e0dee3f65cf24b644a915474ce@haskell.org> Message-ID: <062.41e84c30aed6ab292f8701b6532b91f6@haskell.org> #9878: Static pointers in GHCi cause panic -------------------------------------+------------------------------------- Reporter: monoidal | Owner: facundo.dominguez Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHCi crash | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Let's follow Facundo's plan. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 19 10:18:30 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Dec 2014 10:18:30 -0000 Subject: [GHC] #9903: GHCi produces a cryptic message when using HPC In-Reply-To: <056.3163ec769e71b713310f29b6c2e4fa48@haskell.org> References: <056.3163ec769e71b713310f29b6c2e4fa48@haskell.org> Message-ID: <071.d7aa8ee270cc3ae2d0fe20e315e55515@haskell.org> #9903: GHCi produces a cryptic message when using HPC -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | Status: new Type: bug | Milestone: Priority: normal | Version: 7.9 Component: GHCi | Keywords: hpc Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHCi crash | Related Tickets: #9878, #9762 ? Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Description changed by facundo.dominguez: Old description: > The following test produces an impolite response from GHCi > > {{{ > $ cat t.hs > g :: Int > g = 1 + 1 > $ ghc-stage2 --interactive t.hs -fhpc > GHCi, version 7.9.20141217: http://www.haskell.org/ghc/ :? for help > [1 of 1] Compiling Main ( t.hs, interpreted ) > Ok, modules loaded: Main. > *Main> g > ghc-stage2: panic! (the 'impossible' happened) > (GHC version 7.9.20141217 for x86_64-unknown-linux): > Loading temp shared object failed: /tmp/ghc25774_0/ghc25774_5.so: > undefined symbol: _hpc_tickboxes_Main_hpc > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} > It has been noted elsewhere (#9878) that these kinds of messages are > better avoided. New description: The following test produces an impolite response from GHCi {{{ $ cat t.hs g :: Int g = 1 + 1 $ ghc-stage2 --interactive t.hs -fhpc GHCi, version 7.9.20141217: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( t.hs, interpreted ) Ok, modules loaded: Main. *Main> g ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.9.20141217 for x86_64-unknown-linux): Loading temp shared object failed: /tmp/ghc25774_0/ghc25774_5.so: undefined symbol: _hpc_tickboxes_Main_hpc Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Discovered while investigating #9878. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 19 12:12:29 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Dec 2014 12:12:29 -0000 Subject: [GHC] #2496: Invalid Eq/Ord instances in Data.Version In-Reply-To: <044.b515c7a01d17e019028e237b73b96edc@haskell.org> References: <044.b515c7a01d17e019028e237b73b96edc@haskell.org> Message-ID: <059.2f683eb36f47e7c54b58bff07578a31c@haskell.org> #2496: Invalid Eq/Ord instances in Data.Version -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Core | Version: 6.8.3 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D395 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"5b8fa46ca37caa9ec83b217a697628135da34506/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5b8fa46ca37caa9ec83b217a697628135da34506" Add Data.Version.makeVersion & `IsList Version` These two facilities provide some means to avoid the double-breakage caused by first by the deprecation (see #2496), and then again by the actual future field-removal. See also https://groups.google.com/d/msg/haskell-core-libraries/q9H- QlL_gnE/4lbb_mBjre8J for details about this library addition. Reviewed By: ekmett Differential Revision: https://phabricator.haskell.org/D577 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 19 12:29:34 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Dec 2014 12:29:34 -0000 Subject: [GHC] #9898: Wanted: higher-order type-level programming In-Reply-To: <045.8f7b834957773169b7810af17c757a81@haskell.org> References: <045.8f7b834957773169b7810af17c757a81@haskell.org> Message-ID: <060.5e9d0ff4356f8dff3a78bab559bf5e37@haskell.org> #9898: Wanted: higher-order type-level programming -------------------------------------+------------------------------------- Reporter: erisco | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: (Type checker) | Architecture: x86_64 (amd64) Resolution: | Difficulty: Unknown Operating System: Windows | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek): > Does applying a type family to no arguments count as being partially applied? Yes. To be more precise: you can't have *unsaturated* type families, where unsaturated means "applied to less arguments than it's arity". > will such usage be banned n 7.8.4? No. But that's still a bug and you shouldn't construct your code around this. > What is a good place for Q&A on type level programming in Haskell? Haskell-cafe. If you really want partial application at the type level you can try out `singletons`, as suggested by Richard. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 19 12:40:25 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Dec 2014 12:40:25 -0000 Subject: [GHC] #9213: Maybe important CPP warnings on ghcautoconf.h from cpphs In-Reply-To: <042.40c8fe49091f5227ff0b9eb0ac8fb5d0@haskell.org> References: <042.40c8fe49091f5227ff0b9eb0ac8fb5d0@haskell.org> Message-ID: <057.0f94d5b0510011b13f3cff517344f453@haskell.org> #9213: Maybe important CPP warnings on ghcautoconf.h from cpphs -------------------------------------+------------------------------------- Reporter: asr | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.4-rc1 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by asr): * version: 7.8.3 => 7.8.4-rc1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 19 12:41:55 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Dec 2014 12:41:55 -0000 Subject: [GHC] #9213: Maybe important CPP warnings on ghcautoconf.h from cpphs In-Reply-To: <042.40c8fe49091f5227ff0b9eb0ac8fb5d0@haskell.org> References: <042.40c8fe49091f5227ff0b9eb0ac8fb5d0@haskell.org> Message-ID: <057.c59937164ea626b2616bfc6aacdaebc4@haskell.org> #9213: Maybe important CPP warnings on ghcautoconf.h from cpphs -------------------------------------+------------------------------------- Reporter: asr | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.4-rc1 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Description changed by asr: Old description: > cpphs 1.18.5 yields the following warning: > > {{{ > Warning: trailing characters after #if directive in file ... > /ghcautoconf.h at line 383 col 1: AC_APPLE_UNIVERSAL_BUILD > }}} > > I guess it is necessary to replace `#if defined` by `#ifdef` in the line > {{{ > #if defined AC_APPLE_UNIVERSAL_BUILD > }}} > from the mk/config.h.in file. > > Note the next line > {{{ > # if defined __BIG_ENDIAN__ > }}} > has the same issue. New description: cpphs 1.18.6 yields the following warning: {{{ Warning: trailing characters after #if directive in file ... /ghcautoconf.h at line 383 col 1: AC_APPLE_UNIVERSAL_BUILD }}} I guess it is necessary to replace `#if defined` by `#ifdef` in the line {{{ #if defined AC_APPLE_UNIVERSAL_BUILD }}} from the mk/config.h.in file. Note the next line {{{ # if defined __BIG_ENDIAN__ }}} has the same issue. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 19 14:41:58 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Dec 2014 14:41:58 -0000 Subject: [GHC] #9907: "Unknown PEi386 section name `.text$printf'" error in GHCi on Windows Message-ID: <051.9bd9875fb01e6198fe81abe3cec3e53a@haskell.org> #9907: "Unknown PEi386 section name `.text$printf'" error in GHCi on Windows ----------------------------------+------------------------------------- Reporter: mmikolajczyk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------+------------------------------------- I work on a Haskell library interfacing with foreign C++ library. While trying to use it in GHCi on Windows 8.1 64bit, I encountered an error message that said: {{{ Loading package library-0.1.0.0 ... : Unknown PEi386 section name ` .text$_ZNSt6vectorIcSaIcEED1Ev' (while processing: c:\path\to\file.o) ghc.exe: panic! (the 'impossible' happened) (GHC version 7.8.3 for i386-unknown-mingw32): loadObj "C:\\path\\to\\file.o": failed Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I've prepared a minimal example triggering this bug and attached it to this bug report. On Linux (Arch 64bit), after cabal build and cabal repl it behaves as intended: {{{ GHCi, version 7.8.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading object (static) dist/build/cbits/ex.o ... done final link ... done [1 of 1] Compiling Example ( Example.hs, interpreted ) Ok, modules loaded: Example. ?: foo Test }}} However, on Windows 8.1 it crashes while loading object file: {{{ GHCi, version 7.8.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading object (static) dist\build\cbits\ex.o ... ghc.exe: Unknown PEi386 sectio n name `.text$printf' (while processing: dist\build\cbits\ex.o) ghc.exe: panic! (the 'impossible' happened) (GHC version 7.8.3 for i386-unknown-mingw32): loadObj "dist\\build\\cbits\\ex.o": failed Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Crashing in GHCi means that I cannot use it with programs that contain TH splices, what is important for me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 19 14:51:32 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Dec 2014 14:51:32 -0000 Subject: [GHC] #9872: Runing type functions is too slow In-Reply-To: <046.39f8cd7bfe0ce27cb6afb75f2059ad40@haskell.org> References: <046.39f8cd7bfe0ce27cb6afb75f2059ad40@haskell.org> Message-ID: <061.d2f2b8991a3d8703db0f43f6122a3a1e@haskell.org> #9872: Runing type functions is too slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek): I mentioned on ghc-devs that I witnessed exponential compile times for type families. I just built the latest HEAD and I see that the problem is gone. With my test case I get the following dependency between input size and compile time: ||= Input size =||= GHC 7.8.4 RC1 =||= GHC HEAD || || 64 || 1.2s || 0.6s || || 128 || 11.1s || 1.3s || || 256 || 1m41s || 3.7s || Compiling with GHC 7.8.4 required passing `-ftype-function-depth=1000` (perhaps a smaller value would work, but the default one was too low). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 19 14:54:15 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Dec 2014 14:54:15 -0000 Subject: [GHC] #9872: Runing type functions is too slow In-Reply-To: <046.39f8cd7bfe0ce27cb6afb75f2059ad40@haskell.org> References: <046.39f8cd7bfe0ce27cb6afb75f2059ad40@haskell.org> Message-ID: <061.9a9aae5fcc304238f3884b3c4bc34a5b@haskell.org> #9872: Runing type functions is too slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): What is "my test case"? Perhaps we can add it to the `perf/compiler` tests? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 19 15:01:44 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Dec 2014 15:01:44 -0000 Subject: [GHC] #9872: Runing type functions is too slow In-Reply-To: <046.39f8cd7bfe0ce27cb6afb75f2059ad40@haskell.org> References: <046.39f8cd7bfe0ce27cb6afb75f2059ad40@haskell.org> Message-ID: <061.db660ab9d94f1bceba5fb32cf4c6eac4@haskell.org> #9872: Runing type functions is too slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek): Attached. It's generated automatically using Template Haskell so it's a bit messy. I was planning to clean it up a but that required more time that I had at my disposal :-( -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 19 15:02:11 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Dec 2014 15:02:11 -0000 Subject: [GHC] #8984: Improve output of failed GeneralizedNewtypeDeriving coercion due to type roles In-Reply-To: <044.9146c0f21c1d5c0ac4fad078a63640bb@haskell.org> References: <044.9146c0f21c1d5c0ac4fad078a63640bb@haskell.org> Message-ID: <059.c1f9ea7590f9a846053d1a7fc677e037@haskell.org> #8984: Improve output of failed GeneralizedNewtypeDeriving coercion due to type roles -------------------------------------+------------------------------------- Reporter: haasn | Owner: goldfire Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.1 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | deriving/should_fail/T8984 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"02b4845e07ef7110b2f735f323eb8748903330ff/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="02b4845e07ef7110b2f735f323eb8748903330ff" Consider equality contexts exotic, uninferrable by "deriving" See comments in #8984. This takes back the fix for #6088. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 19 15:02:11 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Dec 2014 15:02:11 -0000 Subject: [GHC] #6088: GeneralizedNewtypeDeriving + TypeFamilies + Equality constraints In-Reply-To: <046.1266b675873dc380465a9fe1f33ad29a@haskell.org> References: <046.1266b675873dc380465a9fe1f33ad29a@haskell.org> Message-ID: <061.b8f504f8a099a8950db25a30d525d38d@haskell.org> #6088: GeneralizedNewtypeDeriving + TypeFamilies + Equality constraints -------------------------------------------------+------------------------- Reporter: Lemming | Owner: Type: feature request | Status: Priority: normal | closed Component: Compiler (Type checker) | Milestone: Resolution: fixed | Version: 7.4.1 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: indexed- | Unknown/Multiple types/should_compile/T6088 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: 3046 -------------------------------------------------+------------------------- Comment (by Richard Eisenberg ): In [changeset:"02b4845e07ef7110b2f735f323eb8748903330ff/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="02b4845e07ef7110b2f735f323eb8748903330ff" Consider equality contexts exotic, uninferrable by "deriving" See comments in #8984. This takes back the fix for #6088. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 19 15:02:11 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Dec 2014 15:02:11 -0000 Subject: [GHC] #9880: ghc crashes on th splices in instance context In-Reply-To: <048.f4daf5bbce32dd24217721fc99cc931b@haskell.org> References: <048.f4daf5bbce32dd24217721fc99cc931b@haskell.org> Message-ID: <063.f8156801a6abcab5463a060a095f838f@haskell.org> #9880: ghc crashes on th splices in instance context -------------------------------------+------------------------------------- Reporter: Philonous | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"53599b3f515227f3407991913781fc8ea79d9638/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="53599b3f515227f3407991913781fc8ea79d9638" Clarify that declaration splices exist at top level only. (#9880) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 19 15:13:54 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Dec 2014 15:13:54 -0000 Subject: [GHC] #8984: Improve output of failed GeneralizedNewtypeDeriving coercion due to type roles In-Reply-To: <044.9146c0f21c1d5c0ac4fad078a63640bb@haskell.org> References: <044.9146c0f21c1d5c0ac4fad078a63640bb@haskell.org> Message-ID: <059.823cb211e423e0758b932241139b8b5c@haskell.org> #8984: Improve output of failed GeneralizedNewtypeDeriving coercion due to type roles -------------------------------------+------------------------------------- Reporter: haasn | Owner: goldfire Type: feature | Status: closed request | Milestone: Priority: normal | Version: 7.8.1 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | deriving/should_fail/T8984 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => fixed Comment: All done now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 19 15:14:52 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Dec 2014 15:14:52 -0000 Subject: [GHC] #9880: ghc crashes on th splices in instance context In-Reply-To: <048.f4daf5bbce32dd24217721fc99cc931b@haskell.org> References: <048.f4daf5bbce32dd24217721fc99cc931b@haskell.org> Message-ID: <063.8bf36edc1b05bfa400069c4e4063d138@haskell.org> #9880: ghc crashes on th splices in instance context -------------------------------------+------------------------------------- Reporter: Philonous | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: | Version: 7.8.3 Documentation | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => fixed * component: Compiler => Documentation -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 19 15:24:55 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Dec 2014 15:24:55 -0000 Subject: [GHC] #9872: Runing type functions is too slow In-Reply-To: <046.39f8cd7bfe0ce27cb6afb75f2059ad40@haskell.org> References: <046.39f8cd7bfe0ce27cb6afb75f2059ad40@haskell.org> Message-ID: <061.c8c8bf81e785daf6277ac08532257a62@haskell.org> #9872: Runing type functions is too slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"dd1b6d4fc96bc2779beaca836d1b9e4b158c1597/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="dd1b6d4fc96bc2779beaca836d1b9e4b158c1597" Add Jan Stolarek's test for Trac #9872 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 19 15:37:23 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Dec 2014 15:37:23 -0000 Subject: [GHC] #9875: ld -l:filename.dylib does not appear to be portable In-Reply-To: <045.5761a7e104bd5de24e048bce5dd70a34@haskell.org> References: <045.5761a7e104bd5de24e048bce5dd70a34@haskell.org> Message-ID: <060.d614d0bf0a40280c06d54738ba57b35f@haskell.org> #9875: ld -l:filename.dylib does not appear to be portable -------------------------------------+------------------------------------ Reporter: ezyang | Owner: trommler Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: GHCi | Version: 7.9 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Unknown Test Case: T2276_ghci | Blocked By: Blocking: 9845 | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------ Changes (by trommler): * owner: => trommler Comment: I'll take care of that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 19 15:37:52 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Dec 2014 15:37:52 -0000 Subject: [GHC] #9732: Pattern synonyms and unboxed values In-Reply-To: <047.98d7de74203e4f381291a803ad282f11@haskell.org> References: <047.98d7de74203e4f381291a803ad282f11@haskell.org> Message-ID: <062.6f216a999caa8ea31db11119f8f3cf2f@haskell.org> #9732: Pattern synonyms and unboxed values -------------------------------------+------------------------------------- Reporter: monoidal | Owner: cactus Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: PatternSynonyms Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed * milestone: 7.8.4 => 7.10.1 Comment: Gergo, I couldn't cleanly apply this it seems even with those patches; so I'm afraid I'll be dropping this for 7.8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 19 15:38:09 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Dec 2014 15:38:09 -0000 Subject: [GHC] #9783: Pattern synonym matcher is unnecessarily strict on unboxed continuations In-Reply-To: <045.fbfedd3216f2b9704ce7d408adca131b@haskell.org> References: <045.fbfedd3216f2b9704ce7d408adca131b@haskell.org> Message-ID: <060.20e57e376f27e4f6a455a859507d57ce@haskell.org> #9783: Pattern synonym matcher is unnecessarily strict on unboxed continuations -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: bug | Status: closed Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: PatternSynonyms Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: 9732 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: This couldn't be merged cleanly; so I'm afraid I'm going to drop it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 19 15:38:18 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Dec 2014 15:38:18 -0000 Subject: [GHC] #9783: Pattern synonym matcher is unnecessarily strict on unboxed continuations In-Reply-To: <045.fbfedd3216f2b9704ce7d408adca131b@haskell.org> References: <045.fbfedd3216f2b9704ce7d408adca131b@haskell.org> Message-ID: <060.4af909609ae767645ac9c1b2800f1586@haskell.org> #9783: Pattern synonym matcher is unnecessarily strict on unboxed continuations -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: PatternSynonyms Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: 9732 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: 7.8.4 => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 19 15:38:39 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Dec 2014 15:38:39 -0000 Subject: [GHC] #9872: Runing type functions is too slow In-Reply-To: <046.39f8cd7bfe0ce27cb6afb75f2059ad40@haskell.org> References: <046.39f8cd7bfe0ce27cb6afb75f2059ad40@haskell.org> Message-ID: <061.fc95a75c391a35760894d7b8711e4db4@haskell.org> #9872: Runing type functions is too slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): I have some work-in-progress [https://github.com/goldfirere/ghc/tree/wip /opt-flatten here] that cuts allocation amounts for the T9872x cases by half. I'm still twiddling knobs to find the best combination of settings, but the high-order bit is this: try to reduce a type family (in `flatten_exact_fam_app_fully`) '''before''' flattening the arguments. Only if that fails do we flatten the arguments. This works well if we have something like {{{ type family F a where F a = G a type family G a type family H a where H Bool = Char }}} and we call `F (H Bool)`. The current (HEAD) flattener will flatten `H Bool`, then reduce `F Char` to `G Char`, then flatten `Char` ''again'', then try to reduce `G Char`. With my patch, it just reduces `F (H Bool)` to `G (H Bool)`, then tries to reduce `G`, fails, and then reduces `H Bool` to `Char`. This saves one flattening. But, you can imagine it saving a lot more (and it does, in practice). On current tests, it works better not to use the flat-cache (which amounts to memoization of type-level functions) for this very-eager reduction. I'll look forward to trying Janek's tests, which satisfies a direct need: I've been worried that I'm overspecializing to the existing tests, and fresh tests will help. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 19 15:44:21 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Dec 2014 15:44:21 -0000 Subject: [GHC] #9575: -XAutoDeriveTypeable fails to generate instances In-Reply-To: <042.10f2f3cb5a176e03ffba6dac9c337cf9@haskell.org> References: <042.10f2f3cb5a176e03ffba6dac9c337cf9@haskell.org> Message-ID: <057.01118de792f4883f9a4d1f773ffd98fa@haskell.org> #9575: -XAutoDeriveTypeable fails to generate instances -------------------------------------+------------------------------------- Reporter: hvr | Owner: dreixel Type: bug | Status: closed Priority: high | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | deriving/should_compile/T8950 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => fixed Comment: Fixed by marking this in the 7.8.4 manual (see 7fa9d836e3b3e16d3d69a8954cf500dfaa3ea54e). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 19 15:45:23 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Dec 2014 15:45:23 -0000 Subject: [GHC] #9860: Package flags not command line completable in 7.8 In-Reply-To: <047.2ed0a58d8a149996e6a01ade6d7be83d@haskell.org> References: <047.2ed0a58d8a149996e6a01ade6d7be83d@haskell.org> Message-ID: <062.782e75310649538072aa9b6f6fb75be5@haskell.org> #9860: Package flags not command line completable in 7.8 -------------------------------------+------------------------------------- Reporter: kolmodin | Owner: kolmodin Type: bug | Status: closed Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D554 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => fixed Comment: Merged to 7.8.4 (see dd52a54279005c3a994114950e378c884e1fee02). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 19 15:47:10 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Dec 2014 15:47:10 -0000 Subject: [GHC] #9316: GHC 7.8.3 no longer infers correct type in presence of type families and constraints In-Reply-To: <047.3e08ece466a818f844fb33b47be1c8dd@haskell.org> References: <047.3e08ece466a818f844fb33b47be1c8dd@haskell.org> Message-ID: <062.f388975e4972451e44f60cf399be46da@haskell.org> #9316: GHC 7.8.3 no longer infers correct type in presence of type families and constraints -------------------------------------+------------------------------------- Reporter: ocharles | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged to 7.8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 19 15:56:15 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Dec 2014 15:56:15 -0000 Subject: [GHC] #9351: add ability to version symbols .c for packages with C code In-Reply-To: <045.80bb3346a6b02dbb6a22b16b99e4840e@haskell.org> References: <045.80bb3346a6b02dbb6a22b16b99e4840e@haskell.org> Message-ID: <060.8949642fea8d4fc67e719bf2c0d46ff7@haskell.org> #9351: add ability to version symbols .c for packages with C code -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: backpack Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by duncan): Or a more automagic approach might be to use binutils to rename or hide C symbols. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 19 17:47:33 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Dec 2014 17:47:33 -0000 Subject: [GHC] #9881: GHCi gives misleading error message when looking up info of ambiguous type In-Reply-To: <050.4dea55782a9eac6405927023d9d109f3@haskell.org> References: <050.4dea55782a9eac6405927023d9d109f3@haskell.org> Message-ID: <065.8daedd9719ffa81b19b859dbe0d60a11@haskell.org> #9881: GHCi gives misleading error message when looking up info of ambiguous type -------------------------------------+------------------------------------- Reporter: | Owner: simonpj RyanGlScott | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: GHCi | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Other | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: => simonpj Comment: Good point. I have a nice solution; more functinoality, less code. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 19 19:23:26 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Dec 2014 19:23:26 -0000 Subject: [GHC] #7473: getModificationTime gives only second-level resolution In-Reply-To: <045.e4643e54563d29d7370456429b4f7379@haskell.org> References: <045.e4643e54563d29d7370456429b4f7379@haskell.org> Message-ID: <060.8efc20cc088287762187e331d1c22a88@haskell.org> #7473: getModificationTime gives only second-level resolution -------------------------------------+------------------------------------- Reporter: duncan | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.6.1 Libraries | Keywords: directory Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by redneb): I just posted a pull request for that on github: https://github.com/haskell/directory/pull/11. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 19 19:42:56 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Dec 2014 19:42:56 -0000 Subject: [GHC] #9875: ld -l:filename.dylib does not appear to be portable In-Reply-To: <045.5761a7e104bd5de24e048bce5dd70a34@haskell.org> References: <045.5761a7e104bd5de24e048bce5dd70a34@haskell.org> Message-ID: <060.cc057e2240d803b9796babce02fcf626@haskell.org> #9875: ld -l:filename.dylib does not appear to be portable -------------------------------------+------------------------------------ Reporter: ezyang | Owner: trommler Type: bug | Status: patch Priority: high | Milestone: 7.10.1 Component: GHCi | Version: 7.9 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Unknown Test Case: T2276_ghci | Blocked By: Blocking: 9845 | Related Tickets: Differential Revisions: Phab:D579 | -------------------------------------+------------------------------------ Changes (by trommler): * status: new => patch * differential: => Phab:D579 Comment: I changed the linking as suggested and validated on Linux amd64. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 19 19:44:35 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Dec 2014 19:44:35 -0000 Subject: [GHC] #9845: GHC API evaluating some Cabal code fails with SegFault if executable is compiled statically In-Reply-To: <059.4340a519aad7bd56a35fa652e2b81e6f@haskell.org> References: <059.4340a519aad7bd56a35fa652e2b81e6f@haskell.org> Message-ID: <074.a19372aa2ac58d7511e6cc894f35316f@haskell.org> #9845: GHC API evaluating some Cabal code fails with SegFault if executable is compiled statically -------------------------------------+------------------------------------- Reporter: | Owner: JeanPhilippeMoresmau | Status: closed Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.8.3 Component: GHC API | Keywords: Resolution: duplicate | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: 9875 Type of failure: Runtime | Related Tickets: #9480, #8935, crash | #8376 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by trommler): * status: new => closed * resolution: => duplicate Comment: This is fixed in HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 19 19:53:32 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Dec 2014 19:53:32 -0000 Subject: [GHC] #9875: ld -l:filename.dylib does not appear to be portable In-Reply-To: <045.5761a7e104bd5de24e048bce5dd70a34@haskell.org> References: <045.5761a7e104bd5de24e048bce5dd70a34@haskell.org> Message-ID: <060.3966047fe30049206313427d0e59dd0c@haskell.org> #9875: ld -l:filename.dylib does not appear to be portable -------------------------------------+------------------------------------ Reporter: ezyang | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.10.1 Component: GHCi | Version: 7.9 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Unknown Test Case: T2276_ghci | Blocked By: Blocking: 9845 | Related Tickets: Differential Revisions: Phab:D579 | -------------------------------------+------------------------------------ Changes (by trommler): * owner: trommler => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 19 20:26:46 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Dec 2014 20:26:46 -0000 Subject: [GHC] #9875: ld -l:filename.dylib does not appear to be portable In-Reply-To: <045.5761a7e104bd5de24e048bce5dd70a34@haskell.org> References: <045.5761a7e104bd5de24e048bce5dd70a34@haskell.org> Message-ID: <060.94cfe0ded16d7ac88fbfc3b2ffa1bdf3@haskell.org> #9875: ld -l:filename.dylib does not appear to be portable -------------------------------------+------------------------------------ Reporter: ezyang | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.10.1 Component: GHCi | Version: 7.9 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Unknown Test Case: T2276_ghci | Blocked By: Blocking: 9845 | Related Tickets: Differential Revisions: Phab:D579 | -------------------------------------+------------------------------------ Comment (by ezyang): That's no good, we need to validate it on Mac OS X! ;) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 19 20:47:14 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Dec 2014 20:47:14 -0000 Subject: [GHC] #9908: Improve enumFromX support for OverloadedLists Message-ID: <045.5fa02968c369a6aec8b09a4fdc1c655c@haskell.org> #9908: Improve enumFromX support for OverloadedLists -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- At present, `OverloadedLists` desugars `[m..n]` as `fromList (enumFromTo m n)`. This is sometimes okay, but terrible for `Data.Sequence`. In particular, I want, for example, {{{#!hs [m..n] :: Seq Int }}} to end up as `fromFunction (n-m+1) (+m)`, which performs much better. There are a few approaches that look reasonable: 1. Try to catch `fromList (enumFromTo m n)` before `enumFromTo` becomes `eftInt`. This does not, unfortunately, seem to work. 2. Grab `eftInt` after it gets written back from `eftIntFB`. This would probably work, but it's currently impossible because `eftInt` is not exported from `GHC.Exts` or even `GHC.Enum`. 3. Add `enumFromTo`, etc., to the `IsList` class. Default to the current behavior, but if possible use `fromListN` for well-known `Enum` types. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 19 21:43:28 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Dec 2014 21:43:28 -0000 Subject: [GHC] #9909: Linker error (TemplateHaskell + HPC?) Message-ID: <047.ee34725d93b97761d609f24ff663ac32@haskell.org> #9909: Linker error (TemplateHaskell + HPC?) -------------------------------------+------------------------------------- Reporter: dcturner | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I'm getting the following error message when compiling a Yesod application (which uses Template Haskell rather a lot) with -fhpc: {{{ /usr/bin/ld: ./Foundation.dyn_o: relocation R_X86_64_PC32 against undefined symbol `_hpc_tickboxes_Settings_hpc' can not be used when making a shared object; recompile with -fPIC }}} Steps to reproduce: 1. Run `yesod init` to make a new scaffold. Call it `testsite` and select `simple` for no database. 2. Run: {{{ cd testsite ghc --make app/main.hs -XTemplateHaskell -XCPP -XOverloadedStrings -XMultiParamTypeClasses -XTypeFamilies -XQuasiQuotes -fhpc -O1 }}} Running the `ghc` line again completes successfully. It seems that there is a missing `./Settings.dyn_o` in the `gcc` command line that `ghc` calls, the first time through. It's there the second time so the link succeeds. No idea what that might mean. It's not a problem at `-O0`. I'm using 7.8.3 so this might be fixed now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 19 21:44:01 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Dec 2014 21:44:01 -0000 Subject: [GHC] #9909: Linker error (TemplateHaskell + HPC?) In-Reply-To: <047.ee34725d93b97761d609f24ff663ac32@haskell.org> References: <047.ee34725d93b97761d609f24ff663ac32@haskell.org> Message-ID: <062.7461a35d5062616598a6626c00da7759@haskell.org> #9909: Linker error (TemplateHaskell + HPC?) ---------------------------------------+---------------------------------- Reporter: dcturner | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ---------------------------------------+---------------------------------- Changes (by dcturner): * os: Unknown/Multiple => Linux * architecture: Unknown/Multiple => x86_64 (amd64) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 19 23:55:22 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Dec 2014 23:55:22 -0000 Subject: [GHC] #9910: ghc's dwarf (-g) output does not like Unicode (Char.intToDigit: not a digit 136) Message-ID: <045.2bab4361f44b745c3385fb704805cc5b@haskell.org> #9910: ghc's dwarf (-g) output does not like Unicode (Char.intToDigit: not a digit 136) -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Easy to reproduce as: {{{ inplace/bin/ghc-stage2 -w -g -c testsuite/tests/parser/unicode/utf8_024.hs ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.9.20141219 for x86_64-unknown-linux): Char.intToDigit: not a digit 136 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} {{{ petermw> Yes, Unicode doesn't work with DWARF yet }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 20 02:16:57 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Dec 2014 02:16:57 -0000 Subject: [GHC] #9911: Pattern synonyms with no signatures should yield warnings Message-ID: <045.fb316f949e47be5eb8be009f5ae43102@haskell.org> #9911: Pattern synonyms with no signatures should yield warnings -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.8.3 checker) | Operating System: Keywords: PatternSynonyms | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Incorrect Difficulty: Unknown | warning at compile-time Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- When `-fwarn-missing-signatures` is turned on, GHC should emit warnings for pattern synonyms with no signatures -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 20 02:40:42 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Dec 2014 02:40:42 -0000 Subject: [GHC] #9872: Runing type functions is too slow In-Reply-To: <046.39f8cd7bfe0ce27cb6afb75f2059ad40@haskell.org> References: <046.39f8cd7bfe0ce27cb6afb75f2059ad40@haskell.org> Message-ID: <061.4c6b08fb885f65e0667731a4a51de775@haskell.org> #9872: Runing type functions is too slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"8e2d858bb837a322f26face78df1b6ef3898e762/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="8e2d858bb837a322f26face78df1b6ef3898e762" Optimize flattener by trying to reduce a TF before reducing its args. This has a demonstrated 2x speed boost on the T9872{a,b,c} tests. (#9872) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 20 02:49:36 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Dec 2014 02:49:36 -0000 Subject: [GHC] #9872: Runing type functions is too slow In-Reply-To: <046.39f8cd7bfe0ce27cb6afb75f2059ad40@haskell.org> References: <046.39f8cd7bfe0ce27cb6afb75f2059ad40@haskell.org> Message-ID: <061.b5a0435a9ed9db91bc71637af5f9d961@haskell.org> #9872: Runing type functions is too slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): In thinking about this issue, the Right Way to get type families to be faster is to optimize them properly. By this, I mean taking the type family definitions and performing an optimization pass on them during type-checking/desugaring. We've essentially just implemented a tiny interpreter inside of !TcFlatten, and the whole thing could be more principled in approach. I'm not making a concrete proposal, just musing on the fact that we have here a classic problem -- how to write a fast interpreter for a given programming language. It just happens to be the language of type families. I suppose there is a body of research and experience on this very issue, and if we want to be serious about fast compilation times in the presence of heavy type-level computation, it would do well to use that body of knowledge. In any case, I'm done dwelling on performance for a while, but I'm quite pleased with my end result. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 20 02:55:47 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Dec 2014 02:55:47 -0000 Subject: [GHC] #9783: Pattern synonym matcher is unnecessarily strict on unboxed continuations In-Reply-To: <045.fbfedd3216f2b9704ce7d408adca131b@haskell.org> References: <045.fbfedd3216f2b9704ce7d408adca131b@haskell.org> Message-ID: <060.0f8750dd46b0a3bdfc61382e5624c1e8@haskell.org> #9783: Pattern synonym matcher is unnecessarily strict on unboxed continuations -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: bug | Status: merge Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: PatternSynonyms Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: 9732 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by cactus): * status: closed => merge * milestone: 7.10.1 => 7.8.4 Comment: I have pushed a new version of the commit that applies cleanly to `ghc-7.8` as `a91a2af`, please merge that. Also, in the future, please try applying the patches in question at an earlier time, instead of discovering if they have problems so close to the freeze date. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 20 04:23:55 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Dec 2014 04:23:55 -0000 Subject: [GHC] #9905: ghc-7.8.x command line error In-Reply-To: <049.b40fd88ea54ea4f681922f4cf3395d55@haskell.org> References: <049.b40fd88ea54ea4f681922f4cf3395d55@haskell.org> Message-ID: <064.92299f9590419f63342a40c623706a53@haskell.org> #9905: ghc-7.8.x command line error -------------------------------------+------------------------------------- Reporter: zRecursive | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by pgj): * os: FreeBSD => Unknown/Multiple Comment: Replying to [comment:1 pgj]: > Is this unique to FreeBSD? Does not the same happens on other platforms? I have just checked on Windows, it works the same way. Thus I have the gut feeling that something in GHC itself was changed, this is not related to the actual platform. Perhaps the consequent `-e` flags are not processed any more, only the first one? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 20 04:25:19 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Dec 2014 04:25:19 -0000 Subject: [GHC] #9905: ghc-7.8.x command line error In-Reply-To: <049.b40fd88ea54ea4f681922f4cf3395d55@haskell.org> References: <049.b40fd88ea54ea4f681922f4cf3395d55@haskell.org> Message-ID: <064.2b865271de0965a921f3db44979862c9@haskell.org> #9905: ghc-7.8.x command line error -------------------------------------+------------------------------------- Reporter: zRecursive | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by pgj): * failure: None/Unknown => Incorrect result at runtime -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 20 08:48:01 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Dec 2014 08:48:01 -0000 Subject: [GHC] #9732: Pattern synonyms and unboxed values In-Reply-To: <047.98d7de74203e4f381291a803ad282f11@haskell.org> References: <047.98d7de74203e4f381291a803ad282f11@haskell.org> Message-ID: <062.dfb127d323baaac657af5fde00ef7eaf@haskell.org> #9732: Pattern synonyms and unboxed values -------------------------------------+------------------------------------- Reporter: monoidal | Owner: cactus Type: bug | Status: merge Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: PatternSynonyms Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by cactus): * status: closed => merge * milestone: 7.10.1 => 7.8.4 Comment: I have pushed a new version of the commit that applies cleanly to `ghc-7.8` as `a91a2af..0f1f3e1`, please merge that. Also, in the future, please try applying the patches in question at an earlier time, instead of discovering if they have problems so close to the freeze date. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 20 10:00:21 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Dec 2014 10:00:21 -0000 Subject: [GHC] #9875: ld -l:filename.dylib does not appear to be portable In-Reply-To: <045.5761a7e104bd5de24e048bce5dd70a34@haskell.org> References: <045.5761a7e104bd5de24e048bce5dd70a34@haskell.org> Message-ID: <060.c20fa5eea081f42d6003ceb23e409187@haskell.org> #9875: ld -l:filename.dylib does not appear to be portable -------------------------------------+------------------------------------ Reporter: ezyang | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.10.1 Component: GHCi | Version: 7.9 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Unknown Test Case: T2276_ghci | Blocked By: Blocking: 9845 | Related Tickets: Differential Revisions: Phab:D579 | -------------------------------------+------------------------------------ Comment (by trommler): Replying to [comment:6 ezyang]: > That's no good, we need to validate it on Mac OS X! ;) Well, at least I did not introduce a regression on Linux :-) Could you help out validating on Mac OS X? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 20 12:18:33 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Dec 2014 12:18:33 -0000 Subject: [GHC] #9912: Where injured soldiers Message-ID: <053.968532407a009f9064b63817fc303c2c@haskell.org> #9912: Where injured soldiers -------------------------------------+------------------------------------- Reporter: ZafinaPrincess | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Where injured soldiers would occasionally go into shock and I within minutes are being given blood from plastic I V bottles before that time blood was stored in glass bottles but in 1948 with the invention a plastic blood storage bags the military abandon the story to blooding glass bottles since they were too easily broken in a wartime environment unfortunately but ballads leaked from the plastic bags into the stored blood. http://xtremenitrotruth.com/blackline-elite/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 20 13:36:37 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Dec 2014 13:36:37 -0000 Subject: [GHC] #9905: ghc-7.8.x command line error In-Reply-To: <049.b40fd88ea54ea4f681922f4cf3395d55@haskell.org> References: <049.b40fd88ea54ea4f681922f4cf3395d55@haskell.org> Message-ID: <064.f9cc46da462651391ec20ca2bd3aca79@haskell.org> #9905: ghc-7.8.x command line error -------------------------------------+------------------------------------- Reporter: zRecursive | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): It's the import itself that is causing ghc-7.8 and later to fail. {{{ $ ghc-7.6.3 -e "import Data.List" $ echo $? 0 $ ghc-7.8.3 -e "import Data.List" $ echo $? 1 $ ghc-7.9.20141219 -e "import Data.List" $ echo $? 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 20 14:03:40 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Dec 2014 14:03:40 -0000 Subject: [GHC] #9911: Pattern synonyms with no signatures should yield warnings In-Reply-To: <045.fb316f949e47be5eb8be009f5ae43102@haskell.org> References: <045.fb316f949e47be5eb8be009f5ae43102@haskell.org> Message-ID: <060.ee86ea3d8c3d037f8efa2b43d1e95254@haskell.org> #9911: Pattern synonyms with no signatures should yield warnings -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: PatternSynonyms (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: Incorrect | warning at compile-time | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by cactus): The reason this doesnt Just Work(tm) is that the set of names that need signatures (`sig_names` in `TcRnDriver.tcTopSrcDecls`) is computed from the `HsBind Name`s on the input side (so for a pattern synonym `P`, the set would contain `P` itself), but then when checking against this set, the names from the typechecked bindings are used; so for a pattern synonym `P`, we try to look up `$mP` for the matcher and `$bP` for the builder. Another problem is that even if we would look up `P` (e.g. by changing matcher names to be the original pattern name without the added `$m` prefix), the warning would show the type of the matcher, instead of the pattern synonym type. So all in all, a real solution to this will require using the typechecked pattern synonym itself (a `PatSyn`) when doing the signature check, since that has the correct `Name` and the type. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 20 14:22:01 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Dec 2014 14:22:01 -0000 Subject: [GHC] #9912: Allow access to full logs in Harbormaster builds Message-ID: <047.9a969c425fcae9f29b85ff8660013a6f@haskell.org> #9912: Allow access to full logs in Harbormaster builds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Harbormaster helpfully tries building every commit and every differential revision. However, when it fails, we only get the tail of the output, with no way to get more information. A case in point is [https://phabricator.haskell.org/harbormaster/build/2736/ this build], where a performance test case failed with `[stat too good]`. In this particular case, the commit is intended to be an optimization, so this failure is not terribly unexpected. I wanted to update `all.T` with the new figure, but I couldn't get the figure that Harbormaster's configuration had. Instead, I had to run the test on my machine (a Mac), get a different number, and hope that Harbormaster's configuration fell within 5% of mine. It did, in this case, but might not next time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 20 14:32:05 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Dec 2014 14:32:05 -0000 Subject: [GHC] #9912: Allow access to full logs in Harbormaster builds In-Reply-To: <047.9a969c425fcae9f29b85ff8660013a6f@haskell.org> References: <047.9a969c425fcae9f29b85ff8660013a6f@haskell.org> Message-ID: <062.a69c34a724b2a1c2870774fba3176b26@haskell.org> #9912: Allow access to full logs in Harbormaster builds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: thoughtpolice Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by hvr): * owner: hvr => thoughtpolice * version: 7.8.3 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 20 14:33:51 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Dec 2014 14:33:51 -0000 Subject: [GHC] #9912: Allow access to full logs in Harbormaster builds In-Reply-To: <047.9a969c425fcae9f29b85ff8660013a6f@haskell.org> References: <047.9a969c425fcae9f29b85ff8660013a6f@haskell.org> Message-ID: <062.39372176a4f5d651415cf74f3480db4d@haskell.org> #9912: Allow access to full logs in Harbormaster builds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: thoughtpolice Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): I thought "Trac & Git" was the best value for the Component field for this ticket, and that component sets the owner to hvr. Perhaps there should be a new Phab component? In any case, I wasn't intending to say that hvr is responsible here! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 20 14:47:10 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Dec 2014 14:47:10 -0000 Subject: [GHC] #9913: Discrepancy in type synonym definition and usage Message-ID: <051.03cc5cbbde77abd6bab9a794b2bf169f@haskell.org> #9913: Discrepancy in type synonym definition and usage -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler (Parser) | Version: 7.8.3 Keywords: | Operating System: Architecture: x86 | Unknown/Multiple Difficulty: Unknown | Type of failure: GHC Blocked By: | rejects valid program Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Minor consistency issue, the following compiles fine (note parentheses): {{{#!hs type Alg f a = f a -> a initial :: Alg(f) a initial = undefined }}} But changing the definition to mirror its use: {{{#!hs type Alg(f) a = f a -> a initial :: Alg(f) a initial = undefined }}} and it fails with: {{{#!hs Unexpected type ?f? In the type declaration for ?Alg? A type declaration should have form type Alg a b c = ... Failed, modules loaded: none. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 20 14:57:00 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Dec 2014 14:57:00 -0000 Subject: [GHC] #9913: Discrepancy in type synonym definition and usage In-Reply-To: <051.03cc5cbbde77abd6bab9a794b2bf169f@haskell.org> References: <051.03cc5cbbde77abd6bab9a794b2bf169f@haskell.org> Message-ID: <066.d8def02bb952c102e1c4714a826f137d@haskell.org> #9913: Discrepancy in type synonym definition and usage -------------------------------------+------------------------------------- Reporter: | Owner: Iceland_jack | Status: closed Type: bug | Milestone: Priority: lowest | Version: 7.8.3 Component: Compiler | Keywords: (Parser) | Architecture: x86 Resolution: invalid | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: GHC | rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => closed * resolution: => invalid Comment: Thanks for your report. I don?t think this is a bug. There is a conceptual difference between the declaration, where the argument to the type synonyms are declared (and hence have to be variables), and the use of a type synonym, where parameters are type expressions. Note that you can use `Alg Maybe`, but cannot define `type Alg Maybe a = Maybe a -> a`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 20 21:09:53 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Dec 2014 21:09:53 -0000 Subject: [GHC] #9744: Make program name and project version configurable In-Reply-To: <044.83253224e4144ae46fadcfbf6a5cd378@haskell.org> References: <044.83253224e4144ae46fadcfbf6a5cd378@haskell.org> Message-ID: <059.e0e83ff039d17c5a47e19750e9835026@haskell.org> #9744: Make program name and project version configurable -------------------------------------+------------------------------------- Reporter: luite | Owner: luite Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D496 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"4523d669989ab3b08e360016a315d6f9cd4808b0/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="4523d669989ab3b08e360016a315d6f9cd4808b0" trac #9744, make program name and product version configurable through DynFlags/Settings Summary: This allows GHC API clients to use a package database and dynamic library names that do not clash with those of the host GHC This also updates the Haddock submodule. Reviewers: hvr, austin Reviewed By: austin Subscribers: thomie, carter Differential Revision: https://phabricator.haskell.org/D496 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 21 04:33:13 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Dec 2014 04:33:13 -0000 Subject: [GHC] #9914: Inconsistent handling of leading whitespace in GHCi Message-ID: <045.d9bc2fa9e5bed47791a329e1a8e86aaf@haskell.org> #9914: Inconsistent handling of leading whitespace in GHCi -------------------------------------+------------------------------------- Reporter: cactus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 7.8.3 Keywords: GHCi | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: GHC Blocked By: | rejects valid program Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- In GHCi, the following three lines all work as expected: {{{ ?? let x = 1 ?? x 1 ?? let x = 2 -- Note leading whitespace ?? x 2 ?? data Foo = Foo ?? :i Foo data Foo = Foo -- Defined at :6:1 }}} However, this fails: {{{ ?? data Bar = Bar -- Note leading whitespace :8:2: parse error on input ?data? }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 21 04:46:05 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Dec 2014 04:46:05 -0000 Subject: [GHC] #9915: GHCi has trouble with 'foreign' when it is not a keyword Message-ID: <045.ba44943d473f217b93194b5df3e50a38@haskell.org> #9915: GHCi has trouble with 'foreign' when it is not a keyword -------------------------------------+------------------------------------- Reporter: cactus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 7.8.3 Keywords: GHCi | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- In Haskell 98 mode, `foreign` is not a keyword at all. The following is an example of a valid Haskell 98 program: {{{#!hs {-# LANGUAGE Haskell98 #-} module F where foreign :: Int foreign = 42 }}} However, it seems noone told GHCi about this: {{{ 12:42:38 [cactus at galaxy hs]$ ghci -XHaskell98 GHCi, version 7.8.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. ?? x = 42 -- Expected to fail :2:3: parse error on input ?=? ?? x -- Expected to fail :3:1: Not in scope: ?x? ?? -- So this should fail as well, right? ?? foreign = 42 ?? -- Nope ?? foreign 42 ?? -- But wait, there's more! ?? foreign -- boo! :9:1: Parse error: naked expression at top level Perhaps you intended to use TemplateHaskell }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 21 04:49:03 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Dec 2014 04:49:03 -0000 Subject: [GHC] #9915: GHCi has trouble with 'foreign' when it is not a keyword In-Reply-To: <045.ba44943d473f217b93194b5df3e50a38@haskell.org> References: <045.ba44943d473f217b93194b5df3e50a38@haskell.org> Message-ID: <060.235b1ab5c753706c5542260c48da0d40@haskell.org> #9915: GHCi has trouble with 'foreign' when it is not a keyword -------------------------------------+------------------------------------- Reporter: cactus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Parser) | Keywords: GHCi Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by cactus): Of course, this is because `InteractiveUI.runStmt` decides to evaluate lines as declarations instead of statements based on a check vs. some hardcoded prefixes: {{{#!hs -- | Entry point to execute some haskell code from user runStmt :: String -> SingleStep -> GHCi Bool runStmt stmt step -- empty | null (filter (not.isSpace) stmt) = return False -- import | "import " `isPrefixOf` stmt = do addImportToContext stmt; return False -- data, class, newtype... | any (flip isPrefixOf stmt) declPrefixes = ... -- parse and run as Decl | otherwise = ... -- parse and run as Stmt -- | If we one of these strings prefixes a command, then we treat it as a decl -- rather than a stmt. declPrefixes :: [String] declPrefixes = ["class ","data ","newtype ","type ","instance ", "deriving ", "foreign ", "default ", "default("] }}} This gives a wrong result when `foreign` is not a keyword (and thus, a prefix of `foreign ` doesn't signify a declaration, like in the `foreign -- boo!` line in my original ticket). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 21 04:49:58 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Dec 2014 04:49:58 -0000 Subject: [GHC] #9900: Support pattern synonyms in GHCi In-Reply-To: <045.62d6509e4b0cfc58e8f6254c0f951369@haskell.org> References: <045.62d6509e4b0cfc58e8f6254c0f951369@haskell.org> Message-ID: <060.1ebba1eaa4ff061e4c45ba1efe28a559@haskell.org> #9900: Support pattern synonyms in GHCi -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.8.3 Component: GHCi | Keywords: PatternSynonyms Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #8749, #7253 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by cactus): As part of this, I would need to add `pattern ` as a declaration- introducing prefix to `InteractiveUI.declPrefixes`, but it has no way of being conditional on whether `PatternSynonyms` is turned on (see #9915). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 21 05:12:33 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Dec 2014 05:12:33 -0000 Subject: [GHC] #9915: GHCi has trouble with 'foreign' when it is not a keyword In-Reply-To: <045.ba44943d473f217b93194b5df3e50a38@haskell.org> References: <045.ba44943d473f217b93194b5df3e50a38@haskell.org> Message-ID: <060.c293c868c8b00bed15340e1493cecd55@haskell.org> #9915: GHCi has trouble with 'foreign' when it is not a keyword -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Parser) | Keywords: GHCi Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by cactus): * owner: => cactus -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 21 07:43:55 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Dec 2014 07:43:55 -0000 Subject: [GHC] #9915: GHCi has trouble with 'foreign' when it is not a keyword In-Reply-To: <045.ba44943d473f217b93194b5df3e50a38@haskell.org> References: <045.ba44943d473f217b93194b5df3e50a38@haskell.org> Message-ID: <060.12e5ae17502ba51661a36febc64e48f8@haskell.org> #9915: GHCi has trouble with 'foreign' when it is not a keyword -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Parser) | Keywords: GHCi Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Dr. ERDI Gergo ): In [changeset:"3b497ddb231981bc6aeb5533426bf632ba126e39/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="3b497ddb231981bc6aeb5533426bf632ba126e39" Check dflags for language extensions when deciding if "foreign " and "deriving " look like prefixes of valid declarations (fixes #9915) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 21 07:44:19 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Dec 2014 07:44:19 -0000 Subject: [GHC] #9915: GHCi has trouble with 'foreign' when it is not a keyword In-Reply-To: <045.ba44943d473f217b93194b5df3e50a38@haskell.org> References: <045.ba44943d473f217b93194b5df3e50a38@haskell.org> Message-ID: <060.23d1f3f3cb175023b511ff011882571a@haskell.org> #9915: GHCi has trouble with 'foreign' when it is not a keyword -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: bug | Status: merge Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 (Parser) | Keywords: GHCi Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | ghci/should_compile/T9915 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by cactus): * status: new => merge * testcase: => ghci/should_compile/T9915 * milestone: => 7.8.4 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 21 09:46:17 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Dec 2014 09:46:17 -0000 Subject: [GHC] #9900: Support pattern synonyms in GHCi In-Reply-To: <045.62d6509e4b0cfc58e8f6254c0f951369@haskell.org> References: <045.62d6509e4b0cfc58e8f6254c0f951369@haskell.org> Message-ID: <060.edcce825bc71bfc5c34569352a02c98d@haskell.org> #9900: Support pattern synonyms in GHCi -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.8.3 Component: GHCi | Keywords: PatternSynonyms Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: 9915 Type of failure: | Related Tickets: #8749, #7253 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by cactus): * blockedby: => 9915 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 21 09:47:21 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Dec 2014 09:47:21 -0000 Subject: [GHC] #9900: Support pattern synonyms in GHCi In-Reply-To: <045.62d6509e4b0cfc58e8f6254c0f951369@haskell.org> References: <045.62d6509e4b0cfc58e8f6254c0f951369@haskell.org> Message-ID: <060.3d23da50daa5cb9191dc77c1f8bb5ffe@haskell.org> #9900: Support pattern synonyms in GHCi -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: feature | Status: new request | Milestone: 7.8.4 Priority: normal | Version: 7.8.3 Component: GHCi | Keywords: PatternSynonyms Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: 9915 Type of failure: GHC | Related Tickets: #8749, #7253 rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by cactus): * failure: None/Unknown => GHC rejects valid program * milestone: 7.10.1 => 7.8.4 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 21 11:35:34 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Dec 2014 11:35:34 -0000 Subject: [GHC] #9049: Expose srcLoc from the assertion architecture to allow better error messages In-Reply-To: <042.a0d4c757be085a0284ebca147547b4f3@haskell.org> References: <042.a0d4c757be085a0284ebca147547b4f3@haskell.org> Message-ID: <057.a7e01ee674c581b4a2c18e06834f695c@haskell.org> #9049: Expose srcLoc from the assertion architecture to allow better error messages -------------------------------------+------------------------------------- Reporter: nh2 | Owner: gridaphobe Type: feature | Status: patch request | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D578 | -------------------------------------+------------------------------------- Comment (by rodlogic): Replying to [comment:13 simonpj]: > gridaphobe, rodlogic, are you willing to reveal your email identities? I'm having trouble connecting up email discussion with Trac personae! Thanks > > Simon Simon, my real name is Yuri de Wit and my email is admin at rodlogic.net. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 21 11:44:41 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Dec 2014 11:44:41 -0000 Subject: [GHC] #9049: Expose srcLoc from the assertion architecture to allow better error messages In-Reply-To: <042.a0d4c757be085a0284ebca147547b4f3@haskell.org> References: <042.a0d4c757be085a0284ebca147547b4f3@haskell.org> Message-ID: <057.d9d1ddc4bfc10630a28de32f03e52a77@haskell.org> #9049: Expose srcLoc from the assertion architecture to allow better error messages -------------------------------------+------------------------------------- Reporter: nh2 | Owner: gridaphobe Type: feature | Status: patch request | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D578 | -------------------------------------+------------------------------------- Comment (by rodlogic): Replying to [comment:19 gridaphobe]: > I've sent a patch that implements [wiki:ExplicitCallStack/ImplicitLocations] to Phab (https://phabricator.haskell.org/D578). This is great. I would have taken me quite a while to get there. In your patch you mention that you didn't change base at this point, could we at least change GHC.Base to use it and add a new assertMsg? This would basically cover the ASSERT macros that exist in HsVersions.h: {{{ #define ASSERT(e) if debugIsOn && not (e) then (assertPanic __FILE__ __LINE__) else #define ASSERT2(e,msg) if debugIsOn && not (e) then (assertPprPanic __FILE__ __LINE__ (msg)) else #define MASSERT(e) ASSERT(e) return () #define MASSERT2(e,msg) ASSERT2(e,msg) return () #define ASSERTM(e) do { bool <- e; MASSERT(bool) } #define ASSERTM2(e,msg) do { bool <- e; MASSERT2(bool,msg) } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 21 15:07:28 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Dec 2014 15:07:28 -0000 Subject: [GHC] #9832: Get rid of PERL dependency of `ghc-split` In-Reply-To: <042.a80d180822707ef08b1350d4a542cee3@haskell.org> References: <042.a80d180822707ef08b1350d4a542cee3@haskell.org> Message-ID: <057.36a86102eb89a077a6137376ddb51aba@haskell.org> #9832: Get rid of PERL dependency of `ghc-split` -------------------------------------+------------------------------------- Reporter: hvr | Owner: rwbarton Type: task | Status: new Priority: high | Milestone: 7.12.1 Component: Driver | Version: Resolution: | Keywords: perl Operating System: Windows | Architecture: Unknown/Multiple Type of failure: | Difficulty: Difficult (2-5 None/Unknown | days) Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Comment (by GregWeber): What is the difference between 1) and 2) here? 1) Write a parser in Haskell 2) Leverage existing internal knowledge about how things are generated? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 21 17:41:18 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Dec 2014 17:41:18 -0000 Subject: [GHC] #9832: Get rid of PERL dependency of `ghc-split` In-Reply-To: <042.a80d180822707ef08b1350d4a542cee3@haskell.org> References: <042.a80d180822707ef08b1350d4a542cee3@haskell.org> Message-ID: <057.162a6a165a5aa920e0b7fa6d8b046e5d@haskell.org> #9832: Get rid of PERL dependency of `ghc-split` -------------------------------------+------------------------------------- Reporter: hvr | Owner: rwbarton Type: task | Status: new Priority: high | Milestone: 7.12.1 Component: Driver | Version: Resolution: | Keywords: perl Operating System: Windows | Architecture: Unknown/Multiple Type of failure: | Difficulty: Difficult (2-5 None/Unknown | days) Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Comment (by ezyang): By the way, if you do (2), be *very* careful about memory usage. GHC outputs C-- in a streaming fashion, so if you accidentally accumulate everything in memory as you are splitting objects you will spike memory usage. In principle it should be possible to make sure it streams properly, but putting the splitter in a separate process certainly makes this job easier. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 21 19:21:47 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Dec 2014 19:21:47 -0000 Subject: [GHC] #5001: makeCorePair: arity missing In-Reply-To: <045.01643f91fbc10ebef1f612bc5674a3a7@haskell.org> References: <045.01643f91fbc10ebef1f612bc5674a3a7@haskell.org> Message-ID: <060.d579df2d146d7b2b656939f71c53bbdf@haskell.org> #5001: makeCorePair: arity missing -------------------------------------+------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: high | Milestone: 7.4.1 Component: Compiler | Version: 7.2.1 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: warning at compile-time | Related Tickets: Test Case: | deSugar/should_compile/T5001 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by nomeata): * owner: simonpj => * status: closed => new * resolution: fixed => Comment: Not fully fixed yet. I just observed this when compiling `mono- traversable-0.6.2` using GHC-7.8.4-rc1: {{{ [2 of 7] Compiling Data.MonoTraversable ( src/Data/MonoTraversable.hs, dist-ghc/build/Da ta/MonoTraversable.o ) src/Data/MonoTraversable.hs:39:1: Warning: The import of `$, replicate' from module `Prelude' is redundant makeCorePair: arity missing $cofoldMap{v aaQ1} [lid] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 21 20:51:58 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Dec 2014 20:51:58 -0000 Subject: [GHC] #9913: Discrepancy in type synonym definition and usage In-Reply-To: <051.03cc5cbbde77abd6bab9a794b2bf169f@haskell.org> References: <051.03cc5cbbde77abd6bab9a794b2bf169f@haskell.org> Message-ID: <066.6cc469e169f5c51efc97c076dc851715@haskell.org> #9913: Discrepancy in type synonym definition and usage -------------------------------------+------------------------------------- Reporter: | Owner: Iceland_jack | Status: closed Type: bug | Milestone: Priority: lowest | Version: 7.8.3 Component: Compiler | Keywords: (Parser) | Architecture: x86 Resolution: invalid | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: GHC | rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): Agreed with what Joachim said, but moreover this falls under the purview of the Haskell 2010 Report, so a bug report of this sort should ideally be accompanied by a reference to section(s) of the Report that GHC is deviating from (in this instance, though I haven't checked, I imagine the Report specifies the behavior that GHC exhibits). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 21 20:56:34 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Dec 2014 20:56:34 -0000 Subject: [GHC] #9909: Linker error (TemplateHaskell + HPC?) In-Reply-To: <047.ee34725d93b97761d609f24ff663ac32@haskell.org> References: <047.ee34725d93b97761d609f24ff663ac32@haskell.org> Message-ID: <062.cbd61cd24133e31ff5b0dc39296c0291@haskell.org> #9909: Linker error (TemplateHaskell + HPC?) ---------------------------------------+---------------------------------- Reporter: dcturner | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #9762 Differential Revisions: | ---------------------------------------+---------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => duplicate * related: => #9762 Comment: Thanks for the report. This looks like the same issue as #9762. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 21 21:01:01 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Dec 2014 21:01:01 -0000 Subject: [GHC] #9898: Wanted: higher-order type-level programming In-Reply-To: <045.8f7b834957773169b7810af17c757a81@haskell.org> References: <045.8f7b834957773169b7810af17c757a81@haskell.org> Message-ID: <060.bdface1ee755ea21d522142766e8e35c@haskell.org> #9898: Wanted: higher-order type-level programming -------------------------------------+------------------------------------- Reporter: erisco | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: (Type checker) | Architecture: x86_64 (amd64) Resolution: | Difficulty: Unknown Operating System: Windows | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): Replying to [comment:5 jstolarek]: > > will such usage be banned n 7.8.4? > No. But that's still a bug and you shouldn't construct your code around this. Really? #9433 is marked as merged as 7.8.4, or am I misunderstanding something here? Or is there a distinction between the "applied to zero arguments" case and the "applied to at least one, but fewer than its arity" case? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 21 21:18:57 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Dec 2014 21:18:57 -0000 Subject: [GHC] #9906: Warning generated by hscpp code have unhelpful file names In-Reply-To: <044.c0b2b77cfbe1caa145f66f9718cb9575@haskell.org> References: <044.c0b2b77cfbe1caa145f66f9718cb9575@haskell.org> Message-ID: <059.f1de3de335c41afd22769ccef75d05da@haskell.org> #9906: Warning generated by hscpp code have unhelpful file names -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): Can you put this in a file `A.hs`: {{{ {-# LANGUAGE CPP #-} module A where #define MESSAGE "Hello, world" f :: Bool -> String f False = MESSAGE main = print (f False) }}} and run `ghc A -Wall -keep-tmp-files`? - Do you get a warning about `A.hs` or some temporary `ghcXXXX_YY.hscpp` file? (On Linux using gcc's C preprocessor, the warning is correctly about `A.hs`.) - In the latter case, could you attach that temporary file here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 21 21:30:34 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Dec 2014 21:30:34 -0000 Subject: [GHC] #9762: #8696 + #9012 In-Reply-To: <047.1416552af7b7cba6e17e930c77b546df@haskell.org> References: <047.1416552af7b7cba6e17e930c77b546df@haskell.org> Message-ID: <062.53309955ca9c2ad6337ffc1e75d53ddd@haskell.org> #9762: #8696 + #9012 -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8696, #9012 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by rwbarton): * owner: => rwbarton -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 21 21:33:39 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Dec 2014 21:33:39 -0000 Subject: [GHC] #9903: GHCi produces a cryptic message when using HPC In-Reply-To: <056.3163ec769e71b713310f29b6c2e4fa48@haskell.org> References: <056.3163ec769e71b713310f29b6c2e4fa48@haskell.org> Message-ID: <071.6433a6135c5d80311d6a3189ca568f8c@haskell.org> #9903: GHCi produces a cryptic message when using HPC -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | Status: new Type: bug | Milestone: Priority: normal | Version: 7.9 Component: GHCi | Keywords: hpc Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHCi crash | Related Tickets: #9878, #9762 ? Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): This is likely the same issue as #9762, yes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 21 21:34:17 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Dec 2014 21:34:17 -0000 Subject: [GHC] #9762: #8696 + #9012 In-Reply-To: <047.1416552af7b7cba6e17e930c77b546df@haskell.org> References: <047.1416552af7b7cba6e17e930c77b546df@haskell.org> Message-ID: <062.b0c47be2a7e65acbeac3fc1b624c146c@haskell.org> #9762: #8696 + #9012 -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8696, #9012, Test Case: | #9903, #9909 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by rwbarton): * related: #8696, #9012 => #8696, #9012, #9903, #9909 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 21 21:44:12 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Dec 2014 21:44:12 -0000 Subject: [GHC] #9904: ghc: out of memory, requested 1048576 bytes on openbsd In-Reply-To: <045.d32cbdc44e8af12b00d61e76d86031a6@haskell.org> References: <045.d32cbdc44e8af12b00d61e76d86031a6@haskell.org> Message-ID: <060.c51697743e3203055325f53d27a4b80b@haskell.org> #9904: ghc: out of memory, requested 1048576 bytes on openbsd -----------------------------------+------------------------------------ Reporter: vu3rdd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: cabal-install Operating System: OpenBSD | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -----------------------------------+------------------------------------ Comment (by rwbarton): Is it possible that your system is actually running out of memory? ghc is rather RAM-hungry and it might fail to build cabal if you have less than around 1G free. In any case, the ghc 7.6 line is no longer being developed so if you do think it may be a bug in ghc, try ghc 7.8 first (you'll have to install cabal 1.18 or newer to work with ghc 7.8). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 21 23:44:04 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Dec 2014 23:44:04 -0000 Subject: [GHC] #9895: No -mtriple param being passed to opt/llc when cross compiling In-Reply-To: <044.a3f80c6c0a5d3377f5d023665058edc9@haskell.org> References: <044.a3f80c6c0a5d3377f5d023665058edc9@haskell.org> Message-ID: <059.198b0cb77ce3b24e98ba3818a91f6ccd@haskell.org> #9895: No -mtriple param being passed to opt/llc when cross compiling -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D576 | -------------------------------------+------------------------------------- Changes (by rwbarton): * differential: D576 => Phab:D576 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 21 23:58:35 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Dec 2014 23:58:35 -0000 Subject: [GHC] #9904: ghc: out of memory, requested 1048576 bytes on openbsd In-Reply-To: <045.d32cbdc44e8af12b00d61e76d86031a6@haskell.org> References: <045.d32cbdc44e8af12b00d61e76d86031a6@haskell.org> Message-ID: <060.3238a22aa6793b3163c73a96a4674e5c@haskell.org> #9904: ghc: out of memory, requested 1048576 bytes on openbsd -----------------------------------+------------------------------------ Reporter: vu3rdd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: cabal-install Operating System: OpenBSD | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -----------------------------------+------------------------------------ Comment (by carter): additionally, its worth configuring having a decent sized swap file or your systems equivalent. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 22 00:26:07 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Dec 2014 00:26:07 -0000 Subject: [GHC] #9905: ghc-7.8.x command line error In-Reply-To: <049.b40fd88ea54ea4f681922f4cf3395d55@haskell.org> References: <049.b40fd88ea54ea4f681922f4cf3395d55@haskell.org> Message-ID: <064.4ba23b7f8911efa241a07d1a72d24e08@haskell.org> #9905: ghc-7.8.x command line error -------------------------------------+------------------------------------- Reporter: zRecursive | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): So, ghc 7.6 did not care if an expression given to `-e` failed to compile; it would exit with status code 0 or proceed to the next `-e` flag. See #7962. That could explain all the results here, except that in ghc 7.6, `-e "import Data.List"` actually works: try `ghc-7.6.3 -e "import Data.List" -e "sort [2,1]"`. This no longer works in ghc 7.8, so there is certainly something to fix here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 22 01:08:51 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Dec 2014 01:08:51 -0000 Subject: [GHC] #3814: Compile to more than one (sub)-architecture In-Reply-To: <045.81dca617e2084ce61e4f3745c003b436@haskell.org> References: <045.81dca617e2084ce61e4f3745c003b436@haskell.org> Message-ID: <060.2cc87051a706d89186368168781c3f83@haskell.org> #3814: Compile to more than one (sub)-architecture -------------------------------------+------------------------------------- Reporter: filcab | Owner: Type: feature | Status: closed request | Milestone: ? Priority: normal | Version: 6.12.1 Component: Compiler | Keywords: architecture, Resolution: duplicate | compiler, x86_64 Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #4163 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): The description touches on two issues: (1) being able to cross-compile at all and (2) being able to generate code for several different targets with the same compiler by using command-line switches. We have (1) currently (though it's a bit DIY), but not (2). But I'll let someone else file a feature request for (2) if they want it, since I'm not convinced it's sufficiently more valuable than just having one ghc installed for each target. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 22 02:27:40 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Dec 2014 02:27:40 -0000 Subject: [GHC] #9905: ghc-7.8.x command line error In-Reply-To: <049.b40fd88ea54ea4f681922f4cf3395d55@haskell.org> References: <049.b40fd88ea54ea4f681922f4cf3395d55@haskell.org> Message-ID: <064.26b00f22992258d157c531a49c8307e1@haskell.org> #9905: ghc-7.8.x command line error -------------------------------------+------------------------------------- Reporter: zRecursive | Owner: rwbarton Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by rwbarton): * owner: => rwbarton -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 22 02:58:24 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Dec 2014 02:58:24 -0000 Subject: [GHC] #9905: ghc-7.8.x command line error In-Reply-To: <049.b40fd88ea54ea4f681922f4cf3395d55@haskell.org> References: <049.b40fd88ea54ea4f681922f4cf3395d55@haskell.org> Message-ID: <064.41ce7cc369b87e9d94a531325bee971c@haskell.org> #9905: ghc-7.8.x command line error -------------------------------------+------------------------------------- Reporter: zRecursive | Owner: rwbarton Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D581 | -------------------------------------+------------------------------------- Changes (by rwbarton): * differential: => Phab:D581 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 22 03:35:18 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Dec 2014 03:35:18 -0000 Subject: [GHC] #9916: ghc -e ":foo bar" exit status is inconsistent Message-ID: <047.06f50f6948066823cd93cdc900252d69@haskell.org> #9916: ghc -e ":foo bar" exit status is inconsistent -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: low | Milestone: Component: GHCi | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: #7962, #9905 | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Since #7962 `ghc -e EXPR` exits with status code 1 if `EXPR` fails to compile. While it's undocumented, `ghc -e` does also accept anything that's valid input to GHCi, including GHCi commands like `:t`. In this case, the exit code of `ghc -e` is not always 1 when the command apparently failed. For example, all of: {{{ ghc -e ':t' ghc -e ':t +' ghc -e ':t =' ghc -e ':t x' ghc -e ':l nonexistentfile.hs' }}} exit with status code 0. But `ghc -e ':l a'` exits with status code 1, because `a` is not a (possible) module name or a source file. (At the code level, `ghc -e ":foo bar"` currently exits with status code 1 when the function for `:foo` raises an exception, and with status code 0 in all other cases.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 22 03:54:57 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Dec 2014 03:54:57 -0000 Subject: [GHC] #8650: Unexpected behaviour of import ccall "header.h function" In-Reply-To: <042.6c752e15c4b7ff5eb43bc6ab27a23ec9@haskell.org> References: <042.6c752e15c4b7ff5eb43bc6ab27a23ec9@haskell.org> Message-ID: <057.f3b99354d0f42db4a50ee79660fe4720@haskell.org> #8650: Unexpected behaviour of import ccall "header.h function" -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: invalid | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: Documentation bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => invalid Comment: Basically, by providing the correct header file in the import specification, you gain portability to Haskell compilers which compile via C (including, but not limited to, ancient or unregisterised versions of GHC). Replying to [ticket:8650 nh2]: > In that case, why does http://www.haskell.org/onlinereport/haskell2010/haskellch8.html suggest {{{ccall "string.h strlen"}}}? In the other case, why would it suggest this if the {{{"string.h"}}} part is ignored? Because that is the Haskell 2010 Report, not the GHC documentation (though it would be accurate for unregisterised versions of GHC). > Relatedly, I can write > > {{{ > foreign import ccall "some.rubbish" f :: IO ... > }}} > > and as long as {{{"some.rubbish"}}} contains a dot, nothin in the system will ever complain. As specified by section 8.5.1 of the Report, both the `chname` and the `cid` are optional. The Report does not specify how to resolve the resulting ambiguity, but since a C identifier cannot contain a dot, GHC must be treating `some.rubbish` as the header file name, and using the Haskell name `f` as the C identifier, as also specified by the Report: > If `cid` is omitted, it defaults to the name of the imported Haskell variable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 22 04:29:25 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Dec 2014 04:29:25 -0000 Subject: [GHC] #9904: ghc: out of memory, requested 1048576 bytes on openbsd In-Reply-To: <045.d32cbdc44e8af12b00d61e76d86031a6@haskell.org> References: <045.d32cbdc44e8af12b00d61e76d86031a6@haskell.org> Message-ID: <060.469370e351e515414216cd4602d24f8e@haskell.org> #9904: ghc: out of memory, requested 1048576 bytes on openbsd -----------------------------------+------------------------------------ Reporter: vu3rdd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: cabal-install Operating System: OpenBSD | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -----------------------------------+------------------------------------ Comment (by vu3rdd): Replying to [comment:1 rwbarton]: > Is it possible that your system is actually running out of memory? ghc is rather RAM-hungry > and it might fail to build cabal if you have less than around 1G free. Thanks. I tried increasing the swap by another 1 GB and still get this problem. > In any case, the ghc 7.6 line is no longer being developed so if you do think it may be > a bug in ghc, try ghc 7.8 first (you'll have to install cabal 1.18 or newer to work with ghc 7.8). Thanks. I will try upgrading to cabal 1.18.x. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 22 04:46:25 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Dec 2014 04:46:25 -0000 Subject: [GHC] #9917: ddump-llvm runs opt/llc even when -fllvm isnt set Message-ID: <045.a11323789867f7415acb20ec316ad1c7@haskell.org> #9917: ddump-llvm runs opt/llc even when -fllvm isnt set -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- to reproduce put {{{ main= putStrLn "hello world" }}} in hello.hs and then invoke `ghc hello.hs -O2 -v3 -fforce-recomp -ddump-llvm` then at some point you'll see something like {{{ *** LLVM Optimiser: opt-3.4 /var/folders/py/wgp_hj9d2rl3cx48yym_ynj00000gn/T/ghc88460_0/ghc88460_2.ll -o /var/folders/py/wgp_hj9d2rl3cx48yym_ynj00000gn/T/ghc88460_0/ghc88460_4.bc -O2 '--enable-tbaa=true' *** LLVM Compiler: llc-3.4 -O2 '-relocation-model=pic' /var/folders/py/wgp_hj9d2rl3cx48yym_ynj00000gn/T/ghc88460_0/ghc88460_4.bc -o /var/folders/py/wgp_hj9d2rl3cx48yym_ynj00000gn/T/ghc88460_0/ghc88460_5.lm_s '--enable-tbaa=true' '-mattr=+sse2' *** LLVM Mangler: }}} in the output -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 22 05:17:45 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Dec 2014 05:17:45 -0000 Subject: [GHC] #9903: GHCi produces a cryptic message when using HPC In-Reply-To: <056.3163ec769e71b713310f29b6c2e4fa48@haskell.org> References: <056.3163ec769e71b713310f29b6c2e4fa48@haskell.org> Message-ID: <071.25f2910f9409fde6896bbb56990d3325@haskell.org> #9903: GHCi produces a cryptic message when using HPC -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | Status: new Type: bug | Milestone: Priority: normal | Version: 7.9 Component: GHCi | Keywords: hpc Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHCi crash | Related Tickets: #9878, #9762 ? Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): Replying to [comment:2 rwbarton]: > This is likely the same issue as #9762, yes. After some investigation I no longer think it's the same issue. This one is really about supporting HPC in bytecode objects. In the short term we may just want to bail out of the bytecode compiler if HPC is turned on (with a friendlier message) and suggest that the user use `-fobject-code`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 22 05:19:49 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Dec 2014 05:19:49 -0000 Subject: [GHC] #9762: #8696 + #9012 In-Reply-To: <047.1416552af7b7cba6e17e930c77b546df@haskell.org> References: <047.1416552af7b7cba6e17e930c77b546df@haskell.org> Message-ID: <062.f2404b7e48ccf55181ec1a2955f3a2d2@haskell.org> #9762: #8696 + #9012 -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8696, #9012, Test Case: | #9909 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by rwbarton): * related: #8696, #9012, #9903, #9909 => #8696, #9012, #9909 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 22 05:28:57 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Dec 2014 05:28:57 -0000 Subject: [GHC] #9762: #8696 + #9012 In-Reply-To: <047.1416552af7b7cba6e17e930c77b546df@haskell.org> References: <047.1416552af7b7cba6e17e930c77b546df@haskell.org> Message-ID: <062.8a38fcc4f5bb6290e5fba61a21278423@haskell.org> #9762: #8696 + #9012 -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8696, #9012, Test Case: | #9909 Blocking: | Differential Revisions: Phab:D583 | -------------------------------------+------------------------------------- Changes (by rwbarton): * differential: => Phab:D583 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 22 06:07:18 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Dec 2014 06:07:18 -0000 Subject: [GHC] #9914: Inconsistent handling of leading whitespace in GHCi In-Reply-To: <045.d9bc2fa9e5bed47791a329e1a8e86aaf@haskell.org> References: <045.d9bc2fa9e5bed47791a329e1a8e86aaf@haskell.org> Message-ID: <060.bcefa6f6c1da488f34bdcab1f417378c@haskell.org> #9914: Inconsistent handling of leading whitespace in GHCi -------------------------------------+------------------------------------- Reporter: cactus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Parser) | Keywords: GHCi Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): A simple fix would be to change {{{`isPrefixOf` stmt}}} to {{{`isPrefixOf` removeSpaces stmt}}} (or just `dropWhile isSpace`) in two places in `InteractiveUI.runStmt`. It may be nicer to `removeSpaces` before calling to `runStmt`, but that might not work for multiline commands, not sure what kind of layout rules those have. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 22 06:19:29 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Dec 2014 06:19:29 -0000 Subject: [GHC] #9898: Wanted: higher-order type-level programming In-Reply-To: <045.8f7b834957773169b7810af17c757a81@haskell.org> References: <045.8f7b834957773169b7810af17c757a81@haskell.org> Message-ID: <060.383b32461de432bd0d52c220c4e90c06@haskell.org> #9898: Wanted: higher-order type-level programming -------------------------------------+------------------------------------- Reporter: erisco | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: (Type checker) | Architecture: x86_64 (amd64) Resolution: | Difficulty: Unknown Operating System: Windows | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek): Replying to [comment:6 rwbarton]: > Really? #9433 is marked as merged as 7.8.4 You're right. In that case this behaviour will change in GHC 7.8.4. I don't know why, but my impression was that 7.8.4 will only address some critical LLVM bug. > Or is there a distinction between the "applied to zero arguments" case and the "applied to at least one, but fewer than its arity" case? No, that's the same. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 22 06:21:49 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Dec 2014 06:21:49 -0000 Subject: [GHC] #9872: Runing type functions is too slow In-Reply-To: <046.39f8cd7bfe0ce27cb6afb75f2059ad40@haskell.org> References: <046.39f8cd7bfe0ce27cb6afb75f2059ad40@haskell.org> Message-ID: <061.14c46aa32e370aa3904797f94114348c@haskell.org> #9872: Runing type functions is too slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek): > I'll look forward to trying Janek's tests, which satisfies a direct need: I've been worried that I'm overspecializing to the existing tests, and fresh tests will help. My test is just a promoted `scanr` function generated using `singletons`. So if you need more tests generating them should be fairly straightforward. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 22 06:24:17 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Dec 2014 06:24:17 -0000 Subject: [GHC] #8308: Resurrect ticky code for counting constructor arity In-Reply-To: <048.881ed81a50f663ce5516d17888eb822c@haskell.org> References: <048.881ed81a50f663ce5516d17888eb822c@haskell.org> Message-ID: <063.a5f021de06297aaf65991f57bef4a924@haskell.org> #8308: Resurrect ticky code for counting constructor arity -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: mlen Type: task | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.7 Resolution: | Keywords: newcomer Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Moderate (less Type of failure: Other | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek): mlen, any progress on this one? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 22 06:37:05 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Dec 2014 06:37:05 -0000 Subject: [GHC] #9762: #8696 + #9012 In-Reply-To: <047.1416552af7b7cba6e17e930c77b546df@haskell.org> References: <047.1416552af7b7cba6e17e930c77b546df@haskell.org> Message-ID: <062.3da835c91184d650236bfb6eb34b0010@haskell.org> #9762: #8696 + #9012 -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8696, #9012, Test Case: | #9909 Blocking: | Differential Revisions: Phab:D583 | -------------------------------------+------------------------------------- Comment (by rwbarton): Given that you are using one-shot mode, you can probably work around this bug for now with `-fomit-interface-pragmas` (this must go ''after'' `-O`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 22 08:58:42 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Dec 2014 08:58:42 -0000 Subject: [GHC] #9918: GHC chooses an instance between two overlapping, but cannot resolve a clause within the similar closed type family Message-ID: <045.8b42c360bfa608017b9b2986029ca51e@haskell.org> #9918: GHC chooses an instance between two overlapping, but cannot resolve a clause within the similar closed type family -------------------------------------+------------------------------------- Reporter: qnikst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- We hoped that closed type families could replace overlapping instances. It is not currently the case: GHC can resolve overlapping instances but cannot resolve the similar closed type family. I'm attaching a minimized example of program where it can be observed. This is reproducible on ghc-7.8.3 and HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 22 09:41:28 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Dec 2014 09:41:28 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.1591a41e909fcb7ee2df65c7501b5a62@haskell.org> #6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature | Status: new request | Milestone: 7.12.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Resolution: | Injective Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #4259 Test Case: | Blocking: | Differential Revisions: Phab:D202 | -------------------------------------+------------------------------------- Changes (by jstolarek): * milestone: 7.10.1 => 7.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 22 09:53:31 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Dec 2014 09:53:31 -0000 Subject: [GHC] #8308: Resurrect ticky code for counting constructor arity In-Reply-To: <048.881ed81a50f663ce5516d17888eb822c@haskell.org> References: <048.881ed81a50f663ce5516d17888eb822c@haskell.org> Message-ID: <063.ebd900f5c3f7cd0bfa6ee10c4814fb81@haskell.org> #8308: Resurrect ticky code for counting constructor arity -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: mlen Type: task | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.7 Resolution: | Keywords: newcomer Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Moderate (less Type of failure: Other | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Comment (by mlen): No, sorry. I hope I'll be able to take a look at it again soon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 22 11:04:31 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Dec 2014 11:04:31 -0000 Subject: [GHC] #9914: Inconsistent handling of leading whitespace in GHCi In-Reply-To: <045.d9bc2fa9e5bed47791a329e1a8e86aaf@haskell.org> References: <045.d9bc2fa9e5bed47791a329e1a8e86aaf@haskell.org> Message-ID: <060.95ffa26b81af7f19afce1c8fba7796bd@haskell.org> #9914: Inconsistent handling of leading whitespace in GHCi -------------------------------------+------------------------------------- Reporter: cactus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Parser) | Keywords: GHCi Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Dr. ERDI Gergo ): In [changeset:"707fb3aa2b058cb4245708d6a63019b3e32f795c/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="707fb3aa2b058cb4245708d6a63019b3e32f795c" Strip leading whitespace before checking if a statement looks like a declaration (fixes #9914) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 22 11:05:21 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Dec 2014 11:05:21 -0000 Subject: [GHC] #9914: Inconsistent handling of leading whitespace in GHCi In-Reply-To: <045.d9bc2fa9e5bed47791a329e1a8e86aaf@haskell.org> References: <045.d9bc2fa9e5bed47791a329e1a8e86aaf@haskell.org> Message-ID: <060.c3bd2d0a3a48a44d538137fcba6a574d@haskell.org> #9914: Inconsistent handling of leading whitespace in GHCi -------------------------------------+------------------------------------- Reporter: cactus | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 (Parser) | Keywords: GHCi Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by cactus): * status: new => merge * milestone: => 7.8.4 Comment: That's exactly what I ended up doing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 22 11:05:27 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Dec 2014 11:05:27 -0000 Subject: [GHC] #9918: GHC chooses an instance between two overlapping, but cannot resolve a clause within the similar closed type family In-Reply-To: <045.8b42c360bfa608017b9b2986029ca51e@haskell.org> References: <045.8b42c360bfa608017b9b2986029ca51e@haskell.org> Message-ID: <060.f59d383315a0d645ca7c8c1cfdb83aa7@haskell.org> #9918: GHC chooses an instance between two overlapping, but cannot resolve a clause within the similar closed type family -------------------------------------+------------------------------------- Reporter: qnikst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Can you be more explicit? * What, precisely, are the changes needed to do from "version that does work using overlapping instances" to "version that does not work using closed type families"? * What, as precisely as possible, does not work? * Why did you think it should work? I can't figure that out from the 50 lines of code you give. Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 22 11:42:47 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Dec 2014 11:42:47 -0000 Subject: [GHC] #9918: GHC chooses an instance between two overlapping, but cannot resolve a clause within the similar closed type family In-Reply-To: <045.8b42c360bfa608017b9b2986029ca51e@haskell.org> References: <045.8b42c360bfa608017b9b2986029ca51e@haskell.org> Message-ID: <060.e02db3d1c7f49c29d0e053d9307b216c@haskell.org> #9918: GHC chooses an instance between two overlapping, but cannot resolve a clause within the similar closed type family -------------------------------------+------------------------------------- Reporter: qnikst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by qnikst): Sorry. Yes I can describe better. What we are trying to do: I have a code that uses monadic regions `IORT` and I want to write a function that allow to use a values from parent regions inside it's children `shPutStrLn`. In order to do it I need to write a type class `class (Monad m1, Monad m2) => MonadRaise m1 m2 where lifts :: m1 a -> m2 a` that allow me to lift actions from one monad to another. One solution is to use Overlapping instances (lines 44-51) and it works perfectly. Changes: The idea was to provide a solution that doesn't require OverlappingInstances and uses closed type families to implement `MonadRaise` instead, lines 22-39. The idea was to provide a type family `TEQ` that describes an equality* between monad stacks. equality* - is because we constraint the form of stacks a bit. Instead of having 2 Overlapping instances now we have one that calls a method from no-longer overlapping instance `MonadRaise'` and provides a proxy that is an evidence of our equality*. It worked for all but one tests in our suite. The problem here is that `MonadRaise'` instance can't be deduced now (with or without adding explicit type signature to the test method): {{{ Minimal.hs:58:12: Could not deduce (MonadRaise' (TEQ (IORT s' m') (IORT s (IORT s' m'))) (IORT s' m') (IORT s (IORT s' m'))) arising from a use of ?shPutStrLn? }}} Why I think it should work: I think that it could be possible to deduce MonadRaise' instance because `TEQ (IORT s' m') (IORT s (IORT s' m')` is `False` due to expression on line 24. and we have corresponding instance: `instance (Monad m2, m2 ~ (IORT s m2'), MonadRaise m1 m2') => MonadRaise' False m1 m2 where` line 37. As a result it seems that compiler have all information for selecting an instance of `MonadRaise' False m1 m2` and thus `MonadRaise m1 m2`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 22 11:48:42 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Dec 2014 11:48:42 -0000 Subject: [GHC] #9918: GHC chooses an instance between two overlapping, but cannot resolve a clause within the similar closed type family In-Reply-To: <045.8b42c360bfa608017b9b2986029ca51e@haskell.org> References: <045.8b42c360bfa608017b9b2986029ca51e@haskell.org> Message-ID: <060.2f65ff933ffc2f65858ca03ce0600197@haskell.org> #9918: GHC chooses an instance between two overlapping, but cannot resolve a clause within the similar closed type family -------------------------------------+------------------------------------- Reporter: qnikst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: goldfire (added) Comment: Aha. What I see is {{{ T9918.hs:64:32: Could not deduce (MonadRaise' (TEQ (IORT s' m') (IORT s (IORT s' m'))) (IORT s' m') (IORT s (IORT s' m'))) arising from a use of ?shPutStrLn? from the context (RMonadIO m') bound by the inferred type of test_copy :: RMonadIO m' => t -> FilePath -> IORT s' m' () at T9918.hs:(60,1)-(64,49) In the second argument of ?(>>=)?, namely ?shPutStrLn hout? In the second argument of ?till?, namely ?(return "foo" >>= shPutStrLn hout)? In a stmt of a 'do' block: till (return True) (return "foo" >>= shPutStrLn hout) }}} You are wondering why the first argument to `MonadRaise'`, namely `(TEQ (IORT s' m') (IORT s (IORT s' m')))`, doesn't reduce to `False`. Answer, because the first equation `TEQ m m` is not "surely apart" from `TEQ (IORT s' m') (IORT s (IORT s' m'))`. You may say that to make the first equation for `TEQ` succeed, we would need `m' = IORT s' m'`, which could only happen for infinite types. But, as you'll see from [http://research.microsoft.com/en- us/um/people/simonpj/papers/ext-f/ our closed type-families paper], we found that we had to use a slightly more conservative check, one that allows infinite types, for the surely-apart check. Why doesn't the same thing happen for overlapping type-classes; here GHC does decide that the two type can't be equal (because of the occurs check) and so picks the second commented-out instance, for `MonadRaise m1 m2`. So there are some interesting things here * Your program depends in a very delicate way on the treatment of infinite types. I wonder if it needs to? * Closed type families and type classes are treated differently. That seems inconsistent. In this particular example, I'm not sure which is "right". I'm adding Richard to cc because he may have a view. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 22 12:05:50 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Dec 2014 12:05:50 -0000 Subject: [GHC] #9872: Runing type functions is too slow In-Reply-To: <046.39f8cd7bfe0ce27cb6afb75f2059ad40@haskell.org> References: <046.39f8cd7bfe0ce27cb6afb75f2059ad40@haskell.org> Message-ID: <061.c22a906694c49e0e2214e5e90cabf6c6@haskell.org> #9872: Runing type functions is too slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek): I've been chasing memory leak on my injective type families branch and it seems that these tests are the culprit. When run separately they are harmless and finish in a matter of seconds. However each of them allocates a lot of memory: T9872a: {{{ 2,680,443,384 bytes allocated in the heap 1,341,144,448 bytes copied during GC 230,497,136 bytes maximum residency (10 sample(s)) 1,651,136 bytes maximum slop 465 MB total memory in use (0 MB lost due to fragmentation) Productivity 34.5% of total user, 34.5% of total elapsed }}} T9872b: {{{ 3,480,475,896 bytes allocated in the heap 2,049,027,512 bytes copied during GC 466,737,240 bytes maximum residency (12 sample(s)) 2,234,096 bytes maximum slop 912 MB total memory in use (0 MB lost due to fragmentation) Productivity 33.2% of total user, 33.1% of total elapsed }}} T9872c: {{{ 2,963,257,224 bytes allocated in the heap 1,905,496,768 bytes copied during GC 454,512,352 bytes maximum residency (11 sample(s)) 2,104,512 bytes maximum slop 889 MB total memory in use (0 MB lost due to fragmentation) Productivity 31.2% of total user, 31.2% of total elapsed }}} T9872d: {{{ 740,175,432 bytes allocated in the heap 564,712,136 bytes copied during GC 68,077,728 bytes maximum residency (11 sample(s)) 904,080 bytes maximum slop 174 MB total memory in use (0 MB lost due to fragmentation) Productivity 26.1% of total user, 26.3% of total elapsed }}} So when these tests are run concurrently during validation they eat up ~2,5GB of RAM and that, in conjunction with other things running in the background, is too much for my machine. Note also the productivity: between to 2/3rd and 3/4th of running time is spent on garbage collection. These numbers don't look good. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 22 12:29:47 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Dec 2014 12:29:47 -0000 Subject: [GHC] #9900: Support pattern synonyms in GHCi In-Reply-To: <045.62d6509e4b0cfc58e8f6254c0f951369@haskell.org> References: <045.62d6509e4b0cfc58e8f6254c0f951369@haskell.org> Message-ID: <060.2fb97274caefac881694dd197eb3ace2@haskell.org> #9900: Support pattern synonyms in GHCi -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: feature | Status: new request | Milestone: 7.8.4 Priority: normal | Version: 7.8.3 Component: GHCi | Keywords: PatternSynonyms Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: 9915 Type of failure: GHC | Related Tickets: #8749, #7253 rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by cactus): I have a fix for this on the `wip/T9900` branch, but I'm waiting for instructions on how to trigger a Harbourmaster build on the branch before merging it to `master`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 22 12:53:24 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Dec 2014 12:53:24 -0000 Subject: [GHC] #9879: Panic with partial type signatures In-Reply-To: <047.e5c88bd3f1ae8bc6f7d19321ba46479c@haskell.org> References: <047.e5c88bd3f1ae8bc6f7d19321ba46479c@haskell.org> Message-ID: <062.88598e5cb24569c3294659039d64e1ca@haskell.org> #9879: Panic with partial type signatures -------------------------------------+------------------------------------- Reporter: monoidal | Owner: thomasw Type: bug | Status: patch Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.9 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHCi crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D572 | -------------------------------------+------------------------------------- Changes (by simonpj): * priority: normal => high * status: new => patch * differential: => Phab:D572 * milestone: => 7.10.1 Comment: So Phab:D572 should be merged for 7.10.1, right? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 22 13:24:50 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Dec 2014 13:24:50 -0000 Subject: [GHC] #9881: GHCi gives misleading error message when looking up info of ambiguous type In-Reply-To: <050.4dea55782a9eac6405927023d9d109f3@haskell.org> References: <050.4dea55782a9eac6405927023d9d109f3@haskell.org> Message-ID: <065.5a6ac9d57c8dcf7b15f8b61a96a061fb@haskell.org> #9881: GHCi gives misleading error message when looking up info of ambiguous type -------------------------------------+------------------------------------- Reporter: | Owner: simonpj RyanGlScott | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: GHCi | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Other | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"cf0a55d76cf945a97fc229b77d6e6177fb14125d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="cf0a55d76cf945a97fc229b77d6e6177fb14125d" For :info, return all matching Names, rather than complaining about ambiguity This fixes Trac #9881, and gives more helpful output in the case of ambiguity. Certainly more helpful than the positively-misleading error we get right now. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 22 13:25:42 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Dec 2014 13:25:42 -0000 Subject: [GHC] #9881: GHCi gives misleading error message when looking up info of ambiguous type In-Reply-To: <050.4dea55782a9eac6405927023d9d109f3@haskell.org> References: <050.4dea55782a9eac6405927023d9d109f3@haskell.org> Message-ID: <065.26b9389627bd7f1d9bf748b8f6f49432@haskell.org> #9881: GHCi gives misleading error message when looking up info of ambiguous type -------------------------------------+------------------------------------- Reporter: | Owner: simonpj RyanGlScott | Status: closed Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: GHCi | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Other | Related Tickets: Test Case: | ghci/scripts/T9881 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => ghci/scripts/T9881 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 22 14:41:09 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Dec 2014 14:41:09 -0000 Subject: [GHC] #9900: Support pattern synonyms in GHCi In-Reply-To: <045.62d6509e4b0cfc58e8f6254c0f951369@haskell.org> References: <045.62d6509e4b0cfc58e8f6254c0f951369@haskell.org> Message-ID: <060.c146d3afc485f7761531e168678dbb55@haskell.org> #9900: Support pattern synonyms in GHCi -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: feature | Status: patch request | Milestone: 7.8.4 Priority: normal | Version: 7.8.3 Component: GHCi | Keywords: PatternSynonyms Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: 9915 Type of failure: GHC | Related Tickets: #8749, #7253 rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by cactus): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 22 16:24:59 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Dec 2014 16:24:59 -0000 Subject: [GHC] #9919: Phab doesn't work with Firefox Message-ID: <047.09a40849a5fbcced3bbd2141a88371e3@haskell.org> #9919: Phab doesn't work with Firefox -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I recently got fed up with Chrome's attempts to notify me about things which I don't wish to be notified, and decided to go (back) to Firefox. But, now I discover that Firefox doesn't work completely with Phab! Specifically, on a differential page, I can't click on the little down- arrow to the right of a comment (the one that pulls up the menu containing the "Quote" option), useful if I want to reply. Clicking there has no effect, and my cursor becomes the shape it usually does when I'm about to enter text, not an arrow. I'm using Firefox version 34.0.5, which claims it is up-to-date. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 22 16:33:48 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Dec 2014 16:33:48 -0000 Subject: [GHC] #9919: Phab doesn't work with Firefox In-Reply-To: <047.09a40849a5fbcced3bbd2141a88371e3@haskell.org> References: <047.09a40849a5fbcced3bbd2141a88371e3@haskell.org> Message-ID: <062.4510df19b9796b59efe1c9483e5ca361@haskell.org> #9919: Phab doesn't work with Firefox -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek): Works for me. Have you tried running Firefox in safe mode (without addons)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 22 16:46:08 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Dec 2014 16:46:08 -0000 Subject: [GHC] #9919: Phab doesn't work with Firefox In-Reply-To: <047.09a40849a5fbcced3bbd2141a88371e3@haskell.org> References: <047.09a40849a5fbcced3bbd2141a88371e3@haskell.org> Message-ID: <062.0bd15a99a52ca0869d8eb6b821f9e938@haskell.org> #9919: Phab doesn't work with Firefox -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: worksforme | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => worksforme Comment: Silly me. I wasn't logged in, as my login cookie didn't transfer. But, the total lack of UI feedback was quite confusing. I filed an upstream low- priority bug [https://secure.phabricator.com/T6798 here]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 22 18:12:06 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Dec 2014 18:12:06 -0000 Subject: [GHC] #9918: GHC chooses an instance between two overlapping, but cannot resolve a clause within the similar closed type family In-Reply-To: <045.8b42c360bfa608017b9b2986029ca51e@haskell.org> References: <045.8b42c360bfa608017b9b2986029ca51e@haskell.org> Message-ID: <060.e04c0303a7894a4df46b82ecde8c8841@haskell.org> #9918: GHC chooses an instance between two overlapping, but cannot resolve a clause within the similar closed type family -------------------------------------+------------------------------------- Reporter: qnikst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): I agree with Simon's analysis. The fact that thinking about infinite types means closed type families are less useful in more prosaic situations is annoying. But I don't know a way around this. About Simon's interesting point (2): Some testing that I've done has made me even more confused, because I can't seem to witness the inconsistency. Are you sure that `OverlappingInstances` works here, even to select the `MonadRaise m m` instance? In my example, I was unable to get GHC to commit to the tyvars-equal instance without `IncoherentInstances` -- behavior I agree with. (It would destroy the type system to allow `IncoherentInstances`-like behavior with closed type families!) I will say that your technique of using closed type families to produce some switch to control instance selection to avoid overlapping instances is a good way to do this. Of course, instance chains would be better -- which, of course, are just like closed type families for class instances. Since we don't have instance chains, you're doing the next-best thing, in my opinion. My bottom line: I'm a little confused here, too. I believe that if GHC treats overlapping instances without the infinite-type reasoning, it would be possible to squeeze out proper incoherence among instances even without `IncoherentInstances`. But I couldn't seem to get it to happen! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 22 18:15:23 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Dec 2014 18:15:23 -0000 Subject: [GHC] #9872: Runing type functions is too slow In-Reply-To: <046.39f8cd7bfe0ce27cb6afb75f2059ad40@haskell.org> References: <046.39f8cd7bfe0ce27cb6afb75f2059ad40@haskell.org> Message-ID: <061.f18ec779e982cdf52d50a38262be2f20@haskell.org> #9872: Runing type functions is too slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): An interesting observation here is that the performance tests should probably never be run in parallel. :) Perhaps open a new feature request for this? I continue to think that comment:25 is the way to go forward here. But that's a lot of work! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 22 18:49:21 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Dec 2014 18:49:21 -0000 Subject: [GHC] #9918: GHC chooses an instance between two overlapping, but cannot resolve a clause within the similar closed type family In-Reply-To: <045.8b42c360bfa608017b9b2986029ca51e@haskell.org> References: <045.8b42c360bfa608017b9b2986029ca51e@haskell.org> Message-ID: <060.f3401241f447288b13b74f4f9f687f64@haskell.org> #9918: GHC chooses an instance between two overlapping, but cannot resolve a clause within the similar closed type family -------------------------------------+------------------------------------- Reporter: qnikst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by qnikst): Thanks for replies. > Your program depends in a very delicate way on the treatment of infinite types. I wonder if it needs to? I need to think more about this, at this moment if was the most obvious way how to write required instances, but possibly there are more ways around. > Are you sure that OverlappingInstances works here, even to select the MonadRaise m m instance? I've just checked the minimal example and I need to say that it doesn't choose `MonadRaise m m`, without explicit type signature: {{{ test_2 = do hout <- newSHandle shPutStrLn hout }}} however adding `test_2 :: IORT s IO ()` helps, in case of type families adding explicit type signature didn't help me in my experiments. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 22 19:25:22 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Dec 2014 19:25:22 -0000 Subject: [GHC] #9872: Runing type functions is too slow In-Reply-To: <046.39f8cd7bfe0ce27cb6afb75f2059ad40@haskell.org> References: <046.39f8cd7bfe0ce27cb6afb75f2059ad40@haskell.org> Message-ID: <061.408b55a6c892c9e6602e06dca12bce21@haskell.org> #9872: Runing type functions is too slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek): Let me only remark that these numbers were taken in a separate runs, not parallel ones. Richard, so you're seeing similar numbers for these tests? GC time actually looks pretty bad and I think it deserves a bug report, not just a feature request. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 22 21:57:39 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Dec 2014 21:57:39 -0000 Subject: [GHC] #9872: Runing type functions is too slow In-Reply-To: <046.39f8cd7bfe0ce27cb6afb75f2059ad40@haskell.org> References: <046.39f8cd7bfe0ce27cb6afb75f2059ad40@haskell.org> Message-ID: <061.44c224e988c9bf217e4a247c0468528c@haskell.org> #9872: Runing type functions is too slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Comment:25 is a bit cryptic. What sort of "compilation" or "optimisation" did you have in mind? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 22 23:34:43 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Dec 2014 23:34:43 -0000 Subject: [GHC] #9920: Segfault in arm binary Message-ID: <044.555edb7e560a8d41cf35aba7c1c44446@haskell.org> #9920: Segfault in arm binary ----------------------------+------------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: arm | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------+------------------------------------------- Using ghc HEAD (6713f0d9a) I compile a very simple program which segfaults immediately. Stepping through it using GDB I find its crashing on the instruction {{{ 0x3f5a98 ldr r5, [r5] }}} and that just before this instruction the value of `r5` is zero. That means its trying to load into `r5` the value at the address in `r5`. Obviously that's going to segfault. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 23 00:35:50 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Dec 2014 00:35:50 -0000 Subject: [GHC] #9920: Segfault in arm binary In-Reply-To: <044.555edb7e560a8d41cf35aba7c1c44446@haskell.org> References: <044.555edb7e560a8d41cf35aba7c1c44446@haskell.org> Message-ID: <059.3cf23752af2ada220b79aba9b06ca068@haskell.org> #9920: Segfault in arm binary -------------------------------------------+--------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------------+--------------------------- Changes (by erikd): * version: 7.9 => 7.11 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 23 00:40:45 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Dec 2014 00:40:45 -0000 Subject: [GHC] #9885: ghc-pkg parser eats too much memory In-Reply-To: <045.91c2102f5d7dc20ac2d922c7041cfbfb@haskell.org> References: <045.91c2102f5d7dc20ac2d922c7041cfbfb@haskell.org> Message-ID: <060.640e38c8bbe6e66032b36c2954383aaa@haskell.org> #9885: ghc-pkg parser eats too much memory -------------------------------------+------------------------------------- Reporter: gnezdo | Owner: Type: bug | Status: new Priority: low | Milestone: Component: ghc-pkg | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Moderate (less performance bug | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Changes (by gnezdo): * priority: normal => low Comment: My workaround for this was to split the long comma separated list of ld- options into multiple ld-options with one item per line. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 23 00:43:28 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Dec 2014 00:43:28 -0000 Subject: [GHC] #9920: Segfault in arm binary In-Reply-To: <044.555edb7e560a8d41cf35aba7c1c44446@haskell.org> References: <044.555edb7e560a8d41cf35aba7c1c44446@haskell.org> Message-ID: <059.57f8755291af7c2a86d25c68bd0450c1@haskell.org> #9920: Segfault in arm binary -------------------------------------------+--------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------------+--------------------------- Comment (by erikd): This problem occurs both with and without the two gold linker patches from #9873. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 23 02:31:03 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Dec 2014 02:31:03 -0000 Subject: [GHC] #9920: Segfault in arm binary In-Reply-To: <044.555edb7e560a8d41cf35aba7c1c44446@haskell.org> References: <044.555edb7e560a8d41cf35aba7c1c44446@haskell.org> Message-ID: <059.a1d00e90a7e7cd4018b268f9266f3ff2@haskell.org> #9920: Segfault in arm binary -------------------------------------------+--------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------------+--------------------------- Comment (by erikd): The function `stg_init_finish` is defined in `rts/StgStartup.cmm` as: {{{ stg_init_finish /* no args: explicit stack layout */ { jump StgReturn []; } }}} and the generated assembly (from a different binary) looks like: {{{ 0x211fc4 ldr r5, [r4, #792] ; 0x318 0x211fc8 ldr r0, [r5], #4 }}} but when I step through the code, it looks like the first of these two instructions are not executed. Howver, if I set a breakpoint at address `0x211fc4` it does indeed halt there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 23 02:45:35 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Dec 2014 02:45:35 -0000 Subject: [GHC] #9872: Runing type functions is too slow In-Reply-To: <046.39f8cd7bfe0ce27cb6afb75f2059ad40@haskell.org> References: <046.39f8cd7bfe0ce27cb6afb75f2059ad40@haskell.org> Message-ID: <061.5aae2e4546b75521a66c5f405a980d22@haskell.org> #9872: Runing type functions is too slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): I don't have anything in particular in mind -- just that we happen to have some expertise on taking a functional program and executing it quickly, and perhaps we can apply that knowledge to this problem. It seems to me that the algorithm used to reduce type families evolved out of a constraint-solving process, and taking a more direct tack might prove fruitful, while still retaining the ability to work with programs where bits (skolem type variables) aren't -- and can't be -- known. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 23 03:25:05 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Dec 2014 03:25:05 -0000 Subject: [GHC] #9920: Segfault in arm binary In-Reply-To: <044.555edb7e560a8d41cf35aba7c1c44446@haskell.org> References: <044.555edb7e560a8d41cf35aba7c1c44446@haskell.org> Message-ID: <059.19d7fd5156c3d819535300984c9695ae@haskell.org> #9920: Segfault in arm binary -------------------------------------------+--------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------------+--------------------------- Comment (by bgamari): For the record this is built with LLVM 3.5. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 23 03:39:26 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Dec 2014 03:39:26 -0000 Subject: [GHC] #9386: GHCi cannot load .so in ./ In-Reply-To: <047.6d829b9ae97b1073447115aeba1e6bb7@haskell.org> References: <047.6d829b9ae97b1073447115aeba1e6bb7@haskell.org> Message-ID: <062.d9b7679626121b16c6641d9266037bcb@haskell.org> #9386: GHCi cannot load .so in ./ -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): hvr: presumably dlopen is finding the `libbsd.so` on your library path, not the one in `.`. I can reproduce this in 7.8.3 but not in HEAD, so I guess it is fixed, though I don't know why yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 23 04:15:40 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Dec 2014 04:15:40 -0000 Subject: [GHC] #9920: Segfault in arm binary In-Reply-To: <044.555edb7e560a8d41cf35aba7c1c44446@haskell.org> References: <044.555edb7e560a8d41cf35aba7c1c44446@haskell.org> Message-ID: <059.985cf2634bbd61ab71120fc9686de26e@haskell.org> #9920: Segfault in arm binary -------------------------------------------+--------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------------+--------------------------- Comment (by erikd): With the help of @bgamari and @rwbarton, we found that function `stg_init_finish` ends up being zero length so that it and function `stg_init` have the same address. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 23 04:19:04 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Dec 2014 04:19:04 -0000 Subject: [GHC] #9386: GHCi cannot load .so in ./ In-Reply-To: <047.6d829b9ae97b1073447115aeba1e6bb7@haskell.org> References: <047.6d829b9ae97b1073447115aeba1e6bb7@haskell.org> Message-ID: <062.30c6559b9a7cb8c1c65ac18fa50f2b3f@haskell.org> #9386: GHCi cannot load .so in ./ -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): Actually it's not fixed, it just works for the inplace GHC only, because the `inplace/bin/ghc-stage2` sets `LD_LIBRARY_PATH=...:$LD_LIBRARY_PATH`, my existing `LD_LIBRARY_PATH` is empty and so GHC's `LD_LIBRARY_PATH` gets an empty component at the end, which is interpreted as the current directory... It's actually not entirely clear what the behavior of `ghci Foo libbar.so` ''should'' be; maybe it should search the system library path for `libbar.so`, like it does today? But I'm inclined to say not, since you could get that behavior with `ghci Foo -lbar` instead. The fact that it doesn't work even when you specify `./mylib.so` is clearly wrong. I guess the pathname gets normalized before being passed to `dlopen`, but I don't yet know where or why. I'm inclined to fix it with a hammer by prepending `./` to the `dlopen` argument whenever it is a relative pathname (if its argument contains a `/` then `dlopen` will treat it is as a pathname and not search the system library path). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 23 05:13:19 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Dec 2014 05:13:19 -0000 Subject: [GHC] #9920: Segfault in arm binary In-Reply-To: <044.555edb7e560a8d41cf35aba7c1c44446@haskell.org> References: <044.555edb7e560a8d41cf35aba7c1c44446@haskell.org> Message-ID: <059.03ab68442f67fff1c755d9031a76f1a5@haskell.org> #9920: Segfault in arm binary -------------------------------------------+--------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------------+--------------------------- Changes (by erikd): * cc: bgamari, rwbarton (added) Comment: Captured the various tmp files when compiling `rts/StgStartup.cmm`. The disassembled llvm byte code for `stg_init_finish` and `stg_init` look like this: {{{ ; Function Attrs: nounwind define cc10 void @"stg_init_finish$def"(i32* noalias nocapture %Base_Arg , i32* noalias nocapture %Sp_Arg, i32* noalias nocapture %Hp_Arg , i32 %R1_Arg, i32 %R2_Arg, i32 %R3_Arg , i32 %R4_Arg, i32 %SpLim_Arg) #0 align 4 { cF: tail call cc10 void bitcast (i8* @StgReturn to void (i32*, i32*, i32*, i32, i32, i32, i32, i32)*)(i32* %Base_Arg , i32* %Sp_Arg, i32* %Hp_Arg, i32 %R1_Arg, i32 undef , i32 undef, i32 undef, i32 %SpLim_Arg) #0 ret void } ; Function Attrs: nounwind define cc10 void @"stg_init$def"(i32* noalias nocapture %Base_Arg , i32* noalias nocapture readnone %Sp_Arg , i32* noalias nocapture %Hp_Arg, i32 %R1_Arg, i32 %R2_Arg , i32 %R3_Arg, i32 %R4_Arg, i32 %SpLim_Arg) #0 align 4 { cH: %ln5z = getelementptr inbounds i32* %Base_Arg, i32 198 .... }}} which is fine, but when that gets run through `llc` we get the following assembly code: {{{ .text .globl stg_init_finish$def .align 2 .type stg_init_finish$def,%function stg_init_finish$def: @ @"stg_init_finish$def" .fnstart .Leh_func_begin7: @ BB#0: @ %cF .Ltmp7: .size stg_init_finish$def, .Ltmp7-stg_init_finish$def .cantunwind .fnend .globl stg_init$def .align 2 .type stg_init$def,%function stg_init$def: @ @"stg_init$def" .fnstart .Leh_func_begin8: @ BB#0: @ %cH ldr r5, [r4, #792] ldr r0, [r5], #4 .Ltmp8: .size stg_init$def, .Ltmp8-stg_init$def .cantunwind .fnend }}} For some reason `llc` is dropping the actual body of the function `stg_init_finish`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 23 12:30:49 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Dec 2014 12:30:49 -0000 Subject: [GHC] #9732: Pattern synonyms and unboxed values In-Reply-To: <047.98d7de74203e4f381291a803ad282f11@haskell.org> References: <047.98d7de74203e4f381291a803ad282f11@haskell.org> Message-ID: <062.90ce8255282d592b4b4cb5e7121f2043@haskell.org> #9732: Pattern synonyms and unboxed values -------------------------------------+------------------------------------- Reporter: monoidal | Owner: cactus Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: PatternSynonyms Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * milestone: 7.8.4 => 7.10.1 Comment: 7.8.4 is already done; closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 23 12:30:50 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Dec 2014 12:30:50 -0000 Subject: [GHC] #9783: Pattern synonym matcher is unnecessarily strict on unboxed continuations In-Reply-To: <045.fbfedd3216f2b9704ce7d408adca131b@haskell.org> References: <045.fbfedd3216f2b9704ce7d408adca131b@haskell.org> Message-ID: <060.999beade108d2d0b7b93af571e76ece1@haskell.org> #9783: Pattern synonym matcher is unnecessarily strict on unboxed continuations -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: PatternSynonyms Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: 9732 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * milestone: 7.8.4 => 7.10.1 Comment: 7.8.4 is already done; closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 23 12:30:54 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Dec 2014 12:30:54 -0000 Subject: [GHC] #9914: Inconsistent handling of leading whitespace in GHCi In-Reply-To: <045.d9bc2fa9e5bed47791a329e1a8e86aaf@haskell.org> References: <045.d9bc2fa9e5bed47791a329e1a8e86aaf@haskell.org> Message-ID: <060.ef3ea14512c85fa97cca75a917b54ca2@haskell.org> #9914: Inconsistent handling of leading whitespace in GHCi -------------------------------------+------------------------------------- Reporter: cactus | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 (Parser) | Keywords: GHCi Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: 7.8.4 => 7.10.1 Comment: 7.8.4 is already done; closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 23 12:30:56 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Dec 2014 12:30:56 -0000 Subject: [GHC] #9915: GHCi has trouble with 'foreign' when it is not a keyword In-Reply-To: <045.ba44943d473f217b93194b5df3e50a38@haskell.org> References: <045.ba44943d473f217b93194b5df3e50a38@haskell.org> Message-ID: <060.4ba523806724d4548b77bf3f68055daa@haskell.org> #9915: GHCi has trouble with 'foreign' when it is not a keyword -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 (Parser) | Keywords: GHCi Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | ghci/should_compile/T9915 | Blocking: 9900 | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed * milestone: 7.8.4 => 7.10.1 Comment: 7.8.4 is already done; closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 23 12:30:57 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Dec 2014 12:30:57 -0000 Subject: [GHC] #9900: Support pattern synonyms in GHCi In-Reply-To: <045.62d6509e4b0cfc58e8f6254c0f951369@haskell.org> References: <045.62d6509e4b0cfc58e8f6254c0f951369@haskell.org> Message-ID: <060.b7a54dc945004529e46ae2f27a4b2c4d@haskell.org> #9900: Support pattern synonyms in GHCi -------------------------------------+------------------------------------- Reporter: cactus | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.8.3 Component: GHCi | Keywords: PatternSynonyms Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: 9915 Type of failure: GHC | Related Tickets: #8749, #7253 rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * owner: cactus => * status: patch => new * milestone: 7.8.4 => 7.10.1 Comment: This isn't making it to 7.8.4; it's already done. We can put it in for 7.10 RC2, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 23 12:31:10 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Dec 2014 12:31:10 -0000 Subject: [GHC] #9900: Support pattern synonyms in GHCi In-Reply-To: <045.62d6509e4b0cfc58e8f6254c0f951369@haskell.org> References: <045.62d6509e4b0cfc58e8f6254c0f951369@haskell.org> Message-ID: <060.20d18082137d9b4c39be71dc2273e513@haskell.org> #9900: Support pattern synonyms in GHCi -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.8.3 Component: GHCi | Keywords: PatternSynonyms Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: 9915 Type of failure: GHC | Related Tickets: #8749, #7253 rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * owner: => cactus -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 23 13:27:30 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Dec 2014 13:27:30 -0000 Subject: [GHC] #9914: Inconsistent handling of leading whitespace in GHCi In-Reply-To: <045.d9bc2fa9e5bed47791a329e1a8e86aaf@haskell.org> References: <045.d9bc2fa9e5bed47791a329e1a8e86aaf@haskell.org> Message-ID: <060.bf64b147b1dc8bfd317852d0dc6fa84e@haskell.org> #9914: Inconsistent handling of leading whitespace in GHCi -------------------------------------+------------------------------------- Reporter: cactus | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 (Parser) | Keywords: GHCi Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 23 13:29:25 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Dec 2014 13:29:25 -0000 Subject: [GHC] #7788: Recursive type family causes <> In-Reply-To: <046.ea3ef9ceaabda348ee27e147f6e7ebb3@haskell.org> References: <046.ea3ef9ceaabda348ee27e147f6e7ebb3@haskell.org> Message-ID: <061.e54da2f40052a2cec023d7320d453874@haskell.org> #7788: Recursive type family causes <> -------------------------------------+------------------------------------- Reporter: shachaf | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.6.2 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: result at runtime | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Does anyone actually care about programs with non-terminating type computations? The type inference engine makes no claim to be a lazy evaluator. So if you write non-terminating type-level expressions, the compiler may loop. I agree that it might be more puzzling if the compiler succeeds but the program loops at runtime. But that doesn't seem to be happening right now. If this matters to anyone, sing out. Otherwise I'm going to leave it. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 23 13:33:23 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Dec 2014 13:33:23 -0000 Subject: [GHC] Batch modify: #344, #602, #1012, #1016, #1330, #1365, #1377, #1379, #1420, #1534, #1572, #1574, #1600, #1612, #1631, #1693, #1727, #1820, #1853, #1880, #1883, #1885, #1894, #2028, #2064, #2075, #2119, #2123, #2135, #2140, #2147, #2159, #2168, #2215, #2224, #2256, #2258, #2260, #2269, #2273, #2289, #2333, #2340, #2345, #2346, #2365, #2370, #2374, #2387, #2437, #2439, #2459, #2460, #2514, #2522, #2530, #2531, #2598, #2600, #2640, #2641, #2642, #2648, #2710, #2721, #2731, #2737, #2776, #2803, #2805, #2867, #2933, #2940, #2945, #2946, #2950, #2968, #2986, #2988, #2991, #3000, #3034, #3061, #3070, #3073, #3107, #3122, #3123, #3138, #3140, #3192, #3238, #3251, #3282, #3314, #3321, #3351, #3355, #3452, #3458, #3533, #3571, #3606, #3711, #3781, #3870, #3960, #4017, #4022, #8782 Message-ID: <20141223133323.25C333A2FF@ghc.haskell.org> Batch modification to #344, #602, #1012, #1016, #1330, #1365, #1377, #1379, #1420, #1534, #1572, #1574, #1600, #1612, #1631, #1693, #1727, #1820, #1853, #1880, #1883, #1885, #1894, #2028, #2064, #2075, #2119, #2123, #2135, #2140, #2147, #2159, #2168, #2215, #2224, #2256, #2258, #2260, #2269, #2273, #2289, #2333, #2340, #2345, #2346, #2365, #2370, #2374, #2387, #2437, #2439, #2459, #2460, #2514, #2522, #2530, #2531, #2598, #2600, #2640, #2641, #2642, #2648, #2710, #2721, #2731, #2737, #2776, #2803, #2805, #2867, #2933, #2940, #2945, #2946, #2950, #2968, #2986, #2988, #2991, #3000, #3034, #3061, #3070, #3073, #3107, #3122, #3123, #3138, #3140, #3192, #3238, #3251, #3282, #3314, #3321, #3351, #3355, #3452, #3458, #3533, #3571, #3606, #3711, #3781, #3870, #3960, #4017, #4022, #8782 by thoughtpolice: milestone to 7.12.1 Comment: Moving to 7.12.1 milestone; if you feel this is an error and should be addressed sooner, please move it back to the 7.10.1 milestone. -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 23 13:33:23 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Dec 2014 13:33:23 -0000 Subject: [GHC] Batch modify: #344, #602, #1012, #1016, #1330, #1365, #1377, #1379, #1420, #1534, #1572, #1574, #1600, #1612, #1631, #1693, #1727, #1820, #1853, #1880, #1883, #1885, #1894, #2028, #2064, #2075, #2119, #2123, #2135, #2140, #2147, #2159, #2168, #2215, #2224, #2256, #2258, #2260, #2269, #2273, #2289, #2333, #2340, #2345, #2346, #2365, #2370, #2374, #2387, #2437, #2439, #2459, #2460, #2514, #2522, #2530, #2531, #2598, #2600, #2640, #2641, #2642, #2648, #2710, #2721, #2731, #2737, #2776, #2803, #2805, #2867, #2933, #2940, #2945, #2946, #2950, #2968, #2986, #2988, #2991, #3000, #3034, #3061, #3070, #3073, #3107, #3122, #3123, #3138, #3140, #3192, #3238, #3251, #3282, #3314, #3321, #3351, #3355, #3452, #3458, #3533, #3571, #3606, #3711, #3781, #3870, #3960, #4017, #4022, #8782 Message-ID: <20141223133323.6358E3A300@ghc.haskell.org> Batch modification to #344, #602, #1012, #1016, #1330, #1365, #1377, #1379, #1420, #1534, #1572, #1574, #1600, #1612, #1631, #1693, #1727, #1820, #1853, #1880, #1883, #1885, #1894, #2028, #2064, #2075, #2119, #2123, #2135, #2140, #2147, #2159, #2168, #2215, #2224, #2256, #2258, #2260, #2269, #2273, #2289, #2333, #2340, #2345, #2346, #2365, #2370, #2374, #2387, #2437, #2439, #2459, #2460, #2514, #2522, #2530, #2531, #2598, #2600, #2640, #2641, #2642, #2648, #2710, #2721, #2731, #2737, #2776, #2803, #2805, #2867, #2933, #2940, #2945, #2946, #2950, #2968, #2986, #2988, #2991, #3000, #3034, #3061, #3070, #3073, #3107, #3122, #3123, #3138, #3140, #3192, #3238, #3251, #3282, #3314, #3321, #3351, #3355, #3452, #3458, #3533, #3571, #3606, #3711, #3781, #3870, #3960, #4017, #4022, #8782 by thoughtpolice: milestone to 7.12.1 Comment: Moving to 7.12.1 milestone; if you feel this is an error and should be addressed sooner, please move it back to the 7.10.1 milestone. -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 23 13:33:46 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Dec 2014 13:33:46 -0000 Subject: [GHC] Batch modify: #1498, #2401, #2614, #3052, #3184, #3372, #3373, #3427, #3462, #3464, #3483, #3547, #3559, #3588, #3619, #3632, #3645, #3649, #3699, #3701, #3704, #3712, #3713, #3744, #3753, #3755, #3766, #3767, #3782, #3786, #3869, #3881, #3895, #3903, #3937, #3946, #3980, #3990, #4016, #4020, #4048, #4049, #4052, #4081, #4096, #4101, #4105, #4114, #4121, #4140, #4150, #4162, #4176, #4180, #4213, #4215, #4222, #4281, #4288, #4296, #4301, #4308, #4316, #4329, #4340, #4366, #4413, #4440, #4442, #4453, #4459, #4466, #4471, #4479, #4520, #4800, #4806, #4815, #4823, #4824, #4831, #4833, #4836, #4837, #4861, #4899, #4913, #4931, #4938, #4942, #4955, #4959, #4960, #4980, #5014, #5016, #5059, #5063, #5073, #5140, #5142, #5171, #5188, #5197, #5219, #5224, #5251, #5262, #5266, #5267, #5273, #5288, #5291, #5296, #5298, #5302, #5305, #5326, #5333, #5376, #5378, #5495, #5654, #5918, #5959, #8156, #8258, #8303, #8539, #8959, #9247, #9260, #9307 Message-ID: <20141223133346.15C793A2FF@ghc.haskell.org> Batch modification to #1498, #2401, #2614, #3052, #3184, #3372, #3373, #3427, #3462, #3464, #3483, #3547, #3559, #3588, #3619, #3632, #3645, #3649, #3699, #3701, #3704, #3712, #3713, #3744, #3753, #3755, #3766, #3767, #3782, #3786, #3869, #3881, #3895, #3903, #3937, #3946, #3980, #3990, #4016, #4020, #4048, #4049, #4052, #4081, #4096, #4101, #4105, #4114, #4121, #4140, #4150, #4162, #4176, #4180, #4213, #4215, #4222, #4281, #4288, #4296, #4301, #4308, #4316, #4329, #4340, #4366, #4413, #4440, #4442, #4453, #4459, #4466, #4471, #4479, #4520, #4800, #4806, #4815, #4823, #4824, #4831, #4833, #4836, #4837, #4861, #4899, #4913, #4931, #4938, #4942, #4955, #4959, #4960, #4980, #5014, #5016, #5059, #5063, #5073, #5140, #5142, #5171, #5188, #5197, #5219, #5224, #5251, #5262, #5266, #5267, #5273, #5288, #5291, #5296, #5298, #5302, #5305, #5326, #5333, #5376, #5378, #5495, #5654, #5918, #5959, #8156, #8258, #8303, #8539, #8959, #9247, #9260, #9307 by thoughtpolice: milestone to 7.12.1 Comment: Moving to 7.12.1 milestone; if you feel this is an error and should be addressed sooner, please move it back to the 7.10.1 milestone. -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 23 13:34:12 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Dec 2014 13:34:12 -0000 Subject: [GHC] Batch modify: #229, #609, #849, #888, #1216, #1349, #1466, #1544, #1620, #1965, #2189, #2408, #2725, #3055, #3085, #3217, #3231, #3242, #3379, #3831, #3927, #3984, #4012, #4092, #4102, #4211, #4243, #4245, #4259, #4295, #4372, #4374, #4385, #4451, #4470, #4879, #4900, #4937, #5075, #5108, #5143, #5218, #5239, #5289, #5320, #5355, #5364, #5369, #5392, #5429, #5444, #5463, #5467, #5470, #5522, #5539, #5542, #5556, #5567, #5590, #5615, #5619, #5620, #5641, #5642, #5645, #5646, #5666, #5672, #5692, #5702, #5757, #5761, #5775, #5777, #5780, #5786, #5791, #5807, #5813, #5821, #5823, #5834, #5835, #5840, #5902, #5916, #5927, #5928, #5941, #5945, #5954, #5972, #5985, #6004, #6017, #6024, #6037, #6040, #6047, #6070, #6079, #6087, #6089, #6092, #6101, #6107, #6113, #6124, #6132, #6166, #7044, #7045, #7048, #7056, #7057, #7063, #7066, #7078, #7081, #7098, #7103, #7104, #7105, #7109, #7114, #7133, #7140, #7141, #7152, #7158, #7161, #7169, #7181, #7190, #7198, #7204, #7240, #7245, #7246, #7253, #7258, #7259, #7275, #7277, #7283, #7285, #7289, #7296, #7297, #7300, #7305, #7307, #7316, #7330, #7331, #7335, #7337, #7353, #7367, #7371, #7373, #7374, #7378, #7380, #7388, #7389, #7395, #7398, #7401, #7413, #7414, #7428, #7430, #7437, #7443, #7450, #7459, #7461, #7473, #7492, #7494, #7495, #7503, #7511, #7535, #7539, #7542, #7543, #7593, #7596, #7604, #7606, #7608, #7610, #7611, #7621, #7624, #7625, #7634, #7635, #7637, #7644, #7647, #7650, #7655, #7660, #7665, #7666, #7668, #7669, #7670, #7672, #7687, #7695, #7723, #7741, #7746, #7763, #7765, #7779, #7789, #7790, #7803, #7808, #7810, #7828, #7829, #7836, #7849, #7883, #7983, #8010, #8014, #8034, #8036, #8107, #8144, #8198, #8199, #8226, #8229, #8238, #8252, #8272, #8281, #8285, #8288, #8321, #8323, #8362, #8379, #8398, #8405, #8422, #8423, #8429, #8457, #8489, #8581, #8594, #8623, #8657, #8694, #8695, #8731, #8732, #8733, #8746, #8751, #8761, #8767, #8793, #8827, #8910, #8920, #8922, #8971, #8976, #8981, #9014, #9022, #9034, #9043, #9046, #9089, #9094, #9133, #9218, #9237, #9238, #9248, #9251, #9274, #9289, #9331, #9342, #9352, #9353, #9358, #9405, #9453, #9526, #9573, #9586, #9588, #9596, #9600, #9601, #9606, #9614, #9618, #9638, #9649, #9671, #9674, #9682, #9716, #9717, #9735, #9743, #9744, #9751, #9760, #9769, #9772, #9792, #9793, #9797, #9799, #9821, #9823, #9841, #9858, #9890, #9895, #9899, #9900, #9911 Message-ID: <20141223133412.436C13A2FF@ghc.haskell.org> Batch modification to #229, #609, #849, #888, #1216, #1349, #1466, #1544, #1620, #1965, #2189, #2408, #2725, #3055, #3085, #3217, #3231, #3242, #3379, #3831, #3927, #3984, #4012, #4092, #4102, #4211, #4243, #4245, #4259, #4295, #4372, #4374, #4385, #4451, #4470, #4879, #4900, #4937, #5075, #5108, #5143, #5218, #5239, #5289, #5320, #5355, #5364, #5369, #5392, #5429, #5444, #5463, #5467, #5470, #5522, #5539, #5542, #5556, #5567, #5590, #5615, #5619, #5620, #5641, #5642, #5645, #5646, #5666, #5672, #5692, #5702, #5757, #5761, #5775, #5777, #5780, #5786, #5791, #5807, #5813, #5821, #5823, #5834, #5835, #5840, #5902, #5916, #5927, #5928, #5941, #5945, #5954, #5972, #5985, #6004, #6017, #6024, #6037, #6040, #6047, #6070, #6079, #6087, #6089, #6092, #6101, #6107, #6113, #6124, #6132, #6166, #7044, #7045, #7048, #7056, #7057, #7063, #7066, #7078, #7081, #7098, #7103, #7104, #7105, #7109, #7114, #7133, #7140, #7141, #7152, #7158, #7161, #7169, #7181, #7190, #7198, #7204, #7240, #7245, #7246, #7253, #7258, #7259, #7275, #7277, #7283, #7285, #7289, #7296, #7297, #7300, #7305, #7307, #7316, #7330, #7331, #7335, #7337, #7353, #7367, #7371, #7373, #7374, #7378, #7380, #7388, #7389, #7395, #7398, #7401, #7413, #7414, #7428, #7430, #7437, #7443, #7450, #7459, #7461, #7473, #7492, #7494, #7495, #7503, #7511, #7535, #7539, #7542, #7543, #7593, #7596, #7604, #7606, #7608, #7610, #7611, #7621, #7624, #7625, #7634, #7635, #7637, #7644, #7647, #7650, #7655, #7660, #7665, #7666, #7668, #7669, #7670, #7672, #7687, #7695, #7723, #7741, #7746, #7763, #7765, #7779, #7789, #7790, #7803, #7808, #7810, #7828, #7829, #7836, #7849, #7883, #7983, #8010, #8014, #8034, #8036, #8107, #8144, #8198, #8199, #8226, #8229, #8238, #8252, #8272, #8281, #8285, #8288, #8321, #8323, #8362, #8379, #8398, #8405, #8422, #8423, #8429, #8457, #8489, #8581, #8594, #8623, #8657, #8694, #8695, #8731, #8732, #8733, #8746, #8751, #8761, #8767, #8793, #8827, #8910, #8920, #8922, #8971, #8976, #8981, #9014, #9022, #90 34, #9043, #9046, #9089, #9094, #9133, #9218, #9237, #9238, #9248, #9251, #9274, #9289, #9331, #9342, #9352, #9353, #9358, #9405, #9453, #9526, #9573, #9586, #9588, #9596, #9600, #9601, #9606, #9614, #9618, #9638, #9649, #9671, #9674, #9682, #9716, #9717, #9735, #9743, #9744, #9751, #9760, #9769, #9772, #9792, #9793, #9797, #9799, #9821, #9823, #9841, #9858, #9890, #9895, #9899, #9900, #9911 by thoughtpolice: milestone to 7.12.1 Comment: Moving to 7.12.1 milestone; if you feel this is an error and should be addressed sooner, please move it back to the 7.10.1 milestone. -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 23 13:36:20 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Dec 2014 13:36:20 -0000 Subject: [GHC] #9751: add runMeta Hook or TcM variant of hscCompileCoreExprHook In-Reply-To: <044.0e39eba5e5bc320ab7bb45f4a7f2c823@haskell.org> References: <044.0e39eba5e5bc320ab7bb45f4a7f2c823@haskell.org> Message-ID: <059.f58a2876e7b7ecf5af2b94ba9b18e75d@haskell.org> #9751: add runMeta Hook or TcM variant of hscCompileCoreExprHook -------------------------------------+------------------------------------- Reporter: luite | Owner: luite Type: task | Status: closed Priority: normal | Milestone: 7.12.1 Component: GHC API | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D501 | -------------------------------------+------------------------------------- Changes (by luite): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 23 13:36:55 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Dec 2014 13:36:55 -0000 Subject: [GHC] #9744: Make program name and project version configurable In-Reply-To: <044.83253224e4144ae46fadcfbf6a5cd378@haskell.org> References: <044.83253224e4144ae46fadcfbf6a5cd378@haskell.org> Message-ID: <059.8a05d888e1eca3e81df54e347655d1bb@haskell.org> #9744: Make program name and project version configurable -------------------------------------+------------------------------------- Reporter: luite | Owner: luite Type: feature | Status: closed request | Milestone: 7.12.1 Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D496 | -------------------------------------+------------------------------------- Changes (by luite): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 23 13:39:45 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Dec 2014 13:39:45 -0000 Subject: [GHC] #9900: Support pattern synonyms in GHCi In-Reply-To: <045.62d6509e4b0cfc58e8f6254c0f951369@haskell.org> References: <045.62d6509e4b0cfc58e8f6254c0f951369@haskell.org> Message-ID: <060.1f7654176d8f1d581923be3a4b35c03e@haskell.org> #9900: Support pattern synonyms in GHCi -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: GHCi | Version: 7.8.3 Resolution: | Keywords: PatternSynonyms Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: 9915 rejects valid program | Related Tickets: #8749, #7253 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by cactus): * status: new => patch * type: feature request => bug * milestone: 7.12.1 => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 23 13:55:38 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Dec 2014 13:55:38 -0000 Subject: [GHC] #9386: GHCi cannot load .so in ./ In-Reply-To: <047.6d829b9ae97b1073447115aeba1e6bb7@haskell.org> References: <047.6d829b9ae97b1073447115aeba1e6bb7@haskell.org> Message-ID: <062.09e6411b9d2260cb770ceb16a909685c@haskell.org> #9386: GHCi cannot load .so in ./ -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by crockeea): * component: GHCi => Compiler Comment: For the purposes of finding and fixing the bug, here are two more tidbits: 1. This bug also affects GHC with .so files 2. This bug does ''not'' affect .o files. In that case, I can just type a list of files '''a.o b.o ...''' and GHC searches the local directory. This seems to support your suggested solution to just prepend a ./ to paths. But why is the behavior different for .o and .so files? Perhaps it's a matter of hardcoded extensions? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 23 14:47:38 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Dec 2014 14:47:38 -0000 Subject: [GHC] #9879: Panic with partial type signatures In-Reply-To: <047.e5c88bd3f1ae8bc6f7d19321ba46479c@haskell.org> References: <047.e5c88bd3f1ae8bc6f7d19321ba46479c@haskell.org> Message-ID: <062.901943e22d9d5b9a3bca8a6e0210a2eb@haskell.org> #9879: Panic with partial type signatures -------------------------------------+------------------------------------- Reporter: monoidal | Owner: thomasw Type: bug | Status: patch Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.9 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHCi crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D572 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"6eb86a56135a9274d2c958a2ccf4df510c9dab86/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="6eb86a56135a9274d2c958a2ccf4df510c9dab86" Fix panic on :kind _ in GHCi (Trac #9879) Summary: Running `:kind _` in GHCi produced a panic, fix it by extracting the wildcards. Now, `:kind _` produces `_ :: k0`. Unfortunately, a `0` is added after the kind is tidied and I haven't found a way to get rid of it... This does not fix the other panic involving TemplateHaskell mentioned in #9879. Test Plan: new test GHCiWildcardKind should pass Reviewers: austin, simonpj Reviewed By: austin Subscribers: simonpj, carter, thomie, monoidal Differential Revision: https://phabricator.haskell.org/D572 GHC Trac Issues: #9879 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 23 14:48:31 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Dec 2014 14:48:31 -0000 Subject: [GHC] #9878: Static pointers in GHCi cause panic In-Reply-To: <047.a0b4c5e0dee3f65cf24b644a915474ce@haskell.org> References: <047.a0b4c5e0dee3f65cf24b644a915474ce@haskell.org> Message-ID: <062.0e2ac33a8d3a99cddcd1e12951215fb0@haskell.org> #9878: Static pointers in GHCi cause panic -------------------------------------+------------------------------------- Reporter: monoidal | Owner: facundo.dominguez Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHCi crash | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: D586 D587 | -------------------------------------+------------------------------------- Changes (by facundo.dominguez): * status: new => patch * differential: => D586 D587 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 23 14:57:27 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Dec 2014 14:57:27 -0000 Subject: [GHC] #9879: Panic with partial type signatures In-Reply-To: <047.e5c88bd3f1ae8bc6f7d19321ba46479c@haskell.org> References: <047.e5c88bd3f1ae8bc6f7d19321ba46479c@haskell.org> Message-ID: <062.816dc616c31a108e0aecb91df6ab828b@haskell.org> #9879: Panic with partial type signatures -------------------------------------+------------------------------------- Reporter: monoidal | Owner: thomasw Type: bug | Status: closed Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.9 (Type checker) | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHCi crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D572 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged in HEAD and 7.10.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 23 15:11:20 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Dec 2014 15:11:20 -0000 Subject: [GHC] #9631: Comment in GHC.Base about GHC.Prim does not appear to be correct In-Reply-To: <045.cbd722b3600402ea72fb22a56a8d8e08@haskell.org> References: <045.cbd722b3600402ea72fb22a56a8d8e08@haskell.org> Message-ID: <060.8df68c0d2cc1d9a55e153a03092c337c@haskell.org> #9631: Comment in GHC.Base about GHC.Prim does not appear to be correct -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.8.3 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: Documentation bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: core-libraries-committee@? (added) * milestone: => 7.10.1 Comment: It's not high priority, but it should be easy for someone who knows the real story. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 23 15:12:20 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Dec 2014 15:12:20 -0000 Subject: [GHC] #9852: Add missing export lists In-Reply-To: <045.0c137db4833268f838cfd23c79dcf251@haskell.org> References: <045.0c137db4833268f838cfd23c79dcf251@haskell.org> Message-ID: <060.8691b307e754157478fded9cbcb9af47@haskell.org> #9852: Add missing export lists -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: new Priority: low | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dfeuer): * milestone: => 7.10.1 Comment: This should be easier now that things are frozen. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 23 15:14:17 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Dec 2014 15:14:17 -0000 Subject: [GHC] #9876: mkdir errors when running `make sdist` In-Reply-To: <048.4e2ab1a0df62a578daea8b81b25fe988@haskell.org> References: <048.4e2ab1a0df62a578daea8b81b25fe988@haskell.org> Message-ID: <063.cb889972de0e0bafa5d7c5016e9422df@haskell.org> #9876: mkdir errors when running `make sdist` -------------------------------------+------------------------------------- Reporter: joehillen | Owner: joehillen Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: Phab:D566 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"9fc3aebd0920561d9d3c747e6b78591d332bed08/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="9fc3aebd0920561d9d3c747e6b78591d332bed08" always use 'mkdir -p' and fix missing dir (fixes #9876) Summary: Signed-off-by: Joe Hillenbrand Reviewers: thomie, austin Reviewed By: thomie, austin Subscribers: carter, thomie Differential Revision: https://phabricator.haskell.org/D566 GHC Trac Issues: #9876 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 23 15:15:02 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Dec 2014 15:15:02 -0000 Subject: [GHC] #9876: mkdir errors when running `make sdist` In-Reply-To: <048.4e2ab1a0df62a578daea8b81b25fe988@haskell.org> References: <048.4e2ab1a0df62a578daea8b81b25fe988@haskell.org> Message-ID: <063.9deec2b841b3ba8a83100b8da59bbc0d@haskell.org> #9876: mkdir errors when running `make sdist` -------------------------------------+------------------------------------- Reporter: joehillen | Owner: joehillen Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: Phab:D566 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed * milestone: => 7.10.1 Comment: Merged to 7.10, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 23 15:23:47 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Dec 2014 15:23:47 -0000 Subject: [GHC] #9674: Foldable doesn't have any laws In-Reply-To: <045.36aee1726cf0a1cc8513396efd92e6c8@haskell.org> References: <045.36aee1726cf0a1cc8513396efd92e6c8@haskell.org> Message-ID: <060.01d0f95b4516f744ee39e08fdf23ddaf@haskell.org> #9674: Foldable doesn't have any laws -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.8.3 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: Documentation bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dfeuer): * milestone: 7.12.1 => 7.10.1 Comment: This was mostly fixed by https://ghc.haskell.org/trac/ghc/browser/ghc/libraries/base/Data/Foldable.hs?rev=e5671302 but `foldr'`, `foldl'`, `foldl1`, and `foldr1`, at least, remain insufficiently documented. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 23 15:31:03 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Dec 2014 15:31:03 -0000 Subject: [GHC] #8723: sdist should not have to build everything In-Reply-To: <046.92216f47e2ba2986f6ec19c3e526b45f@haskell.org> References: <046.92216f47e2ba2986f6ec19c3e526b45f@haskell.org> Message-ID: <061.f1406a89bbad71d408f5e1a5ed9b98bd@haskell.org> #8723: sdist should not have to build everything -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: low | Milestone: Component: Build | Version: 7.6.3 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by hvr): * cc: hvr (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 23 15:38:21 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Dec 2014 15:38:21 -0000 Subject: [GHC] #9386: GHCi cannot load .so in ./ In-Reply-To: <047.6d829b9ae97b1073447115aeba1e6bb7@haskell.org> References: <047.6d829b9ae97b1073447115aeba1e6bb7@haskell.org> Message-ID: <062.f7ff2ad862173d6c414109285dc4bdd2@haskell.org> #9386: GHCi cannot load .so in ./ -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): Replying to [comment:5 rwbarton]: > presumably dlopen is finding the `libbsd.so` on your library path, not the one in `.`. Correct. When I remove `/usr/lib/x86_64-linux-gnu/libbsd.so`, the test from comment:3 also fails. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 23 16:03:06 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Dec 2014 16:03:06 -0000 Subject: [GHC] #2189: hSetBuffering stdin NoBuffering doesn't work on Windows In-Reply-To: <047.b31f95b84e60784da45a33105d44ed84@haskell.org> References: <047.b31f95b84e60784da45a33105d44ed84@haskell.org> Message-ID: <062.aa20b0694beabcf119925ead38c715b3@haskell.org> #2189: hSetBuffering stdin NoBuffering doesn't work on Windows -------------------------------------+------------------------------------- Reporter: FalconNL | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Core | Version: 6.8.2 Libraries | Keywords: hsetbuffering Resolution: | buffering buffer Operating System: Windows | Architecture: x86 Type of failure: | Difficulty: Unknown None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: ryan.gl.scott@?, core-libraries-committee@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 23 16:07:39 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Dec 2014 16:07:39 -0000 Subject: [GHC] #9878: Static pointers in GHCi cause panic In-Reply-To: <047.a0b4c5e0dee3f65cf24b644a915474ce@haskell.org> References: <047.a0b4c5e0dee3f65cf24b644a915474ce@haskell.org> Message-ID: <062.7b907524b2fbc373987e0a91bb194a9b@haskell.org> #9878: Static pointers in GHCi cause panic -------------------------------------+------------------------------------- Reporter: monoidal | Owner: facundo.dominguez Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHCi crash | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: Phab:D586 | Phab:D587 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * differential: D586 D587 => Phab:D586 Phab:D587 * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 23 16:09:06 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Dec 2014 16:09:06 -0000 Subject: [GHC] #8624: -ddump-splices-file In-Reply-To: <048.f5eead94409241401357105f8bb65a4f@haskell.org> References: <048.f5eead94409241401357105f8bb65a4f@haskell.org> Message-ID: <063.aa55b68ae289fc524286d3ef4f7db1e2@haskell.org> #8624: -ddump-splices-file -------------------------------------+------------------------------------- Reporter: GregWeber | Owner: Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.6.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D518 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * differential: https://phabricator.haskell.org/D518 => Phab:D518 * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 23 16:11:24 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Dec 2014 16:11:24 -0000 Subject: [GHC] #9213: Maybe important CPP warnings on ghcautoconf.h from cpphs In-Reply-To: <042.40c8fe49091f5227ff0b9eb0ac8fb5d0@haskell.org> References: <042.40c8fe49091f5227ff0b9eb0ac8fb5d0@haskell.org> Message-ID: <057.ece0a725c7b587e64102b6a22569793a@haskell.org> #9213: Maybe important CPP warnings on ghcautoconf.h from cpphs -------------------------------------+------------------------------------- Reporter: asr | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by asr): * version: 7.8.4-rc1 => 7.8.4 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 23 16:29:26 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Dec 2014 16:29:26 -0000 Subject: [GHC] #3064: Very long compile times with type functions In-Reply-To: <046.2a7b2611764311f7357001c522d303b9@haskell.org> References: <046.2a7b2611764311f7357001c522d303b9@haskell.org> Message-ID: <061.fb3b03ed1930b15c68a7a40bcf4b1788@haskell.org> #3064: Very long compile times with type functions -------------------------------------------------+------------------------- Reporter: simonpj | Owner: Type: bug | Status: Priority: low | closed Component: Compiler (Type checker) | Milestone: 7.6.1 Resolution: fixed | Version: Operating System: Unknown/Multiple | 6.10.1 Type of failure: Compile-time performance bug | Keywords: Test Case: perf/compiler/T3064 | Architecture: Blocking: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by Simon Peyton Jones ): In [changeset:"a6f0f5ab45b2643b561e0a0a54a4f14745ab2152/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a6f0f5ab45b2643b561e0a0a54a4f14745ab2152" Eliminate so-called "silent superclass parameters" The purpose of silent superclass parameters was to solve the awkward problem of superclass dictinaries being bound to bottom. See THE PROBLEM in Note [Recursive superclasses] in TcInstDcls Although the silent-superclass idea worked, * It had non-local consequences, and had effects even in Haddock, where we had to discard silent parameters before displaying instance declarations * It had unexpected peformance costs, shown up by Trac #3064 and its test case. In monad-transformer code, when constructing a Monad dictionary you had to pass an Applicative dictionary; and to construct that you neede a Functor dictionary. Yet these extra dictionaries were often never used. (All this got much worse when we added Applicative as a superclass of Monad.) Test T3064 compiled *far* faster after silent superclasses were eliminated. * It introduced new bugs. For example SilentParametersOverlapping, T5051, and T7862, all failed to compile because of instance overlap directly because of the silent-superclass trick. So this patch takes a new approach, which I worked out with Dimitrios in the closing hours before Christmas. It is described in detail in THE PROBLEM in Note [Recursive superclasses] in TcInstDcls. Seems to work great! Quite a bit of knock-on effect * The main implementation work is in tcSuperClasses in TcInstDcls Everything else is fall-out * IdInfo.DFunId no longer needs its n-silent argument * Ditto IDFunId in IfaceSyn * Hence interface file format changes * Now that DFunIds do not have silent superclass parameters, printing out instance declarations is simpler. There is tiny knock-on effect in Haddock, so that submodule is updated * I realised that when computing the "size of a dictionary type" in TcValidity.sizePred, we should be rather conservative about type functions, which can arbitrarily increase the size of a type. Hence the new datatype TypeSize, which has a TSBig constructor for "arbitrarily big". * instDFunType moves from TcSMonad to Inst * Interestingly, CmmNode and CmmExpr both now need a non-silent (Ord r) in a couple of instance declarations. These were previously silent but must now be explicit. * Quite a bit of wibbling in error messages }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 23 16:29:26 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Dec 2014 16:29:26 -0000 Subject: [GHC] #9032: Panic with self-import In-Reply-To: <048.b2b35b617fab282b73adc84f1bdd96f5@haskell.org> References: <048.b2b35b617fab282b73adc84f1bdd96f5@haskell.org> Message-ID: <063.be123665d7296cff1bcd5a34360efb43@haskell.org> #9032: Panic with self-import -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Template | Version: 7.8.2 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Compile- | Related Tickets: #1012 time crash | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"edd233acc19d269385c1a870829e0916a3df8e88/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="edd233acc19d269385c1a870829e0916a3df8e88" Test earlier for self-import (Trac #9032) This patch makes the renamer check for self-import, especially when dependencies change, because the typechecker can fall over if that happens. I'm still uneasy about *indirect* self-import, but I'll leave that for another day }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 23 16:30:30 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Dec 2014 16:30:30 -0000 Subject: [GHC] #9032: Panic with self-import In-Reply-To: <048.b2b35b617fab282b73adc84f1bdd96f5@haskell.org> References: <048.b2b35b617fab282b73adc84f1bdd96f5@haskell.org> Message-ID: <063.5afe9bbb624c84eb0074a61f80345c46@haskell.org> #9032: Panic with self-import -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.10.1 Component: Template | Version: 7.8.2 Haskell | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Compile- | Related Tickets: #1012 time crash | Test Case: | rename/should_fail/T9032 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => rename/should_fail/T9032 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 23 18:00:46 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Dec 2014 18:00:46 -0000 Subject: [GHC] #3064: Very long compile times with type functions In-Reply-To: <046.2a7b2611764311f7357001c522d303b9@haskell.org> References: <046.2a7b2611764311f7357001c522d303b9@haskell.org> Message-ID: <061.0ea971e1b751091fbb5348e3d28c4595@haskell.org> #3064: Very long compile times with type functions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: low | Milestone: 7.6.1 Component: Compiler | Version: 6.10.1 (Type checker) | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Compile- | Related Tickets: time performance bug | Test Case: | perf/compiler/T3064 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): should this be merged into the 7.10 branch or remilestoned for 7.12 only? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 23 18:09:37 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Dec 2014 18:09:37 -0000 Subject: [GHC] #9852: Add missing export lists In-Reply-To: <045.0c137db4833268f838cfd23c79dcf251@haskell.org> References: <045.0c137db4833268f838cfd23c79dcf251@haskell.org> Message-ID: <060.694724e57a08375654d9d7b3f59f7477@haskell.org> #9852: Add missing export lists -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: patch Priority: low | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D551 | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch * differential: => Phab:D551 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 23 18:59:16 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Dec 2014 18:59:16 -0000 Subject: [GHC] #3064: Very long compile times with type functions In-Reply-To: <046.2a7b2611764311f7357001c522d303b9@haskell.org> References: <046.2a7b2611764311f7357001c522d303b9@haskell.org> Message-ID: <061.a134bfb1f4724b79304a26a0d2d358df@haskell.org> #3064: Very long compile times with type functions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: low | Milestone: 7.12.1 Component: Compiler | Version: 6.10.1 (Type checker) | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Compile- | Related Tickets: time performance bug | Test Case: | perf/compiler/T3064 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by goldfire): * milestone: 7.6.1 => 7.12.1 Comment: From the second-to-last bullet point in Simon's commit message, it looks like this is a breaking change and should not be merged into 7.10 since RC1 is already out. I have to say the breakage is a little disappointing here. Here is the real-life example from the Note: {{{ class Ord r => UserOfRegs r a where ... (i1) instance UserOfRegs r a => UserOfRegs r (Maybe a) where ... (i2) instance (Ord r, UserOfRegs r CmmReg) => UserOfRegs r CmmExpr where ... }}} Note the `Ord r` constraint in `(i2)`, which is newly-required by this change. What's disappointing here is that `Ord r` is "obviously" derivable from `UserOfRegs r CmmReg`! While I understand the reasoning in the Note (that `UserOfRegs r CmmReg` is not strictly smaller than the instance head, and therefore looking in its superclasses might, in perverse but realistic scenarios, might cause the superclass dictionary to loop), it's far from obvious from a user standpoint. Is it possible to alert the user to this problem in an error message? It seems, from the diff, that this is not yet done. And, should this perhaps be the first 7.12 release note? As it's a breaking change, I do think it should be called out in the user manual. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 23 21:11:23 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Dec 2014 21:11:23 -0000 Subject: [GHC] #9905: ghc-7.8.x command line error In-Reply-To: <049.b40fd88ea54ea4f681922f4cf3395d55@haskell.org> References: <049.b40fd88ea54ea4f681922f4cf3395d55@haskell.org> Message-ID: <064.8d7201359f1a12784d1c0c906e6446a6@haskell.org> #9905: ghc-7.8.x command line error -------------------------------------+------------------------------------- Reporter: zRecursive | Owner: rwbarton Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D581 | -------------------------------------+------------------------------------- Comment (by Reid Barton ): In [changeset:"878910e1c4520732ab9d8372c1c81f00d484e48f/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="878910e1c4520732ab9d8372c1c81f00d484e48f" Make ghc -e not exit on valid import commands (#9905) Summary: Some Trues and Falses were mixed up due to Bool being used in different senses in different parts of GHCi. Test Plan: harbormaster; validate Reviewers: austin Reviewed By: austin Subscribers: carter, thomie Differential Revision: https://phabricator.haskell.org/D581 GHC Trac Issues: #9905 Conflicts: ghc/InteractiveUI.hs }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 23 21:48:13 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Dec 2014 21:48:13 -0000 Subject: [GHC] #9905: ghc-7.8.x command line error In-Reply-To: <049.b40fd88ea54ea4f681922f4cf3395d55@haskell.org> References: <049.b40fd88ea54ea4f681922f4cf3395d55@haskell.org> Message-ID: <064.7cf6f159e07093c555eaa245fa0703dd@haskell.org> #9905: ghc-7.8.x command line error -------------------------------------+------------------------------------- Reporter: zRecursive | Owner: rwbarton Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D581 | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => merge Comment: Austin: please merge [changeset:"cc510b46b4f6046115cd74acc2c8726c91823bcf/ghc"] also, thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 23 22:18:27 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Dec 2014 22:18:27 -0000 Subject: [GHC] #9920: Segfault in arm binary In-Reply-To: <044.555edb7e560a8d41cf35aba7c1c44446@haskell.org> References: <044.555edb7e560a8d41cf35aba7c1c44446@haskell.org> Message-ID: <059.14b1e756b5881dffbbf2b77b10f2c657@haskell.org> #9920: Segfault in arm binary -------------------------------------------+--------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------------+--------------------------- Comment (by erikd): Same problem with `llc` from llvm version 3.6. Managed to reduce the input `.ll` file to about 30 lines of code containing just the functions `stg_init_finish$def` and `stg_init$def`. If I remove the `cc10` calling convention (which is as I understand it, only used by GHC) from the LLVM IR code then the `stg_init_finish$def` function no longer has zero instructions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 23 23:02:57 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Dec 2014 23:02:57 -0000 Subject: [GHC] #9918: GHC chooses an instance between two overlapping, but cannot resolve a clause within the similar closed type family In-Reply-To: <045.8b42c360bfa608017b9b2986029ca51e@haskell.org> References: <045.8b42c360bfa608017b9b2986029ca51e@haskell.org> Message-ID: <060.7b0cc7800ce9ea26cba59423c28aaea4@haskell.org> #9918: GHC chooses an instance between two overlapping, but cannot resolve a clause within the similar closed type family -------------------------------------+------------------------------------- Reporter: qnikst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by qnikst): I read the article and see a reasoning behind this solution, also I don't have an ideas or wishes about what solution will be right one. > Your program depends in a very delicate way on the treatment of infinite types. I wonder if it needs to? I was a region code by Kiselev et al. And me and Oleg decided to give closed type families try to remove overloaded instances in the code. There are few other approaches that I have found like expressing type of the monadic stack as a typelevel list of monadic stacks then then check only relevant parts of that list, or calculate list length. {{{ type family Listify (a :: * -> *) :: [* -> *] where Listify (IORT s m) = IORT s m ': Listify m Listify m = '[m] }}} Either of this approaches partially fix the issue, i.e. the code will work for statically known stack, for example: {{{ test_copy = runSIO $ do hout <- newSHandle newRgn $ shPutStrLn hout runSIO :: (forall s. IORT s IO v) -> IO v runSIO = newRgn }}} But this approach do not allow to write region polymorphic code, as in all the cases I'm facing a case there type family can no longer be reduced as in all cases I'm finishing with something like: `MyTypeFamily (Listify m) (IORT s m, Listify m)` and at this point it's not possible to make a right choice. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 24 00:41:08 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Dec 2014 00:41:08 -0000 Subject: [GHC] #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' In-Reply-To: <043.cbe6919f438ad52f7a7c1b87d59cd82e@haskell.org> References: <043.cbe6919f438ad52f7a7c1b87d59cd82e@haskell.org> Message-ID: <058.a02edc85cd0e02a4aef6ea2fbe2c0de3@haskell.org> #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' -----------------------------+---------------------------------- Reporter: Kata | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+---------------------------------- Comment (by Reid Barton ): In [changeset:"3e3aa9258b521d362d3a51cb48969df3eeab4981/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="3e3aa9258b521d362d3a51cb48969df3eeab4981" Fix linker interaction between Template Haskell and HPC (#9762) Summary: I'm not really happy about perpetuating the hackish fix for #8696, but at least in the context of building with -fhpc, the performance cost should be negligible. I'm suspicious about PlainModuleInitLabel and the Windows stuff too, but I don't know what it does / can't test it (respectively) so I'll leave those alone for now. Hopefully out-of-process TH will save us from these hacks some day. The test is an adaptation of T8696. It's a bit more awkward since I couldn't think of a way to get cross-module tickbox references without optimizations (inlining), but ghci doesn't permit -O for some reason. Test Plan: harbormaster; validate Reviewers: austin Reviewed By: austin Subscribers: carter, thomie Differential Revision: https://phabricator.haskell.org/D583 GHC Trac Issues: #9762 Conflicts: testsuite/tests/ghci/scripts/all.T }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 24 00:41:08 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Dec 2014 00:41:08 -0000 Subject: [GHC] #9762: #8696 + #9012 In-Reply-To: <047.1416552af7b7cba6e17e930c77b546df@haskell.org> References: <047.1416552af7b7cba6e17e930c77b546df@haskell.org> Message-ID: <062.705643c2f1fcb611a880353a0b693481@haskell.org> #9762: #8696 + #9012 -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8696, #9012, Test Case: | #9909 Blocking: | Differential Revisions: Phab:D583 | -------------------------------------+------------------------------------- Comment (by Reid Barton ): In [changeset:"3e3aa9258b521d362d3a51cb48969df3eeab4981/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="3e3aa9258b521d362d3a51cb48969df3eeab4981" Fix linker interaction between Template Haskell and HPC (#9762) Summary: I'm not really happy about perpetuating the hackish fix for #8696, but at least in the context of building with -fhpc, the performance cost should be negligible. I'm suspicious about PlainModuleInitLabel and the Windows stuff too, but I don't know what it does / can't test it (respectively) so I'll leave those alone for now. Hopefully out-of-process TH will save us from these hacks some day. The test is an adaptation of T8696. It's a bit more awkward since I couldn't think of a way to get cross-module tickbox references without optimizations (inlining), but ghci doesn't permit -O for some reason. Test Plan: harbormaster; validate Reviewers: austin Reviewed By: austin Subscribers: carter, thomie Differential Revision: https://phabricator.haskell.org/D583 GHC Trac Issues: #9762 Conflicts: testsuite/tests/ghci/scripts/all.T }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 24 00:42:32 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Dec 2014 00:42:32 -0000 Subject: [GHC] #9762: #8696 + #9012 In-Reply-To: <047.1416552af7b7cba6e17e930c77b546df@haskell.org> References: <047.1416552af7b7cba6e17e930c77b546df@haskell.org> Message-ID: <062.b42b0844529337cd89901ce57bdb70ac@haskell.org> #9762: #8696 + #9012 -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton Type: bug | Status: merge Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8696, #9012, Test Case: | #9909 Blocking: | Differential Revisions: Phab:D583 | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => merge * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 24 00:43:32 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Dec 2014 00:43:32 -0000 Subject: [GHC] #9905: ghc-7.8.x command line error In-Reply-To: <049.b40fd88ea54ea4f681922f4cf3395d55@haskell.org> References: <049.b40fd88ea54ea4f681922f4cf3395d55@haskell.org> Message-ID: <064.89448192305c5cda658640aa851b198b@haskell.org> #9905: ghc-7.8.x command line error -------------------------------------+------------------------------------- Reporter: zRecursive | Owner: rwbarton Type: bug | Status: merge Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D581 | -------------------------------------+------------------------------------- Changes (by rwbarton): * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 24 00:53:48 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Dec 2014 00:53:48 -0000 Subject: [GHC] #9875: ld -l:filename.dylib does not appear to be portable In-Reply-To: <045.5761a7e104bd5de24e048bce5dd70a34@haskell.org> References: <045.5761a7e104bd5de24e048bce5dd70a34@haskell.org> Message-ID: <060.2eb2829f397480d7463ac01ee246b001@haskell.org> #9875: ld -l:filename.dylib does not appear to be portable -------------------------------------+------------------------------------ Reporter: ezyang | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.10.1 Component: GHCi | Version: 7.9 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Unknown Test Case: T2276_ghci | Blocked By: Blocking: 9845 | Related Tickets: Differential Revisions: Phab:D579 | -------------------------------------+------------------------------------ Comment (by ezyang): OK, I validated on OS X. We just need to address the CR comments. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 24 01:44:37 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Dec 2014 01:44:37 -0000 Subject: [GHC] #9652: Bootstrapping GHC HEAD against itself doesn't work In-Reply-To: <045.174cce8060d844f9c120636e662de792@haskell.org> References: <045.174cce8060d844f9c120636e662de792@haskell.org> Message-ID: <060.618c5b6d879629b9f94784b82990ff90@haskell.org> #9652: Bootstrapping GHC HEAD against itself doesn't work -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: D589 | -------------------------------------+------------------------------------- Changes (by ezyang): * differential: => D589 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 24 06:43:29 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Dec 2014 06:43:29 -0000 Subject: [GHC] #9875: ld -l:filename.dylib does not appear to be portable In-Reply-To: <045.5761a7e104bd5de24e048bce5dd70a34@haskell.org> References: <045.5761a7e104bd5de24e048bce5dd70a34@haskell.org> Message-ID: <060.a9080cfb664edbe29a5cd156ad20e2ae@haskell.org> #9875: ld -l:filename.dylib does not appear to be portable -------------------------------------+------------------------------------ Reporter: ezyang | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.10.1 Component: GHCi | Version: 7.9 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Unknown Test Case: T2276_ghci | Blocked By: Blocking: 9845 | Related Tickets: Differential Revisions: Phab:D579 | -------------------------------------+------------------------------------ Comment (by trommler): Replying to [comment:8 ezyang]: > OK, I validated on OS X. Thanks a lot! > We just need to address the CR comments. Done. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 24 10:17:45 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Dec 2014 10:17:45 -0000 Subject: [GHC] #9921: Building Haddocks with Hoogle output results in an error Message-ID: <047.5612adaf4961bd48041d34575c43a0f4@haskell.org> #9921: Building Haddocks with Hoogle output results in an error -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: x86_64 (amd64) | Unknown/Multiple Difficulty: Unknown | Type of failure: Runtime Blocked By: | crash Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- With the GHC 7.10 release candidate 1 and cabal-install 1.22 (via Herbert's PPA), I unpacked BoundedChan, configured, and then ran the following, with the given output: {{{ $ cabal haddock --hoogle Running Haddock for BoundedChan-1.0.3.0... Preprocessing library BoundedChan-1.0.3.0... Haddock coverage: 100% ( 10 / 10) in 'Control.Concurrent.BoundedChan' haddock: internal error: expectJust getPackageDetails }}} I can reopen against the Haddock repo instead, but I thought this should be on the 7.10 milestone. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 24 10:30:22 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Dec 2014 10:30:22 -0000 Subject: [GHC] #9920: Segfault in arm binary In-Reply-To: <044.555edb7e560a8d41cf35aba7c1c44446@haskell.org> References: <044.555edb7e560a8d41cf35aba7c1c44446@haskell.org> Message-ID: <059.54940d0f6f4ac4b08e9b8ffe64652a81@haskell.org> #9920: Segfault in arm binary -------------------------------------------+--------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------------+--------------------------- Comment (by erikd): `llc` from llvm git HEAD (3681929e116d9b 2014/12/24) seems to work and produces the following assembly language: {{{ stg_init_finish$def: @ @"stg_init_finish$def" .fnstart .Leh_func_begin0: @ BB#0: @ %cF b StgReturn .Ltmp0: .size stg_init_finish$def, .Ltmp0-stg_init_finish$def }}} which seems correct. However, using llvm from git HEAD requires changes to the metdata definitons from this: {{{ !0 = metadata !{metadata !1, metadata !1, i64 0} }}} to this: {{{ !0 = !{!1, !1, i64 0} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 24 11:45:29 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Dec 2014 11:45:29 -0000 Subject: [GHC] #9922: Partial type signatures + extensions panic Message-ID: <047.bcb93dee275eec47e30ed9673a9b0d12@haskell.org> #9922: Partial type signatures + extensions panic -------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.9 checker) | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Compile- Difficulty: Unknown | time crash Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Partial type signatures combined with the following GHC extensions cause a panic: {{{#!hs class C a where default f :: _ -- DefaultSignatures instance Num Bool where negate :: _ -- InstanceSigs deriving instance _ -- StandaloneDeriving }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 24 12:11:40 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Dec 2014 12:11:40 -0000 Subject: [GHC] #9921: Building Haddocks with Hoogle output results in an error In-Reply-To: <047.5612adaf4961bd48041d34575c43a0f4@haskell.org> References: <047.5612adaf4961bd48041d34575c43a0f4@haskell.org> Message-ID: <062.f2bc5534a8d43063490881cbcce48fc1@haskell.org> #9921: Building Haddocks with Hoogle output results in an error -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: x86_64 (amd64) Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by NeilMitchell): * cc: ndmitchell@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 24 12:40:42 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Dec 2014 12:40:42 -0000 Subject: [GHC] #9920: Segfault in arm binary In-Reply-To: <044.555edb7e560a8d41cf35aba7c1c44446@haskell.org> References: <044.555edb7e560a8d41cf35aba7c1c44446@haskell.org> Message-ID: <059.341953200ae249dbb467c0e12ac5c3dd@haskell.org> #9920: Segfault in arm binary -------------------------------------------+--------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------------+--------------------------- Comment (by erikd): Seems to have been fixed (in LLVM) by: {{{ commit f7f88095a32d1ac5bc7778204fd9a37a9fb8082c Author: Tim Northover Date: Mon Dec 1 17:46:39 2014 +0000 ARM: lower tail calls correctly when using GHC calling convention. Patch by Ben Gamari. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 24 18:09:01 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Dec 2014 18:09:01 -0000 Subject: [GHC] #17: Separate warnings for unused local and top-level bindings In-Reply-To: <047.fe4cdb312b5d86f34d27df1115f2c91a@haskell.org> References: <047.fe4cdb312b5d86f34d27df1115f2c91a@haskell.org> Message-ID: <062.87fda1de40ef4e51cf691fb2d964bf05@haskell.org> #17: Separate warnings for unused local and top-level bindings -------------------------------------+------------------------------------- Reporter: magunter | Owner: Type: feature | Status: new request | Milestone: 7.12.1 Priority: lowest | Version: None Component: Compiler | Keywords: -fwarn-unused- Resolution: None | binds newcomer Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #3283 Test Case: | Blocking: | Differential Revisions: Phab:D591 | -------------------------------------+------------------------------------- Changes (by thomie): * differential: => Phab:D591 * milestone: ? => 7.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 24 20:24:09 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Dec 2014 20:24:09 -0000 Subject: [GHC] #9923: Offer copy-on-GC sliced arrays Message-ID: <045.bfe02837f0b70bc36ccad815cc301a05@haskell.org> #9923: Offer copy-on-GC sliced arrays -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.11 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- It's sometimes useful to split an array and send each part on to a different computation. Slicing works very well for this sort of thing, as long as both computations run to completion or become garbage at about the same time. It can work badly, however, if one computation is completed or abandoned and the other is retained?it may only hold a tiny slice, but that's enough to keep the entire array alive. The alternative, currently, is to copy the array to form two new arrays. This gets rid of the retention problem, but introduces a performance problem. One way to solve these problems might be to offer sliced arrays supported by the RTS. On collection, the garbage collector would copy each slice separately, turning it into an independent (and independently collectible) array. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 24 20:32:30 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Dec 2014 20:32:30 -0000 Subject: [GHC] #9921: Building Haddocks with Hoogle output results in an error In-Reply-To: <047.5612adaf4961bd48041d34575c43a0f4@haskell.org> References: <047.5612adaf4961bd48041d34575c43a0f4@haskell.org> Message-ID: <062.560382d44cdd5d2acf4362ccdb1bb87b@haskell.org> #9921: Building Haddocks with Hoogle output results in an error -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: x86_64 (amd64) Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by luite): Yep this had me scratching my head for a few days. It's a known problem in Haddock and will probably need some changes in both Haddock and Cabal to fix, see https://github.com/haskell/haddock/issues/353 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 24 22:54:58 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Dec 2014 22:54:58 -0000 Subject: [GHC] #9924: libffi configure script does not detect MSYS2 Windows 10 x86_64 Message-ID: <044.eb148a97098db208d1e56e2d87b80e8c@haskell.org> #9924: libffi configure script does not detect MSYS2 Windows 10 x86_64 -------------------------------------+------------------------------------- Reporter: luite | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc1 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- When building GHC 7.10 RC 1 on Windows 10 Technical Preview, 64 bit, in MSYS2, libffi fails with the message that it cannot determine the build system, and that `config.guess` and `config.sub` may need to be updated. The latest versions do indeed work. Unfortunately the scripts are stored in the `libffi.tar` file, if we don't want to change the file we'll need some way to get the correct versions in place. I have a very hacky workaround that downloads the latest versions after unpacking the tar, which is obviously not how it should be solved, but might help some people get their RC1 to build before we have a proper fix: {{{ diff --git a/libffi/ghc.mk b/libffi/ghc.mk index ec37f0c..fbd2e5e 100644 --- a/libffi/ghc.mk +++ b/libffi/ghc.mk @@ -89,6 +89,9 @@ $(libffi_STAMP_CONFIGURE): $(TOUCH_DEP) cd libffi && \ $(LIBFFI_PATH_MANGLE) \ cd build && \ + autoreconf -f && \ + wget -O config.guess "http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD" && \ + wget -O config.sub "http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD" && \ CC=$(CC_STAGE1) \ CXX=$(CC_STAGE1) \ LD=$(LD) \ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 24 22:56:04 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Dec 2014 22:56:04 -0000 Subject: [GHC] #9924: libffi configure script does not detect MSYS2 Windows 10 x86_64 In-Reply-To: <044.eb148a97098db208d1e56e2d87b80e8c@haskell.org> References: <044.eb148a97098db208d1e56e2d87b80e8c@haskell.org> Message-ID: <059.0d126fe3144dc4b1438ed1233704cac4@haskell.org> #9924: libffi configure script does not detect MSYS2 Windows 10 x86_64 -------------------------------------+------------------------------------- Reporter: luite | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: | Difficulty: Unknown None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by luite): More versions might be affected, but my other test system with Windows 8.1 32 bit, with MSYS2 msys32 is detected correctly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 24 23:16:03 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Dec 2014 23:16:03 -0000 Subject: [GHC] #9920: Segfault in arm binary In-Reply-To: <044.555edb7e560a8d41cf35aba7c1c44446@haskell.org> References: <044.555edb7e560a8d41cf35aba7c1c44446@haskell.org> Message-ID: <059.67f39b7d1ece0b06650b9682215f66f6@haskell.org> #9920: Segfault in arm binary -------------------------------------------+--------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------------+--------------------------- Comment (by erikd): If I compile my test file `test.ll` with llvm-3.5 compiled from source I get: {{{ llc: /home/erikd/LLVM/llvm-3.5.0.src/lib/Target/ARM/InstPrinter/../ARMGenAsmWriter.inc:6048: void llvm::ARMInstPrinter::printInstruction(const llvm::MCInst *, llvm::raw_ostream &): Assertion `Bits != 0 && "Cannot print this instruction."' failed. 0 llc 0x0000000001391255 llvm::sys::PrintStackTrace(_IO_FILE*) + 37 1 llc 0x0000000001391a43 2 libpthread.so.0 0x00007ffa635718d0 3 libc.so.6 0x00007ffa6259e107 gsignal + 55 4 libc.so.6 0x00007ffa6259f4e8 abort + 328 5 libc.so.6 0x00007ffa62597226 6 libc.so.6 0x00007ffa625972d2 7 llc 0x0000000000a3df99 llvm::ARMInstPrinter::printInstruction(llvm::MCInst const*, llvm::raw_ostream&) + 17673 8 llc 0x0000000000a49052 llvm::ARMInstPrinter::printInst(llvm::MCInst const*, llvm::raw_ostream&, llvm::StringRef) + 4322 9 llc 0x00000000013171f5 10 llc 0x00000000008fa01c 11 llc 0x0000000000dbbba0 llvm::AsmPrinter::EmitFunctionBody() + 3840 12 llc 0x00000000008ebad6 13 llc 0x0000000000ea44fc llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 124 14 llc 0x00000000012c8cbb llvm::FPPassManager::runOnFunction(llvm::Function&) + 539 15 llc 0x00000000012c8f2b llvm::FPPassManager::runOnModule(llvm::Module&) + 43 16 llc 0x00000000012c94a7 llvm::legacy::PassManagerImpl::run(llvm::Module&) + 967 17 llc 0x00000000005926ea main + 6682 18 libc.so.6 0x00007ffa6258ab45 __libc_start_main + 245 19 llc 0x000000000058f62d Stack dump: 0. Program arguments: /home/erikd/LLVM/3.5/bin/llc -O3 -relocation- model=static --enable-tbaa=true -mattr=+v7,+vfp3 -float-abi=hard test.ll -o test.s 1. Running pass 'Function Pass Manager' on module 'test.ll'. 2. Running pass 'ARM Assembly / Object Emitter' on function '@"stg_init_finish$def"' }}} This does not happen with llvm-3.5 installed from Debian. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 25 01:30:03 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Dec 2014 01:30:03 -0000 Subject: [GHC] #9479: Report required constraints when reporting the type of a hole In-Reply-To: <056.d301c5f3e1df29c162c4f7ce444029a2@haskell.org> References: <056.d301c5f3e1df29c162c4f7ce444029a2@haskell.org> Message-ID: <071.0adaa7f19a2365526c1dfc8ac491e3d4@haskell.org> #9479: Report required constraints when reporting the type of a hole -------------------------------------+------------------------------------- Reporter: | Owner: dominiquedevriese | Status: new Type: feature | Milestone: request | Version: 7.8.3 Priority: low | Keywords: holes Component: Compiler | Architecture: Unknown/Multiple (Type checker) | Difficulty: Unknown Resolution: | Blocked By: Operating System: | Related Tickets: Unknown/Multiple | Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by phadej): With `-fdefer-type-errors` GHC (both 7.8 and 7.10) tries a bit longer and finds the missing instance: {{{ [1 of 1] Compiling Test ( /Users/ogre/show.hs, /Users/ogre/show.o ) /Users/ogre/show.hs:4:8: Warning: No instance for (Show a0) arising from a use of ?show? The type variable ?a0? is ambiguous Note: there are several potential instances: instance Show a => Show (Maybe a) -- Defined in ?GHC.Show? instance Show Ordering -- Defined in ?GHC.Show? instance Show Integer -- Defined in ?GHC.Show? ...plus 22 others In the expression: show _h In an equation for ?test?: test = show _h /Users/ogre/show.hs:4:13: Warning: Found hole ?_h? with type: a0 Where: ?a0? is an ambiguous type variable Relevant bindings include test :: String (bound at /Users/ogre/show.hs:4:1) In the first argument of ?show?, namely ?_h? In the expression: show _h In an equation for ?test?: test = show _h }}} So should we make holeReporter to try to find //Dicts// errors too, if `-fdefer-type-errors` is not set? IMHO the //No instance// error is what we need here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 25 20:16:40 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Dec 2014 20:16:40 -0000 Subject: [GHC] #9925: ghc internal error while installing hakyll Message-ID: <048.d8a23dd08c68f1e4fb161babc09db093@haskell.org> #9925: ghc internal error while installing hakyll ----------------------------------+---------------------------------------- Reporter: fvictorio | 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: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------+---------------------------------------- Tried to install hakyll on Ubuntu 14.04 {{{ cabal update cabal install hakyll }}} Error during installation: {{{ [55 of 69] Compiling Text.Pandoc.Writers.OpenDocument ( src/Text/Pandoc/Writers/OpenDocument.hs, dist/build/Text/Pandoc/Writers/OpenDocument.o ) ghc: internal error: evacuate: strange closure type 15574408 (GHC version 7.6.3 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 25 20:17:27 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Dec 2014 20:17:27 -0000 Subject: [GHC] #9925: ghc internal error while installing hakyll In-Reply-To: <048.d8a23dd08c68f1e4fb161babc09db093@haskell.org> References: <048.d8a23dd08c68f1e4fb161babc09db093@haskell.org> Message-ID: <063.155457f575fe97b3a2f711e111532be0@haskell.org> #9925: ghc internal error while installing hakyll ----------------------------------------+---------------------------------- Reporter: fvictorio | 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: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------+---------------------------------- Comment (by fvictorio): Doing {{{ cabal install hakyll }}} again finished the installation without further problems. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 25 23:33:21 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Dec 2014 23:33:21 -0000 Subject: [GHC] #9384: setNumCapabilities call breaks eventlog events In-Reply-To: <045.20a8519e305e1ec14c5a72f8498ddcb2@haskell.org> References: <045.20a8519e305e1ec14c5a72f8498ddcb2@haskell.org> Message-ID: <060.7bf30e0e2697901ae2229c7208686706@haskell.org> #9384: setNumCapabilities call breaks eventlog events -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Profiling | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Incorrect | Difficulty: Unknown result at runtime | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: D592 | -------------------------------------+------------------------------------- Changes (by qnikst): * cc: qnikst (added) * differential: => D592 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 25 23:36:39 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Dec 2014 23:36:39 -0000 Subject: [GHC] #9384: setNumCapabilities call breaks eventlog events In-Reply-To: <045.20a8519e305e1ec14c5a72f8498ddcb2@haskell.org> References: <045.20a8519e305e1ec14c5a72f8498ddcb2@haskell.org> Message-ID: <060.fd653fe916b45322c47d9673e060119f@haskell.org> #9384: setNumCapabilities call breaks eventlog events -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.10.1 Component: Profiling | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Incorrect | Difficulty: Unknown result at runtime | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: D592 | -------------------------------------+------------------------------------- Changes (by slyfox): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 25 23:48:11 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Dec 2014 23:48:11 -0000 Subject: [GHC] #9384: setNumCapabilities call breaks eventlog events In-Reply-To: <045.20a8519e305e1ec14c5a72f8498ddcb2@haskell.org> References: <045.20a8519e305e1ec14c5a72f8498ddcb2@haskell.org> Message-ID: <060.57bac3e87bdcbfdd220866870de060a5@haskell.org> #9384: setNumCapabilities call breaks eventlog events -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.10.1 Component: Profiling | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Incorrect | Difficulty: Unknown result at runtime | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: Phab:D592 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * differential: D592 => Phab:D592 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 26 01:07:18 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Dec 2014 01:07:18 -0000 Subject: [GHC] #9524: GHC uses wrong linker when cross compiling In-Reply-To: <049.96f062346f8aab14c3c1ff251a788093@haskell.org> References: <049.96f062346f8aab14c3c1ff251a788093@haskell.org> Message-ID: <064.ab695016c0c62ea8166ef5c3f8ada187@haskell.org> #9524: GHC uses wrong linker when cross compiling -------------------------------------+------------------------------------- Reporter: Kritzefitz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.8.3 System | Keywords: Cross compiling Resolution: | Architecture: x86 Operating System: Linux | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by Kritzefitz): * keywords: => Cross compiling * os: Unknown/Multiple => Linux * component: Compiler (FFI) => Build System * architecture: Unknown/Multiple => x86 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 26 06:52:37 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Dec 2014 06:52:37 -0000 Subject: [GHC] #9920: Segfault in arm binary In-Reply-To: <044.555edb7e560a8d41cf35aba7c1c44446@haskell.org> References: <044.555edb7e560a8d41cf35aba7c1c44446@haskell.org> Message-ID: <059.147190d435b5f0288cbeef228860f7e1@haskell.org> #9920: Segfault in arm binary -------------------------------------------+--------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------------+--------------------------- Comment (by erikd): If I grab the llvm 3.5 release source tarball, apply the attached patch named `arm-lower-tail-calls.patch?` to the llvm sources, build them and the copy the new `llc` binary to `/usr/bin/llc-3.5` on my Debian system, I then get myself a working amd64-linux to armhf-linux cross compiler. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 26 07:42:44 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Dec 2014 07:42:44 -0000 Subject: [GHC] #7593: Unable to print exceptions of unicode identifiers In-Reply-To: <044.180348374c60284a01c4dfa59f341d42@haskell.org> References: <044.180348374c60284a01c4dfa59f341d42@haskell.org> Message-ID: <059.0bd0996d8fd262214702d061c40dcd1d@haskell.org> #7593: Unable to print exceptions of unicode identifiers -------------------------------------+------------------------------------- Reporter: dagit | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Incorrect | Difficulty: Unknown warning at compile-time | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jeremy-list): The workaround I've been using is to add "//TRANSLIT" to the encoding of stdin, stdout, and stderr. I believe this should be the default rather than something I have to specify in my program. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 26 15:19:58 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Dec 2014 15:19:58 -0000 Subject: [GHC] #9926: Restore INSTALL file in src dist Message-ID: <047.2ac1500d1611590565c97bb128aecaed@haskell.org> #9926: Restore INSTALL file in src dist -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Documentation | Version: 7.10.1-rc1 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I seem to recall previous source distributions having an `INSTALL` file with instructions. (The particular detail I was looking for was whether or not I need to `perl boot` the 7.10-rc1 source distro.) There don't seem to be any installation instructions anymore. Could this be restored for future source distros? Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 26 15:49:27 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Dec 2014 15:49:27 -0000 Subject: [GHC] #9927: Should simplifier try more iterations? Message-ID: <047.578e70cae2a9663a3bc68c7bc786ce1f@haskell.org> #9927: Should simplifier try more iterations? -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- When compiling with the `devel1` build, we get debugging output while building libraries. I see a lot of warnings like this: {{{ WARNING: file compiler/simplCore/SimplCore.hs, line 592 Simplifier bailing out after 4 iterations [5024, 247, 22, 1] Size = {terms: 3,735, types: 3,028, coercions: 216} }}} It looks to me like the simplifier is doing quite a nice job and shouldn't give up so soon. Concretely, I propose: increase the cutoff and see what the effect is on timing of running the entire GHC build, at whatever settings a performance guru thinks appropriate (almost certainly ''not'' `devel1`!). Ideally, the testing would take place on ghcspeed, so that it's a controlled environment and can be compared nicely with historical performance. I have not carried out this proposal myself because I'm not sure if there are other issues at work here (I don't know the simplifier much at all), and I don't know if there is even a way to get ghcspeed to do this for us. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 26 16:21:54 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Dec 2014 16:21:54 -0000 Subject: [GHC] #9928: Wrong information about the version of the time library in the release notes of various versions of GHC Message-ID: <042.da80f41221c9fccf24e54a1fbfd2424e@haskell.org> #9928: Wrong information about the version of the time library in the release notes of various versions of GHC -------------------------------------+------------------------------------- Reporter: asr | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Documentation | Version: 7.10.1-rc1 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The information about the version of the time library is wrong in the release notes of [https://downloads.haskell.org/~ghc/7.10.1-rc1/docs/html/users_guide/release-7-10-1.html GHC 7.10.1], [https://downloads.haskell.org/~ghc/7.8.1/docs/html/users_guide/release-7-8-1.html GHC 7.8.3] and [https://downloads.haskell.org/~ghc/7.6.1/docs/html/users_guide/release-7-6-1.html GHC 7.6.1]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 26 16:30:02 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Dec 2014 16:30:02 -0000 Subject: [GHC] #9927: Should simplifier try more iterations? In-Reply-To: <047.578e70cae2a9663a3bc68c7bc786ce1f@haskell.org> References: <047.578e70cae2a9663a3bc68c7bc786ce1f@haskell.org> Message-ID: <062.4bc6aa38e72913f8c0c42c9560d002f7@haskell.org> #9927: Should simplifier try more iterations? -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nomeata): ghcspeed is currently not well prepared for such manual runs. There are two options: * Simply do the commit, push to master, see what happens, and revert if you don?t like it. It?s not like you are breaking things, and until last year, this was the normal way anyways. * Do the usual local comparisons of two working copies in validate settings and using nofib-compare. Attach the result to the ticket and discuss. What would you expect from ghcspeed that you would not get this way? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 26 19:12:32 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Dec 2014 19:12:32 -0000 Subject: [GHC] #9929: New alias handling not compatible with LLVM 3.4 Message-ID: <047.16e0d585b02943379458702a5beede5a@haskell.org> #9929: New alias handling not compatible with LLVM 3.4 -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler (LLVM) | Version: 7.10.1-rc1 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Compile- Difficulty: Unknown | time crash Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- As reported by Joachim here: https://www.haskell.org/pipermail/ghc- devs/2014-November/007480.html, and it happens for me too. It seems to affect every program compiled with `-fllvm`; T5681 just happens to be the only such program in the normal test suite. Faced with the definitions {{{ @Main_zdwwork_info_itable$def = internal constant %Main_zdwwork_entry_struct<{ i64 add (i64 sub (i64 ptrtoint (i8* @S2ZH_srt to i64),i64 ptrtoint ( void (i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64)* @Main_zdwwork_info$def to i64)),i64 8), i64 4294967299, i64 0, i64 4294967311}>, section "X98A__STRIP,__me3", align 8 @Main_zdwwork_info_itable = alias i8* bitcast (%Main_zdwwork_entry_struct* @Main_zdwwork_info_itable$def to i8*) }}} LLVM 3.4 produced the assembly {{{ .type Main_zdwwork_info_itable, at object # @Main_zdwwork_info_itable .section .rodata,"a", at progbits ; note .rodata, not X98A__STRIP,__me3! .globl Main_zdwwork_info_itable .align 16 Main_zdwwork_info_itable: .quad (S2ZH_srt$def-Main_zdwwork_info$def)+8 .quad 4294967299 # 0x100000003 .quad 0 # 0x0 .quad 4294967311 # 0x10000000f .size Main_zdwwork_info_itable, 32 }}} At first I thought this was an LLVM bug, but after reading http://llvm.org/docs/LangRef.html#linkage-types I'm not sure; maybe the `internal` linkage type means that `@Main_zdwwork_info_itable$def` is just a constant value without any "identity", so the LLVM optimizer is free to drop it, merge it with another constant, or move it to another section? One workaround would be to use external linkage for these `foo_info_itable$def` symbols, and then if desired (to reduce symbol table size), strip out any `.global bar$def` statements in the LLVM mangler...? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 26 19:20:11 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Dec 2014 19:20:11 -0000 Subject: [GHC] #9929: New alias handling not compatible with LLVM 3.4 In-Reply-To: <047.16e0d585b02943379458702a5beede5a@haskell.org> References: <047.16e0d585b02943379458702a5beede5a@haskell.org> Message-ID: <062.d60033bf085c0dca19eca6e99f709111@haskell.org> #9929: New alias handling not compatible with LLVM 3.4 -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc1 (LLVM) | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: Linux | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): A small test case for LLVM's behavior here: {{{ ; test.ll @foo$def = internal constant i64 123, section ".mysection" @foo = alias i8* bitcast (i64* @foo$def to i8*) $ opt-3.4 -O1 test.ll -o test.lo && llc-3.4 test.lo -o test.s && cat test.s }}} LLVM 3.3 and 3.4 both put `foo` in the `.rodata` section, while 3.5 puts it in `.mysection`. (So perhaps this behavior was considered to be a bug, and fixed in 3.5.) For some reason, GHC's usage of LLVM 3.3 is okay nevertheless (this isn't the way that GHC invokes opt/llc and my guess is that the difference is due to different optimizations enabled by default in LLVM 3.3). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 26 19:27:47 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Dec 2014 19:27:47 -0000 Subject: [GHC] #9929: New alias handling not compatible with LLVM 3.4 In-Reply-To: <047.16e0d585b02943379458702a5beede5a@haskell.org> References: <047.16e0d585b02943379458702a5beede5a@haskell.org> Message-ID: <062.cc2ab1a625fa2f740871a38a6f5a7532@haskell.org> #9929: New alias handling not compatible with LLVM 3.4 -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc1 (LLVM) | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: Linux | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by rwbarton): * cc: bgamari (added) Comment: Actually, would it be possible to skip the whole `$def` game for info tables? We never need to refer to an `_info_itable` symbol from another module, right? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 26 21:51:18 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Dec 2014 21:51:18 -0000 Subject: [GHC] #9386: GHCi cannot load .so in ./ In-Reply-To: <047.6d829b9ae97b1073447115aeba1e6bb7@haskell.org> References: <047.6d829b9ae97b1073447115aeba1e6bb7@haskell.org> Message-ID: <062.2c0c585c95974873c93642c505a504d1@haskell.org> #9386: GHCi cannot load .so in ./ -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): As a workaround, you can use an absolute path {{{ghci Foo `pwd`/*.so}}}. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 26 22:29:54 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Dec 2014 22:29:54 -0000 Subject: [GHC] #9524: GHC uses wrong linker when cross compiling In-Reply-To: <049.96f062346f8aab14c3c1ff251a788093@haskell.org> References: <049.96f062346f8aab14c3c1ff251a788093@haskell.org> Message-ID: <064.9dbe5eb0623ec6da8c1d11439fd5141e@haskell.org> #9524: GHC uses wrong linker when cross compiling -------------------------------------+------------------------------------- Reporter: Kritzefitz | Owner: rwbarton Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.8.3 System | Keywords: Cross compiling Resolution: | Architecture: x86 Operating System: Linux | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by rwbarton): * owner: => rwbarton Comment: It's not that GHC is using the wrong linker, it's that GHC built the wrong code: this hsc2hs is supposed to run on your host system which is Linux (you can tell because it is being built by `/usr/bin/ghc`, which is not a cross-compiler), so it should not be calling `GetModuleFileNameW`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 26 22:50:55 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Dec 2014 22:50:55 -0000 Subject: [GHC] #9924: libffi configure script does not detect MSYS2 Windows 10 x86_64 In-Reply-To: <044.eb148a97098db208d1e56e2d87b80e8c@haskell.org> References: <044.eb148a97098db208d1e56e2d87b80e8c@haskell.org> Message-ID: <059.130b7211eb87e8686a769d4fe1eb30dc@haskell.org> #9924: libffi configure script does not detect MSYS2 Windows 10 x86_64 -------------------------------------+------------------------------------- Reporter: luite | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: | Difficulty: Unknown None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by hvr): ...would the `config.guess` & `config.sub` files from the top-level `ghc.git` folder be new enough? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 26 23:41:58 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Dec 2014 23:41:58 -0000 Subject: [GHC] #9929: New alias handling not compatible with LLVM 3.4 In-Reply-To: <047.16e0d585b02943379458702a5beede5a@haskell.org> References: <047.16e0d585b02943379458702a5beede5a@haskell.org> Message-ID: <062.3ef1d669fc8a468841b72223d5792118@haskell.org> #9929: New alias handling not compatible with LLVM 3.4 -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc1 (LLVM) | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: Linux | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by erikd): * cc: erikd (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 26 23:48:02 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Dec 2014 23:48:02 -0000 Subject: [GHC] #9873: Use CONF_GCC_LINKER_OPTS_STAGE2 only in stage2 In-Reply-To: <046.77f53bab4b42e7b7f0531b045d80ca9c@haskell.org> References: <046.77f53bab4b42e7b7f0531b045d80ca9c@haskell.org> Message-ID: <061.34985d084206510c2fd7ba627c2182b8@haskell.org> #9873: Use CONF_GCC_LINKER_OPTS_STAGE2 only in stage2 -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.9 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by erikd): Mine was a separate problem so I raised ticket #9920. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 26 23:48:51 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Dec 2014 23:48:51 -0000 Subject: [GHC] #9524: GHC uses wrong linker when cross compiling In-Reply-To: <049.96f062346f8aab14c3c1ff251a788093@haskell.org> References: <049.96f062346f8aab14c3c1ff251a788093@haskell.org> Message-ID: <064.14c266fa2acc2b62dc4be6fea93a2e27@haskell.org> #9524: GHC uses wrong linker when cross compiling -------------------------------------+------------------------------------- Reporter: Kritzefitz | Owner: rwbarton Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.8.4 System | Keywords: Cross compiling Resolution: | Architecture: x86 Operating System: Linux | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by Kritzefitz): * version: 7.8.3 => 7.8.4 Comment: That makes sense. Thanks for clarification, I just reproduces this with GHC 7.8.4 and had the same result. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 26 23:51:13 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Dec 2014 23:51:13 -0000 Subject: [GHC] #9920: Segfault in arm binary with llvm 3.5 (was: Segfault in arm binary) In-Reply-To: <044.555edb7e560a8d41cf35aba7c1c44446@haskell.org> References: <044.555edb7e560a8d41cf35aba7c1c44446@haskell.org> Message-ID: <059.38a4f5bb91c9f5c40c467ad27901eb2a@haskell.org> #9920: Segfault in arm binary with llvm 3.5 -------------------------------------------+--------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------------+--------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 27 00:34:22 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Dec 2014 00:34:22 -0000 Subject: [GHC] #9524: GHC uses wrong linker when cross compiling In-Reply-To: <049.96f062346f8aab14c3c1ff251a788093@haskell.org> References: <049.96f062346f8aab14c3c1ff251a788093@haskell.org> Message-ID: <064.7fce7300df9b78be1a7ec28e42ea468a@haskell.org> #9524: GHC uses wrong linker when cross compiling -------------------------------------+------------------------------------- Reporter: Kritzefitz | Owner: rwbarton Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.8.4 System | Keywords: Cross compiling Resolution: | Architecture: x86 Operating System: Linux | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): I suspect the fix is just to delete the first three non-comment lines of hsc2hs's Main.hs, but my GHC HEAD cross-compiling setup is failing for an unrelated reason so I can't test it right now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 27 00:36:31 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Dec 2014 00:36:31 -0000 Subject: [GHC] #9691: GHC-HEAD runtime is broken on arm In-Reply-To: <047.9fcb5b64ebe9f7a33ad168c55acc7b20@haskell.org> References: <047.9fcb5b64ebe9f7a33ad168c55acc7b20@haskell.org> Message-ID: <062.6d699a2506ee506a62b49f4b6e9420ac@haskell.org> #9691: GHC-HEAD runtime is broken on arm ----------------------------------------+--------------------------- Reporter: mkbrandt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------+--------------------------- Comment (by erikd): This is a duplicate of #9920 (which has far more analysis and a solution). Ok, to close this one? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 27 01:01:16 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Dec 2014 01:01:16 -0000 Subject: [GHC] #9924: libffi configure script does not detect MSYS2 Windows 10 x86_64 In-Reply-To: <044.eb148a97098db208d1e56e2d87b80e8c@haskell.org> References: <044.eb148a97098db208d1e56e2d87b80e8c@haskell.org> Message-ID: <059.4fd36a7cc25167e53f5bff80cf105f6c@haskell.org> #9924: libffi configure script does not detect MSYS2 Windows 10 x86_64 -------------------------------------+------------------------------------- Reporter: luite | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: | Difficulty: Unknown None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by luite): Yep, I just completed a build succesfully with the following patch: {{{ diff --git a/libffi/ghc.mk b/libffi/ghc.mk index ec37f0c..62ffe32 100644 --- a/libffi/ghc.mk +++ b/libffi/ghc.mk @@ -89,6 +89,8 @@ $(libffi_STAMP_CONFIGURE): $(TOUCH_DEP) cd libffi && \ $(LIBFFI_PATH_MANGLE) \ cd build && \ + cp $(TOP)/config.guess config.guess && \ + cp $(TOP)/config.sub config.sub && \ CC=$(CC_STAGE1) \ CXX=$(CC_STAGE1) \ LD=$(LD) \ }}} (This probably fails if `$(TOP)` contains spaces, due to missing quotes) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 27 08:12:06 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Dec 2014 08:12:06 -0000 Subject: [GHC] #9924: libffi configure script does not detect MSYS2 Windows 10 x86_64 In-Reply-To: <044.eb148a97098db208d1e56e2d87b80e8c@haskell.org> References: <044.eb148a97098db208d1e56e2d87b80e8c@haskell.org> Message-ID: <059.7c4464c174446dd27d1e09ef28bfb90a@haskell.org> #9924: libffi configure script does not detect MSYS2 Windows 10 x86_64 -------------------------------------+------------------------------------- Reporter: luite | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: | Difficulty: Unknown None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"9ae78b0ac20199982b994122889a04c6124e01b2/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="9ae78b0ac20199982b994122889a04c6124e01b2" Copy GHC's config.guess/sub over libffi's versions This should address #9924 as GHC's config.guess/sub versions need to be up to date anyway. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 27 08:12:23 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Dec 2014 08:12:23 -0000 Subject: [GHC] #9924: libffi configure script does not detect MSYS2 Windows 10 x86_64 In-Reply-To: <044.eb148a97098db208d1e56e2d87b80e8c@haskell.org> References: <044.eb148a97098db208d1e56e2d87b80e8c@haskell.org> Message-ID: <059.17fbd4606d0ed63924ccf8fa6536fa53@haskell.org> #9924: libffi configure script does not detect MSYS2 Windows 10 x86_64 -------------------------------------+------------------------------------- Reporter: luite | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.1 Component: Build | Version: 7.10.1-rc1 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by hvr): * status: new => merge * failure: None/Unknown => Building GHC failed * component: Compiler => Build System * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 27 11:07:24 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Dec 2014 11:07:24 -0000 Subject: [GHC] #9032: Panic with self-import In-Reply-To: <048.b2b35b617fab282b73adc84f1bdd96f5@haskell.org> References: <048.b2b35b617fab282b73adc84f1bdd96f5@haskell.org> Message-ID: <063.3f63ff4d982c8013fdb218f78d901987@haskell.org> #9032: Panic with self-import -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.10.1 Component: Template | Version: 7.8.2 Haskell | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Compile- | Related Tickets: #1012 time crash | Test Case: | rename/should_fail/T9032 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by hvr): * status: closed => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 27 11:19:36 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Dec 2014 11:19:36 -0000 Subject: [GHC] #9524: GHC uses wrong linker when cross compiling In-Reply-To: <049.96f062346f8aab14c3c1ff251a788093@haskell.org> References: <049.96f062346f8aab14c3c1ff251a788093@haskell.org> Message-ID: <064.5d608a8da6c78f5f61224fbc08756c85@haskell.org> #9524: GHC uses wrong linker when cross compiling -------------------------------------+------------------------------------- Reporter: Kritzefitz | Owner: rwbarton Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.8.4 System | Keywords: Cross compiling Resolution: | Architecture: x86 Operating System: Linux | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Kritzefitz): I tested it (with 7.8.4) and the problem with `GetModuleFileNameW` went away. It's now failing with the failure message that threads aren't supported. Is this related or should I open another ticket? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 27 12:48:35 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Dec 2014 12:48:35 -0000 Subject: [GHC] #9922: Partial type signatures + extensions panic In-Reply-To: <047.bcb93dee275eec47e30ed9673a9b0d12@haskell.org> References: <047.bcb93dee275eec47e30ed9673a9b0d12@haskell.org> Message-ID: <062.f854cac84e0da84f8843b4cc5c362450@haskell.org> #9922: Partial type signatures + extensions panic -------------------------------------+------------------------------------- Reporter: monoidal | Owner: thomasw Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Compile- | Related Tickets: time crash | Test Case: | Blocking: | Differential Revisions: D595 | -------------------------------------+------------------------------------- Changes (by thomasw): * owner: => thomasw * differential: => D595 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 27 12:50:07 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Dec 2014 12:50:07 -0000 Subject: [GHC] #9922: Partial type signatures + extensions panic In-Reply-To: <047.bcb93dee275eec47e30ed9673a9b0d12@haskell.org> References: <047.bcb93dee275eec47e30ed9673a9b0d12@haskell.org> Message-ID: <062.bde8d739f85081f67ac78876184cd094@haskell.org> #9922: Partial type signatures + extensions panic -------------------------------------+------------------------------------- Reporter: monoidal | Owner: thomasw Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Compile- | Related Tickets: time crash | Test Case: | Blocking: | Differential Revisions: Phab:D595 | -------------------------------------+------------------------------------- Changes (by thomasw): * differential: D595 => Phab:D595 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 27 12:51:24 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Dec 2014 12:51:24 -0000 Subject: [GHC] #9922: Partial type signatures + extensions panic In-Reply-To: <047.bcb93dee275eec47e30ed9673a9b0d12@haskell.org> References: <047.bcb93dee275eec47e30ed9673a9b0d12@haskell.org> Message-ID: <062.3baa0fa6d1345762e6564f3b4d7b45fa@haskell.org> #9922: Partial type signatures + extensions panic -------------------------------------+------------------------------------- Reporter: monoidal | Owner: thomasw Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Compile- | Related Tickets: time crash | Test Case: | Blocking: | Differential Revisions: Phab:D595 | -------------------------------------+------------------------------------- Comment (by thomasw): Thanks for finding all the panics I caused :) I fixed it in Phab:D595. Happy holidays. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 27 13:15:50 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Dec 2014 13:15:50 -0000 Subject: [GHC] #9930: By default, a source code would get overwritten by executable on *nix Message-ID: <049.ce546f2e46260ffee3d03a0558c425a6@haskell.org> #9930: By default, a source code would get overwritten by executable on *nix -------------------------------------+------------------------------------- Reporter: Rufflewind | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Other Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- If I have a source code without an extension, say `foo`, and I forget to specify the output file via `-o`, GHC will overwrite it with the executable itself after compilation. This occurs only on *nix-like operating systems. Presumably something similar could happen on Windows ? fortunately, those who use `.exe` for source code are probably among the minority. Minimum example: {{{#!sh #!/bin/sh echo >foo 'main=undefined' ghc -x hs foo less foo # 'foo' now contains binary data }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 27 13:18:31 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Dec 2014 13:18:31 -0000 Subject: [GHC] #9930: By default, a source code without extension would get overwritten by executable on *nix (was: By default, a source code would get overwritten by executable on *nix) In-Reply-To: <049.ce546f2e46260ffee3d03a0558c425a6@haskell.org> References: <049.ce546f2e46260ffee3d03a0558c425a6@haskell.org> Message-ID: <064.e7896b88a40cc1a6be3b9b2ce2d9de76@haskell.org> #9930: By default, a source code without extension would get overwritten by executable on *nix -------------------------------------+------------------------------------- Reporter: Rufflewind | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 27 14:23:14 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Dec 2014 14:23:14 -0000 Subject: [GHC] #9922: Partial type signatures + extensions panic In-Reply-To: <047.bcb93dee275eec47e30ed9673a9b0d12@haskell.org> References: <047.bcb93dee275eec47e30ed9673a9b0d12@haskell.org> Message-ID: <062.8262068615e38bbfb44e15912a4666d5@haskell.org> #9922: Partial type signatures + extensions panic -------------------------------------+------------------------------------- Reporter: monoidal | Owner: thomasw Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Compile- | Related Tickets: time crash | Test Case: | Blocking: | Differential Revisions: Phab:D595 | -------------------------------------+------------------------------------- Changes (by hvr): * status: new => patch * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 27 15:40:33 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Dec 2014 15:40:33 -0000 Subject: [GHC] #9918: GHC chooses an instance between two overlapping, but cannot resolve a clause within the similar closed type family In-Reply-To: <045.8b42c360bfa608017b9b2986029ca51e@haskell.org> References: <045.8b42c360bfa608017b9b2986029ca51e@haskell.org> Message-ID: <060.92c6790371e3bf5831fe1b645402541f@haskell.org> #9918: GHC chooses an instance between two overlapping, but cannot resolve a clause within the similar closed type family -------------------------------------+------------------------------------- Reporter: qnikst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by oleg): Perhaps the following two examples, deliberately simple, better illustrate the problem -- the difference in behavior of overlapping instances and closed type families. Example1: {{{ {-# LANGUAGE MultiParamTypeClasses, FlexibleInstances, FlexibleContexts #-} {-# LANGUAGE UndecidableInstances, OverlappingInstances #-} {-# LANGUAGE TypeFamilies #-} module Sub where data Z = Z data S n = S n -- x is greater than y by some amount class Sub x y where how_larger_is_x_than_y :: x -> y -> Int instance Sub x x where how_larger_is_x_than_y _ _ = 0 instance (x ~ (S x1), Sub x1 y) => Sub x y where how_larger_is_x_than_y ~(S x) y = 1 + how_larger_is_x_than_y x y -- The inferred type shows no constraints! So we obtained the result -- without instantiating the type of y, hence maintaining polymorphism. test y = how_larger_is_x_than_y (S (S y)) y -- inferred type: -- test :: x1 -> Int main = test (S Z) -- 2 }}} Example 2: rewritten using type families. This is how we hoped closed type families could eliminate overlapping instances. {{{ {-# LANGUAGE MultiParamTypeClasses, FlexibleInstances, FlexibleContexts #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE ScopedTypeVariables #-} module Sub1 where data Z = Z data S n = S n class Nat a where nat :: a -> Int instance Nat Z where nat _ = 0 instance Nat n => Nat (S n) where nat ~(S n) = 1 + nat n type family Sub x y :: * where Sub x x = Z Sub (S x) y = S (Sub x y) how_larger_is_x_than_y :: forall x y. (Nat (Sub x y)) => x -> y -> Int how_larger_is_x_than_y x y = nat (undefined :: Sub x y) -- The inferred type has the unresolved constraint test y = how_larger_is_x_than_y (S (S y)) y -- test :: Nat (Sub (S (S y)) y) => y -> Int main = test (S Z) -- 2 }}} As you can see, with overlapping instances, GHC was able to eliminate the constraints on test. But with closed type families, it could not. There are no incoherent instances here, btw. In this simple example, the fact that test in the second example is no longer fully polymorphic does not matter. The code works anyway. But it does matter in the original (submitted) example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 27 15:43:33 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Dec 2014 15:43:33 -0000 Subject: [GHC] #9918: GHC chooses an instance between two overlapping, but cannot resolve a clause within the similar closed type family In-Reply-To: <045.8b42c360bfa608017b9b2986029ca51e@haskell.org> References: <045.8b42c360bfa608017b9b2986029ca51e@haskell.org> Message-ID: <060.839c0115ed023e33002bd6a61878a1d4@haskell.org> #9918: GHC chooses an instance between two overlapping, but cannot resolve a clause within the similar closed type family -------------------------------------+------------------------------------- Reporter: qnikst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by oleg): * cc: oleg (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 27 15:56:05 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Dec 2014 15:56:05 -0000 Subject: [GHC] #9868: ghc: panic! Dynamic linker not initialised In-Reply-To: <046.5f3f9e960e287bc6e82a07e7ce17a8b6@haskell.org> References: <046.5f3f9e960e287bc6e82a07e7ce17a8b6@haskell.org> Message-ID: <061.d075ee12624012d09d207d866d4bccb9@haskell.org> #9868: ghc: panic! Dynamic linker not initialised -------------------------------------+------------------------------------- Reporter: Jamedjo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Compile- | Difficulty: Unknown time crash | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by hanjoosten): Hi, I have the same bug, but on a windows 7 64bits machine. I have installed EclipesFP on it, which uses buildwrapper. The Buildwrapper output is: buildwrapper.exe: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-unknown-mingw32): Dynamic linker not initialised Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug build-wrapper- json:[null,[{"l":{"l":1,"ec":1,"el":1,"c":1,"f":"src\\Database\\Design\\Ampersand\\Input\\Parsing.hs"},"t":"buildwrapper.exe: panic! (the 'impossible' happened)\n (GHC version 7.8.3 for x86_64-unk nown-mingw32):\n\tDynamic linker not initialised\n\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\n","s":"Error"}]] buildwrapper.exe: warning: inet_ntoa from ws2_32 is linked instead of __imp_inet_ntoa buildwrapper.exe: warning: getnameinfo from ws2_32 is linked instead of __imp_getnameinfo buildwrapper.exe: warning: getaddrinfo from ws2_32 is linked instead of __imp_getaddrinfo buildwrapper.exe: warning: freeaddrinfo from ws2_32 is linked instead of __imp_freeaddrinfo buildwrapper.exe: warning: accept from ws2_32 is linked instead of __imp_accept buildwrapper.exe: warning: WSACleanup from ws2_32 is linked instead of __imp_WSACleanup buildwrapper.exe: warning: WSAStartup from ws2_32 is linked instead of __imp_WSAStartup buildwrapper.exe: warning: WSACleanup from ws2_32 is linked instead of __imp_WSACleanup buildwrapper.exe: warning: tolower from msvcrt is linked instead of __imp_tolower buildwrapper.exe: warning: toupper from msvcrt is linked instead of __imp_toupper buildwrapper.exe: warning: isalpha from msvcrt is linked instead of __imp_isalpha buildwrapper.exe: warning: isalnum from msvcrt is linked instead of __imp_isalnum buildwrapper.exe: warning: isupper from msvcrt is linked instead of __imp_isupper buildwrapper.exe: warning: isgraph from msvcrt is linked instead of __imp_isgraph buildwrapper.exe: warning: isprint from msvcrt is linked instead of __imp_isprint buildwrapper.exe: warning: ispunct from msvcrt is linked instead of __imp_ispunct buildwrapper.exe: warning: iscntrl from msvcrt is linked instead of __imp_iscntrl buildwrapper.exe: warning: isupper from msvcrt is linked instead of __imp_isupper buildwrapper.exe: C:\Users\hjo20125\Git\ampersand\.cabal-sandbox\x86_64 -windows-ghc-7.8.3\hslua-0.3.13\HShslua-0.3.13.o: unknown symbol `mingw_getsp' Hope this helps in some way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 27 15:56:56 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Dec 2014 15:56:56 -0000 Subject: [GHC] #9652: Bootstrapping GHC HEAD against itself doesn't work In-Reply-To: <045.174cce8060d844f9c120636e662de792@haskell.org> References: <045.174cce8060d844f9c120636e662de792@haskell.org> Message-ID: <060.1612c0178c49a250b01696a5bf086298@haskell.org> #9652: Bootstrapping GHC HEAD against itself doesn't work -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: D589 | -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"0899caab400e7a095528ea769a7e93a33717ae72/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="0899caab400e7a095528ea769a7e93a33717ae72" Use directory-style database for bootstrapping database Summary: This allows GHC HEAD to be bootstrapped using 7.10. Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: austin Subscribers: carter, thomie Differential Revision: https://phabricator.haskell.org/D589 GHC Trac Issues: #9652 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 27 15:57:56 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Dec 2014 15:57:56 -0000 Subject: [GHC] #9652: Bootstrapping GHC HEAD against itself doesn't work In-Reply-To: <045.174cce8060d844f9c120636e662de792@haskell.org> References: <045.174cce8060d844f9c120636e662de792@haskell.org> Message-ID: <060.7cdab192ecc0d978242fb77c2ebfda26@haskell.org> #9652: Bootstrapping GHC HEAD against itself doesn't work -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: merge Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: D589 | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => merge Comment: So, I fixed a bug so that GHC HEAD can be compiled with 7.10. However, we'll need to fix GHC's confusion over where packages live in order get 7.10 to compile itself, or GHC HEAD to bootstrap itself. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 27 16:28:41 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Dec 2014 16:28:41 -0000 Subject: [GHC] Batch modify: #9032, #9652, #9762, #9905, #9924 Message-ID: <20141227162841.3BFB63A2FF@ghc.haskell.org> Batch modification to #9032, #9652, #9762, #9905, #9924 by hvr: Action: merged Comment: has been cherry-picked into ghc-7.10 branch -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 27 16:29:40 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Dec 2014 16:29:40 -0000 Subject: [GHC] #9852: Add missing export lists In-Reply-To: <045.0c137db4833268f838cfd23c79dcf251@haskell.org> References: <045.0c137db4833268f838cfd23c79dcf251@haskell.org> Message-ID: <060.9966d1f8cb5ea3d88b1197345a68dfb9@haskell.org> #9852: Add missing export lists -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: patch Priority: low | Milestone: 7.12.1 Component: Core | Version: 7.9 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D551 | -------------------------------------+------------------------------------- Changes (by hvr): * milestone: 7.10.1 => 7.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 27 17:15:30 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Dec 2014 17:15:30 -0000 Subject: [GHC] #9762: #8696 + #9012 In-Reply-To: <047.1416552af7b7cba6e17e930c77b546df@haskell.org> References: <047.1416552af7b7cba6e17e930c77b546df@haskell.org> Message-ID: <062.63ec1a8476957c4a9202e1c5650e5626@haskell.org> #9762: #8696 + #9012 -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8696, #9012, Test Case: | #9909 Blocking: | Differential Revisions: Phab:D583 | -------------------------------------+------------------------------------- Comment (by nomeata): The test is broken in a non-dynamic build of GHC. Not serious, but this affects travis, and it would be nice if travis would also give thumbs-up on the 7.10 branch, hence my request to also merge 1dcef98a77afa0f9dc73896b8d8cc7444e2e0039 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 27 17:15:50 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Dec 2014 17:15:50 -0000 Subject: [GHC] #9762: #8696 + #9012 In-Reply-To: <047.1416552af7b7cba6e17e930c77b546df@haskell.org> References: <047.1416552af7b7cba6e17e930c77b546df@haskell.org> Message-ID: <062.5858aaad71ae6ef963dc53c63c9233cf@haskell.org> #9762: #8696 + #9012 -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton Type: bug | Status: merge Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8696, #9012, Test Case: | #9909 Blocking: | Differential Revisions: Phab:D583 | -------------------------------------+------------------------------------- Changes (by nomeata): * status: closed => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 27 17:47:02 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Dec 2014 17:47:02 -0000 Subject: [GHC] #9931: Option to truncate Show output in ghci REPL Message-ID: <046.6d68de86d6a269e0a0cd4e73235bebfc@haskell.org> #9931: Option to truncate Show output in ghci REPL -------------------------------------+------------------------------------- Reporter: pumpkin | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Perhaps a configurable limit, with a :more (or :all) that would give you more if you ask for it. Seems pretty harmless and could help usability a bit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 27 18:14:05 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Dec 2014 18:14:05 -0000 Subject: [GHC] #9762: #8696 + #9012 In-Reply-To: <047.1416552af7b7cba6e17e930c77b546df@haskell.org> References: <047.1416552af7b7cba6e17e930c77b546df@haskell.org> Message-ID: <062.9ecf46f0eee3686962244612bc95b233@haskell.org> #9762: #8696 + #9012 -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8696, #9012, Test Case: | #9909 Blocking: | Differential Revisions: Phab:D583 | -------------------------------------+------------------------------------- Changes (by hvr): * status: merge => closed Comment: Replying to [comment:11 nomeata]: > ..., hence my request to also merge 1dcef98a77afa0f9dc73896b8d8cc7444e2e0039 cherry-picked via 62a6d14be0076da0adb3524e5ef70352beb4ee13 to ghc-7.10 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 27 19:18:22 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Dec 2014 19:18:22 -0000 Subject: [GHC] #7473: getModificationTime gives only second-level resolution In-Reply-To: <045.e4643e54563d29d7370456429b4f7379@haskell.org> References: <045.e4643e54563d29d7370456429b4f7379@haskell.org> Message-ID: <060.4b5da8fe0e12192ca844c653022e68d6@haskell.org> #7473: getModificationTime gives only second-level resolution -------------------------------------+------------------------------------- Reporter: duncan | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Core | Version: 7.6.1 Libraries | Keywords: directory Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by redneb): The pull request has been merged so I think this bug can be closed now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 27 19:36:07 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Dec 2014 19:36:07 -0000 Subject: [GHC] #7473: getModificationTime gives only second-level resolution In-Reply-To: <045.e4643e54563d29d7370456429b4f7379@haskell.org> References: <045.e4643e54563d29d7370456429b4f7379@haskell.org> Message-ID: <060.46df1b22731d17d85a3e215da89461a3@haskell.org> #7473: getModificationTime gives only second-level resolution -------------------------------------+------------------------------------- Reporter: duncan | Owner: ekmett Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.6.1 Libraries | Keywords: directory Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by hvr): * status: new => closed * resolution: => fixed * milestone: 7.12.1 => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 27 20:06:25 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Dec 2014 20:06:25 -0000 Subject: [GHC] #9243: Recompilation avoidance works imperfectly with -fno-code/-fwrite-interface In-Reply-To: <045.eb0d37b8e28f9b0d21ba7b721e124a6b@haskell.org> References: <045.eb0d37b8e28f9b0d21ba7b721e124a6b@haskell.org> Message-ID: <060.4c231e5c432f0b8a947201b17945c415@haskell.org> #9243: Recompilation avoidance works imperfectly with -fno-code/-fwrite-interface -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: backpack Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: D596 | -------------------------------------+------------------------------------- Changes (by ezyang): * owner: => ezyang * priority: normal => high * differential: => D596 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 27 20:08:43 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Dec 2014 20:08:43 -0000 Subject: [GHC] #9243: Recompilation avoidance works imperfectly with -fno-code/-fwrite-interface In-Reply-To: <045.eb0d37b8e28f9b0d21ba7b721e124a6b@haskell.org> References: <045.eb0d37b8e28f9b0d21ba7b721e124a6b@haskell.org> Message-ID: <060.130e64013319c99242dfb8aa810de0e1@haskell.org> #9243: Recompilation avoidance works imperfectly with -fno-code/-fwrite-interface -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: backpack Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: D596 | -------------------------------------+------------------------------------- Changes (by ezyang): * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 27 20:13:32 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Dec 2014 20:13:32 -0000 Subject: [GHC] #9764: Home package modules silently override available modules from package database In-Reply-To: <045.c611384dbc686471200b2ebf01fe484a@haskell.org> References: <045.c611384dbc686471200b2ebf01fe484a@haskell.org> Message-ID: <060.29bdcccdeefb19c1cccbc54538f7080e@haskell.org> #9764: Home package modules silently override available modules from package database -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: closed request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: wontfix | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: accepts invalid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => wontfix Comment: Our resolution for 7.10 and the indefinite future is this: 1. Normal modules do NOT warn about shadowing, so we don't break Wall'd code. 2. Signature modules silently get merged with the available modules in the context. So we just treat normal modules differently from signature modules. This is a little different from how the Backpack paper works, but I don't think there is any difference in expressivity. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 27 20:14:30 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Dec 2014 20:14:30 -0000 Subject: [GHC] #9717: More lazy orphan module loading In-Reply-To: <045.9158d61e70fef57bd7cb8f0956c9909d@haskell.org> References: <045.9158d61e70fef57bd7cb8f0956c9909d@haskell.org> Message-ID: <060.753f3aca95e1c282dc18fdaca0d69f1a@haskell.org> #9717: More lazy orphan module loading -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.9 (Type checker) | Keywords: backpack Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: D454 | -------------------------------------+------------------------------------- Changes (by ezyang): * differential: => D454 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 27 20:15:34 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Dec 2014 20:15:34 -0000 Subject: [GHC] #9508: Rename package key In-Reply-To: <045.9321326ff6fd1cf354acf4ce2c70bc86@haskell.org> References: <045.9321326ff6fd1cf354acf4ce2c70bc86@haskell.org> Message-ID: <060.dd0f1fe6d39a958686c0f76d87536070@haskell.org> #9508: Rename package key -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: backpack Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by ezyang): Our window for doing this renaming is rapidly closing: once we release 7.10 it probably will not be worth it to rename it. Maybe we should just give up on the renaming? (I'd like that, less work for me!) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 27 20:15:42 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Dec 2014 20:15:42 -0000 Subject: [GHC] #9508: Rename package key In-Reply-To: <045.9321326ff6fd1cf354acf4ce2c70bc86@haskell.org> References: <045.9321326ff6fd1cf354acf4ce2c70bc86@haskell.org> Message-ID: <060.370d473108a18597466706d45c1e1c28@haskell.org> #9508: Rename package key -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: backpack Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by ezyang): * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 27 20:16:06 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Dec 2014 20:16:06 -0000 Subject: [GHC] #9243: Recompilation avoidance doesn't work for -fno-code/-fwrite-interface (was: Recompilation avoidance works imperfectly with -fno-code/-fwrite-interface) In-Reply-To: <045.eb0d37b8e28f9b0d21ba7b721e124a6b@haskell.org> References: <045.eb0d37b8e28f9b0d21ba7b721e124a6b@haskell.org> Message-ID: <060.75aa824c0e92cd999ec2898ae54d7f51@haskell.org> #9243: Recompilation avoidance doesn't work for -fno-code/-fwrite-interface -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: backpack Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: D596 | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 27 20:17:18 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Dec 2014 20:17:18 -0000 Subject: [GHC] #9067: Optimize clearNursery by short-circuiting when we get to currentNursery In-Reply-To: <045.c7f02cf5a52be23a613e87f34c2ef3ee@haskell.org> References: <045.c7f02cf5a52be23a613e87f34c2ef3ee@haskell.org> Message-ID: <060.bb1267f7192c4d83b7d6954e503a8a39@haskell.org> #9067: Optimize clearNursery by short-circuiting when we get to currentNursery -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: closed Priority: low | Milestone: Component: Runtime | Version: 7.9 System | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: Phab:D318 | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => fixed Comment: {{{ commit e22bc0dedb9e9da0176ad7ce4a74acbefedc7207 Author: Simon Marlow Date: Tue Oct 7 10:30:36 2014 +0100 Make clearNursery free Summary: clearNursery resets all the bd->free pointers of nursery blocks to make the blocks empty. In profiles we've seen clearNursery taking significant amounts of time particularly with large -N and -A values. This patch moves the work of clearNursery to the point at which we actually need the new block, thereby introducing an invariant that blocks to the right of the CurrentNursery pointer still need their bd->free pointer reset. This should make things faster overall, because we don't need to clear blocks that we don't use. Test Plan: validate Reviewers: AndreasVoellmy, ezyang, austin Subscribers: thomie, carter, ezyang, simonmar Differential Revision: https://phabricator.haskell.org/D318 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 27 20:17:29 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Dec 2014 20:17:29 -0000 Subject: [GHC] #9067: Optimize clearNursery by short-circuiting when we get to currentNursery In-Reply-To: <045.c7f02cf5a52be23a613e87f34c2ef3ee@haskell.org> References: <045.c7f02cf5a52be23a613e87f34c2ef3ee@haskell.org> Message-ID: <060.e82e4a41e01e8fc62910bcbf5aee6649@haskell.org> #9067: Optimize clearNursery by short-circuiting when we get to currentNursery -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: closed Priority: low | Milestone: 7.10.1 Component: Runtime | Version: 7.9 System | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: Phab:D318 | -------------------------------------+------------------------------------- Changes (by ezyang): * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 27 20:17:58 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Dec 2014 20:17:58 -0000 Subject: [GHC] #9717: More lazy orphan module loading In-Reply-To: <045.9158d61e70fef57bd7cb8f0956c9909d@haskell.org> References: <045.9158d61e70fef57bd7cb8f0956c9909d@haskell.org> Message-ID: <060.f93fb8f3a2df9d1e1771b8d146ecd4fe@haskell.org> #9717: More lazy orphan module loading -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.9 (Type checker) | Keywords: backpack Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D454 | -------------------------------------+------------------------------------- Changes (by ezyang): * differential: D454 => Phab:D454 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 27 20:23:55 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Dec 2014 20:23:55 -0000 Subject: [GHC] #9722: ghcirun004 intermittently fails with ghc: ioManagerWakeup: write: Bad file descriptor In-Reply-To: <045.2ac77d27a9a71df853ff4839dd3c18d0@haskell.org> References: <045.2ac77d27a9a71df853ff4839dd3c18d0@haskell.org> Message-ID: <060.80285b89f301c5293c88a7859955bc17@haskell.org> #9722: ghcirun004 intermittently fails with ghc: ioManagerWakeup: write: Bad file descriptor -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: GHCi | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: crash | Related Tickets: Test Case: ghcirun004 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by ezyang): I haven't seen this bug recently, but I don't see any commits which might have solved it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 27 20:26:49 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Dec 2014 20:26:49 -0000 Subject: [GHC] #5910: Holes with other constraints In-Reply-To: <045.7ce17b393921f6c85549a3e0d688b66c@haskell.org> References: <045.7ce17b393921f6c85549a3e0d688b66c@haskell.org> Message-ID: <060.c0a9d8453655947d4fc1adbdcc706f16@haskell.org> #5910: Holes with other constraints -------------------------------------+------------------------------------- Reporter: xnyhps | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.5 Component: Compiler | Keywords: holes (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: Other | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by ezyang): * priority: high => normal -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 27 20:32:35 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Dec 2014 20:32:35 -0000 Subject: [GHC] #9243: Recompilation avoidance doesn't work for -fno-code/-fwrite-interface In-Reply-To: <045.eb0d37b8e28f9b0d21ba7b721e124a6b@haskell.org> References: <045.eb0d37b8e28f9b0d21ba7b721e124a6b@haskell.org> Message-ID: <060.5eb1c8f793e5e278857195ca3c33423f@haskell.org> #9243: Recompilation avoidance doesn't work for -fno-code/-fwrite-interface -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: patch Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: backpack Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: D596 | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 27 20:59:21 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Dec 2014 20:59:21 -0000 Subject: [GHC] #9276: audit ghc floating point support for IEEE (non)compliance In-Reply-To: <045.ad291164c8d6795bec19bab0953045e8@haskell.org> References: <045.ad291164c8d6795bec19bab0953045e8@haskell.org> Message-ID: <060.e23dc7eadce4627a0db8013b7666d50a@haskell.org> #9276: audit ghc floating point support for IEEE (non)compliance -------------------------------------+------------------------------------- Reporter: carter | Owner: carter Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: 3070, | 8364, 9304, 9530 | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by carter): * priority: high => normal * milestone: 7.10.1 => 7.12.1 Comment: remilestoning to 7.12, -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 27 21:00:22 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Dec 2014 21:00:22 -0000 Subject: [GHC] #8396: cleanup / refactor native code gens In-Reply-To: <045.aa7cf1c57555c9884c0054e57028458c@haskell.org> References: <045.aa7cf1c57555c9884c0054e57028458c@haskell.org> Message-ID: <060.652180c8383a4f641ba89fca8e94218f@haskell.org> #8396: cleanup / refactor native code gens -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: (NCG) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #8299 , #8287 None/Unknown | ,#8272 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by carter): * priority: high => normal * milestone: 7.10.1 => 7.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 27 21:00:42 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Dec 2014 21:00:42 -0000 Subject: [GHC] #8279: bad alignment in code gen yields substantial perf issue In-Reply-To: <045.3fa2c6fed8a76bf664b09b6a4e78beae@haskell.org> References: <045.3fa2c6fed8a76bf664b09b6a4e78beae@haskell.org> Message-ID: <060.72889d2b35a9e51e65012b7839f045aa@haskell.org> #8279: bad alignment in code gen yields substantial perf issue -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: #8082 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by carter): * priority: high => normal * milestone: 7.10.1 => 7.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 27 21:01:36 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Dec 2014 21:01:36 -0000 Subject: [GHC] #8287: exploring calling convention changes and related engineering for 7.10 In-Reply-To: <045.594cdade97652c9633f43b7996da7568@haskell.org> References: <045.594cdade97652c9633f43b7996da7568@haskell.org> Message-ID: <060.be719cdfcdc67d51962262a32cfddd6f@haskell.org> #8287: exploring calling convention changes and related engineering for 7.10 -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: task | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Rocket Science Type of failure: | Blocked By: 8299 None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by carter): * milestone: 7.10.1 => 7.12.1 Comment: lowering priority and moving to 7.12 mileston -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 27 21:01:49 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Dec 2014 21:01:49 -0000 Subject: [GHC] #8287: exploring calling convention changes and related engineering for 7.10 In-Reply-To: <045.594cdade97652c9633f43b7996da7568@haskell.org> References: <045.594cdade97652c9633f43b7996da7568@haskell.org> Message-ID: <060.6bc1d4303b3d8337d1c413b34722df85@haskell.org> #8287: exploring calling convention changes and related engineering for 7.10 -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Rocket Science Type of failure: | Blocked By: 8299 None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by carter): * priority: high => normal -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 27 21:03:05 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Dec 2014 21:03:05 -0000 Subject: [GHC] #8299: Add richer data model address arithmetic: AddrDiff and AddrInt (ie d Int_ptr_diff and Int_ptr_size) In-Reply-To: <045.f91b5080e44be46bd4f6c2cd9b6ce680@haskell.org> References: <045.f91b5080e44be46bd4f6c2cd9b6ce680@haskell.org> Message-ID: <060.32e444ba86ff897f568a3e1823eab166@haskell.org> #8299: Add richer data model address arithmetic: AddrDiff and AddrInt (ie d Int_ptr_diff and Int_ptr_size) -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: feature | Status: new request | Milestone: 7.12.1 Priority: high | Version: 7.6.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Project (more Unknown/Multiple | than a week) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: 8287 | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by carter): * milestone: 7.10.1 => 7.12.1 Comment: this is still an issue, but should be punted to 7.12 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 27 21:03:34 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Dec 2014 21:03:34 -0000 Subject: [GHC] #8364: equip GHC with an accurate internal model of floating point In-Reply-To: <045.1a954a36897b343743f15a900b2f72bd@haskell.org> References: <045.1a954a36897b343743f15a900b2f72bd@haskell.org> Message-ID: <060.428f802c51ebe3fc99f1adf20ffad8ea@haskell.org> #8364: equip GHC with an accurate internal model of floating point -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: feature | Status: new request | Milestone: 7.12.1 Priority: high | Version: 7.6.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Project (more Unknown/Multiple | than a week) Type of failure: | Blocked By: 9276 None/Unknown | Related Tickets: #9276 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by carter): * milestone: 7.10.1 => 7.12.1 Comment: still high priority, but moving to 7.12 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 28 01:52:25 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Dec 2014 01:52:25 -0000 Subject: [GHC] #9852: Add missing export lists In-Reply-To: <045.0c137db4833268f838cfd23c79dcf251@haskell.org> References: <045.0c137db4833268f838cfd23c79dcf251@haskell.org> Message-ID: <060.6f0b86c0750daf561be85a7e13b93a57@haskell.org> #9852: Add missing export lists -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: patch Priority: low | Milestone: 7.12.1 Component: Core | Version: 7.9 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D551 | -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"d6e7f5dc9db7e382ce34d649f85505176a451a04/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="d6e7f5dc9db7e382ce34d649f85505176a451a04" Add export lists to some modules. Summary: This makes it easier to see what is exported, and allows us to add non-exported top-level names. Reviewers: hvr, austin, ezyang Reviewed By: ezyang Subscribers: ezyang, carter, thomie Projects: #ghc Differential Revision: https://phabricator.haskell.org/D551 GHC Trac Issues: #9852 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 28 07:10:28 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Dec 2014 07:10:28 -0000 Subject: [GHC] #9852: Add missing export lists In-Reply-To: <045.0c137db4833268f838cfd23c79dcf251@haskell.org> References: <045.0c137db4833268f838cfd23c79dcf251@haskell.org> Message-ID: <060.0bb0825e2501925b61117d5c804c83b7@haskell.org> #9852: Add missing export lists -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: closed Priority: low | Milestone: 7.12.1 Component: Core | Version: 7.9 Libraries | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D551 | -------------------------------------+------------------------------------- Changes (by hvr): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 28 11:39:58 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Dec 2014 11:39:58 -0000 Subject: [GHC] #9900: Support pattern synonyms in GHCi In-Reply-To: <045.62d6509e4b0cfc58e8f6254c0f951369@haskell.org> References: <045.62d6509e4b0cfc58e8f6254c0f951369@haskell.org> Message-ID: <060.ec868cd29a2c17870afb3232b5b058b3@haskell.org> #9900: Support pattern synonyms in GHCi -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: GHCi | Version: 7.8.3 Resolution: | Keywords: PatternSynonyms Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: 9915 rejects valid program | Related Tickets: #8749, #7253 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Dr. ERDI Gergo ): In [changeset:"0cc0cc8688ddb53db65a73d7d562e9564cfad22b/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="0cc0cc8688ddb53db65a73d7d562e9564cfad22b" Support pattern synonyms in GHCi (fixes #9900) This involves recognizing lines starting with `"pattern "` as declarations, keeping non-exported pattern synonyms in `deSugar`, and including pattern synonyms in the result of `hscDeclsWithLocation`. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 28 11:40:26 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Dec 2014 11:40:26 -0000 Subject: [GHC] #9900: Support pattern synonyms in GHCi In-Reply-To: <045.62d6509e4b0cfc58e8f6254c0f951369@haskell.org> References: <045.62d6509e4b0cfc58e8f6254c0f951369@haskell.org> Message-ID: <060.a1d8592b2a108b960578d7ef04dd7775@haskell.org> #9900: Support pattern synonyms in GHCi -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: bug | Status: merge Priority: normal | Milestone: 7.10.1 Component: GHCi | Version: 7.8.3 Resolution: | Keywords: PatternSynonyms Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: 9915 rejects valid program | Related Tickets: #8749, #7253 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by cactus): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 28 16:17:35 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Dec 2014 16:17:35 -0000 Subject: [GHC] #9524: GHC uses wrong linker when cross compiling In-Reply-To: <049.96f062346f8aab14c3c1ff251a788093@haskell.org> References: <049.96f062346f8aab14c3c1ff251a788093@haskell.org> Message-ID: <064.8015611c1974d87873c3790ffbca0b5a@haskell.org> #9524: GHC uses wrong linker when cross compiling -------------------------------------+------------------------------------- Reporter: Kritzefitz | Owner: rwbarton Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.8.4 System | Keywords: Cross compiling Resolution: | Architecture: x86 Operating System: Linux | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): It looks like a different bug (probably of the same type) so please open another ticket, thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 28 16:48:56 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Dec 2014 16:48:56 -0000 Subject: [GHC] #9932: GHC fails to build when cross compiling for mingw with the message "Threads not supported" Message-ID: <049.e487d99eeb784ebf45e20f30dbd986d2@haskell.org> #9932: GHC fails to build when cross compiling for mingw with the message "Threads not supported" -------------------------------------+------------------------------------- Reporter: Kritzefitz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.4 Keywords: Cross compiling | Operating System: Linux Architecture: x86 | Type of failure: Building Difficulty: Unknown | GHC failed Blocked By: | Test Case: Related Tickets: 9542 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I'm trying to build a mingw32 cross compiler. I configured with `./configure --target=x86_64-x64-mingw32`, then I built with `make -j 1`. The build then fails with the message ` # error "Threads not supported"` followed by some other errors. (The last part of the make log is attached) To bypass #9542, I deleted the following lines from utils/hsc2hs/Main.hs: {{{ #if defined(__GLASGOW_HASKELL__) && !defined(BUILD_NHC) #include "../../includes/ghcconfig.h" #endif }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 28 16:51:18 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Dec 2014 16:51:18 -0000 Subject: [GHC] #9524: GHC uses wrong linker when cross compiling In-Reply-To: <049.96f062346f8aab14c3c1ff251a788093@haskell.org> References: <049.96f062346f8aab14c3c1ff251a788093@haskell.org> Message-ID: <064.1c31588e0137dafa9bdef5b6898e649e@haskell.org> #9524: GHC uses wrong linker when cross compiling -------------------------------------+------------------------------------- Reporter: Kritzefitz | Owner: rwbarton Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.8.4 System | Keywords: Cross compiling Resolution: | Architecture: x86 Operating System: Linux | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Kritzefitz): done: #9932 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 29 00:23:08 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Dec 2014 00:23:08 -0000 Subject: [GHC] #9895: No -mtriple param being passed to opt/llc when cross compiling In-Reply-To: <044.a3f80c6c0a5d3377f5d023665058edc9@haskell.org> References: <044.a3f80c6c0a5d3377f5d023665058edc9@haskell.org> Message-ID: <059.ed51ee07686701ee52a45a638f51064c@haskell.org> #9895: No -mtriple param being passed to opt/llc when cross compiling -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: feature | Status: patch request | Milestone: 7.12.1 Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D576 | -------------------------------------+------------------------------------- Comment (by Erik de Castro Lopo ): In [changeset:"58ac9c8f6e986bac817ad08d5a2fd11cd167f029/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="58ac9c8f6e986bac817ad08d5a2fd11cd167f029" LlvmCodeGen cross-compiling fixes (#9895) Summary: * Throw an error when cross-compiling without a target definition. When cross compiling via LLVM, a target 'datalayout' and 'triple' must be defined or LLVM will generate code for the compile host instead of the compile target. * Add aarch64-unknown-linux-gnu target. The datalayout and triple lines were found by using clang to compile a small C program and -emit-llvm to get the LLVM IR output. Signed-off-by: Erik de Castro Lopo Test Plan: validate Reviewers: rwbarton, carter, hvr, bgamari, austin Reviewed By: austin Subscribers: carter, thomie, garious Differential Revision: https://phabricator.haskell.org/D585 GHC Trac Issues: #9895 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 29 02:49:02 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Dec 2014 02:49:02 -0000 Subject: =?utf-8?q?=5BGHC=5D_=239933=3A_Cross-compile_failure_=3A_Not_in_?= =?utf-8?b?c2NvcGU6IOKAmGdjZEludCfigJk=?= Message-ID: <044.5fbd4764d2309354b240e8b3ffabc8d1@haskell.org> #9933: Cross-compile failure : Not in scope: ?gcdInt'? -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Building Blocked By: | GHC failed Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- When cross-compiling from x86_64-linux to armhf-linux using the `quick- cross` setting from `mk/build.mk.sample` I get: {{{ libraries/base/GHC/Real.hs:28:25: Not in scope: ?gcdInt'? libraries/base/GHC/Real.hs:28:34: Not in scope: ?gcdWord'? }}} It turns out these functions are exported un-conditionally but are only defined within an `#ifdef`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 29 03:13:15 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Dec 2014 03:13:15 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=239933=3A_Cross-compile_failure_=3A_N?= =?utf-8?b?b3QgaW4gc2NvcGU6IOKAmGdjZEludCfigJk=?= In-Reply-To: <044.5fbd4764d2309354b240e8b3ffabc8d1@haskell.org> References: <044.5fbd4764d2309354b240e8b3ffabc8d1@haskell.org> Message-ID: <059.ed3c2cc70ad6050a4b20a1d8b02b407a@haskell.org> #9933: Cross-compile failure : Not in scope: ?gcdInt'? -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: Core | Version: 7.11 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D598 | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch * cc: core-libraries-committee@? (added) * differential: => Phab:D598 * component: Compiler => Core Libraries * difficulty: Unknown => Easy (less than 1 hour) * milestone: => 7.12.1 Comment: Whoops! That one's my fault. I'm on it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 29 05:49:57 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Dec 2014 05:49:57 -0000 Subject: [GHC] #9934: Typo in GHC.RTS.Flags Message-ID: <050.0ec040db1f00688d5b940ce1d03caaea@haskell.org> #9934: Typo in GHC.RTS.Flags -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.1-rc1 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: Other hour) | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Currently, the {{{GCFlags}}} data type in the {{{GHC.RTS.Flags}}} module of {{{base-4.8.0.0}}} has a field named {{{heapSizeSuggesionAuto}}} (without a {{{t}}} in {{{Suggesion}}}). Given that the corresponding struct field in {{{rts/Flags.h}}} is named {{{heapSizeSuggestionAuto}}}, this is probably a typo. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 29 06:55:22 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Dec 2014 06:55:22 -0000 Subject: [GHC] #9935: Can't compile rts/StgCRun.c for aarch64-linux Message-ID: <044.200c17fd365ff41cdf84e3ad7b9ecbc2@haskell.org> #9935: Can't compile rts/StgCRun.c for aarch64-linux ----------------------------+---------------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Linux Architecture: Other | Type of failure: Building GHC failed Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------+---------------------------------------------- When cross-compiling from x86_64-linux to aarch64-linux I get: {{{ rts/StgCRun.c: In function ?StgRun?: rts/StgCRun.c:756:5: error: unknown register name ?%lr? in ?asm? __asm__ volatile ( }}} It seems the asm code here is for iOS and does not work for Linux. Have a patch in progress. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 29 08:14:33 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Dec 2014 08:14:33 -0000 Subject: [GHC] #9934: Typo in GHC.RTS.Flags In-Reply-To: <050.0ec040db1f00688d5b940ce1d03caaea@haskell.org> References: <050.0ec040db1f00688d5b940ce1d03caaea@haskell.org> Message-ID: <065.97bf4e9a65574c13cc0cd7db0f38fcd0@haskell.org> #9934: Typo in GHC.RTS.Flags -------------------------------------+------------------------------------- Reporter: | Owner: RyanGlScott | Status: new Type: bug | Milestone: Priority: normal | Version: 7.10.1-rc1 Component: | Keywords: libraries/base | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: Other | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"40561cd235f07d41904d2604ff7f0c942af4d35e/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="40561cd235f07d41904d2604ff7f0c942af4d35e" Fix `heapSizeSuggesionAuto` typo (#9934) This was introduced in 1617a10a (re #5364) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 29 08:14:32 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Dec 2014 08:14:32 -0000 Subject: [GHC] #5364: Access RTS flag values from inside Haskell programs In-Reply-To: <045.dac6fe30423f96742744c66f751179f8@haskell.org> References: <045.dac6fe30423f96742744c66f751179f8@haskell.org> Message-ID: <060.296ced5a2c08a4bbe0bdc3dbba33f077@haskell.org> #5364: Access RTS flag values from inside Haskell programs -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ekmett Type: feature | Status: new request | Milestone: 7.12.1 Priority: normal | Version: 7.3 Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D306 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"40561cd235f07d41904d2604ff7f0c942af4d35e/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="40561cd235f07d41904d2604ff7f0c942af4d35e" Fix `heapSizeSuggesionAuto` typo (#9934) This was introduced in 1617a10a (re #5364) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 29 08:15:33 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Dec 2014 08:15:33 -0000 Subject: [GHC] #9934: Typo in GHC.RTS.Flags In-Reply-To: <050.0ec040db1f00688d5b940ce1d03caaea@haskell.org> References: <050.0ec040db1f00688d5b940ce1d03caaea@haskell.org> Message-ID: <065.a15de2f4dc930af904447a0466830d2e@haskell.org> #9934: Typo in GHC.RTS.Flags -------------------------------------+------------------------------------- Reporter: | Owner: RyanGlScott | Status: merge Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.9 Component: | Keywords: libraries/base | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: Other | Related Tickets: #5364 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by hvr): * status: new => merge * version: 7.10.1-rc1 => 7.9 * related: => #5364 * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 29 08:21:02 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Dec 2014 08:21:02 -0000 Subject: [GHC] #5364: Access RTS flag values from inside Haskell programs In-Reply-To: <045.dac6fe30423f96742744c66f751179f8@haskell.org> References: <045.dac6fe30423f96742744c66f751179f8@haskell.org> Message-ID: <060.71c7025be0f2745ae140859b5bb665bd@haskell.org> #5364: Access RTS flag values from inside Haskell programs -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ekmett Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.3 Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D306 | -------------------------------------+------------------------------------- Changes (by hvr): * milestone: 7.12.1 => 7.10.1 Comment: btw, I noticed that the API exposed by GHC.RTS.Flags varies depending on `unsigned int`: {{{#!hs -- | @'nat'@ defined in @rts/Types.h@ type Nat = #{type unsigned int} data GCFlags = GCFlags { statsFile :: Maybe FilePath , giveStats :: GiveGCStats , maxStkSize :: Nat , initialStkSize :: Nat , stkChunkSize :: Nat ... }}} Is this really a good idea rather simply using `Word` which I assume should always be large enough to contain the range of `CULong`? Moreover, shouldn't most of those small-fields be `!`-ed to avoid thunks and unecessary pointer chasing? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 29 09:12:26 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Dec 2014 09:12:26 -0000 Subject: [GHC] #9847: Remove "Difficulty" field from the Trac In-Reply-To: <048.2f318234beb94b756753871fe44a2045@haskell.org> References: <048.2f318234beb94b756753871fe44a2045@haskell.org> Message-ID: <063.f9684cd6409c46a512c47a633e4d4910@haskell.org> #9847: Remove "Difficulty" field from the Trac -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: closed Priority: normal | Milestone: Component: Trac & Git | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * status: new => closed * resolution: => fixed Comment: I've just removed that field -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 29 09:12:32 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Dec 2014 09:12:32 -0000 Subject: [GHC] #9935: Can't compile rts/StgCRun.c for aarch64-linux In-Reply-To: <044.200c17fd365ff41cdf84e3ad7b9ecbc2@haskell.org> References: <044.200c17fd365ff41cdf84e3ad7b9ecbc2@haskell.org> Message-ID: <059.1eed86a53ebe990cff4d38c89d5cd9f7@haskell.org> #9935: Can't compile rts/StgCRun.c for aarch64-linux ----------------------------------------+---------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------------+---------------------------------- Changes (by erikd): * architecture: Other => aarch64 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 29 09:13:32 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Dec 2014 09:13:32 -0000 Subject: [GHC] #9935: Can't compile rts/StgCRun.c for aarch64-linux In-Reply-To: <044.200c17fd365ff41cdf84e3ad7b9ecbc2@haskell.org> References: <044.200c17fd365ff41cdf84e3ad7b9ecbc2@haskell.org> Message-ID: <059.06f39fb3df17b33706f9e7e1950c7d4f@haskell.org> #9935: Can't compile rts/StgCRun.c for aarch64-linux ----------------------------------------+---------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: D599 ----------------------------------------+---------------------------------- Changes (by erikd): * differential: => D599 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 29 09:17:44 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Dec 2014 09:17:44 -0000 Subject: [GHC] #9935: Can't compile rts/StgCRun.c for aarch64-linux In-Reply-To: <044.200c17fd365ff41cdf84e3ad7b9ecbc2@haskell.org> References: <044.200c17fd365ff41cdf84e3ad7b9ecbc2@haskell.org> Message-ID: <059.f3e01e09c27caeb0c87b4419d1c2a4b7@haskell.org> #9935: Can't compile rts/StgCRun.c for aarch64-linux ----------------------------------------+---------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: D599 ----------------------------------------+---------------------------------- Description changed by erikd: Old description: > When cross-compiling from x86_64-linux to aarch64-linux I get: > > {{{ > rts/StgCRun.c: In function ?StgRun?: > > rts/StgCRun.c:756:5: > error: unknown register name ?%lr? in ?asm? > __asm__ volatile ( > }}} > > It seems the asm code here is for iOS and does not work for Linux. Have a > patch in progress. New description: When building an x86_64-linux to aarch64-linux cross-compiling I get: {{{ rts/StgCRun.c: In function ?StgRun?: rts/StgCRun.c:756:5: error: unknown register name ?%lr? in ?asm? __asm__ volatile ( }}} It seems the asm code here is for iOS and does not work for Linux. Have a patch in progress. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 29 14:58:04 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Dec 2014 14:58:04 -0000 Subject: [GHC] #9936: Data.Fixed truncates 5.17 to 5.16 Message-ID: <049.6b8f69f5357b7d4ed3acd7f2538418ac@haskell.org> #9936: Data.Fixed truncates 5.17 to 5.16 -------------------------------------+------------------------------------- Reporter: singpolyma | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.6.3 libraries/base | Operating System: Unknown/Multiple Keywords: | Type of failure: Incorrect result Architecture: | at runtime Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- `(realToFrac (5.17 :: Double) :: Centi) == 5.16` is true -- it should be false. The offender seems to be the assumption in `fromRational`: `fromRational r = withResolution (\res -> MkFixed (floor (r * (toRational res))))` Uses `floor` assuming that the underlying floating point value is stored purely and not as 0.999999 or similar -- switching it to `round` fixes this issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 29 15:08:01 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Dec 2014 15:08:01 -0000 Subject: [GHC] #9936: Data.Fixed truncates 5.17 to 5.16 In-Reply-To: <049.6b8f69f5357b7d4ed3acd7f2538418ac@haskell.org> References: <049.6b8f69f5357b7d4ed3acd7f2538418ac@haskell.org> Message-ID: <064.4c69759fee0bd7887c6a4376aed9ed4e@haskell.org> #9936: Data.Fixed truncates 5.17 to 5.16 -------------------------------------+------------------------------------- Reporter: singpolyma | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ekmett): #9231 tackles somewhat similar issues. Does the fix there address this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 29 15:08:32 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Dec 2014 15:08:32 -0000 Subject: [GHC] #9936: Data.Fixed truncates 5.17 to 5.16 In-Reply-To: <049.6b8f69f5357b7d4ed3acd7f2538418ac@haskell.org> References: <049.6b8f69f5357b7d4ed3acd7f2538418ac@haskell.org> Message-ID: <064.961bee2cb28e8fb789023738f1cd8aa9@haskell.org> #9936: Data.Fixed truncates 5.17 to 5.16 -------------------------------------+------------------------------------- Reporter: singpolyma | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #9231 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ekmett): * related: => #9231 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 29 15:09:43 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Dec 2014 15:09:43 -0000 Subject: [GHC] #9936: Data.Fixed truncates 5.17 to 5.16 In-Reply-To: <049.6b8f69f5357b7d4ed3acd7f2538418ac@haskell.org> References: <049.6b8f69f5357b7d4ed3acd7f2538418ac@haskell.org> Message-ID: <064.b6d6b1d1c68583cb3083dde2b512b509@haskell.org> #9936: Data.Fixed truncates 5.17 to 5.16 -------------------------------------+------------------------------------- Reporter: singpolyma | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #9231, #9240 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ekmett): * related: #9231 => #9231, #9240 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 29 15:12:53 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Dec 2014 15:12:53 -0000 Subject: [GHC] #9936: Data.Fixed truncates 5.17 to 5.16 In-Reply-To: <049.6b8f69f5357b7d4ed3acd7f2538418ac@haskell.org> References: <049.6b8f69f5357b7d4ed3acd7f2538418ac@haskell.org> Message-ID: <064.2aaaf2c0ac4e5f0f239c514485f672a6@haskell.org> #9936: Data.Fixed truncates 5.17 to 5.16 -------------------------------------+------------------------------------- Reporter: singpolyma | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #9231 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by singpolyma): * related: #9231, #9240 => #9231 Comment: @ekmett the changes there seem to be for reading from string -- this is just in the `fromRational`/`realToFrac` path. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 29 15:16:19 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Dec 2014 15:16:19 -0000 Subject: [GHC] #9936: Data.Fixed truncates 5.17 to 5.16 In-Reply-To: <049.6b8f69f5357b7d4ed3acd7f2538418ac@haskell.org> References: <049.6b8f69f5357b7d4ed3acd7f2538418ac@haskell.org> Message-ID: <064.063a302ddd0e9b810b7dbc6ff1585c4b@haskell.org> #9936: Data.Fixed truncates 5.17 to 5.16 -------------------------------------+------------------------------------- Reporter: singpolyma | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #9231, #9240 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by singpolyma): * related: #9231 => #9231, #9240 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 29 15:24:12 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Dec 2014 15:24:12 -0000 Subject: [GHC] #9936: Data.Fixed truncates 5.17 to 5.16 In-Reply-To: <049.6b8f69f5357b7d4ed3acd7f2538418ac@haskell.org> References: <049.6b8f69f5357b7d4ed3acd7f2538418ac@haskell.org> Message-ID: <064.fc89d439057166c7827d7fff42fd7c5f@haskell.org> #9936: Data.Fixed truncates 5.17 to 5.16 -------------------------------------+------------------------------------- Reporter: singpolyma | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #9231, #9240 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): Replying to [comment:1 ekmett]: > #9231 & #9240 tackle somewhat similar issues. > > Does the fix there address this? The behavior reported in this ticket still occurs in 7.11. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 29 16:32:16 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Dec 2014 16:32:16 -0000 Subject: [GHC] #9875: ld -l:filename.dylib does not appear to be portable In-Reply-To: <045.5761a7e104bd5de24e048bce5dd70a34@haskell.org> References: <045.5761a7e104bd5de24e048bce5dd70a34@haskell.org> Message-ID: <060.b04cd6ca205721c84529898091b9c883@haskell.org> #9875: ld -l:filename.dylib does not appear to be portable -------------------------------+------------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.10.1 Component: GHCi | Version: 7.9 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: T2276_ghci Blocked By: | Blocking: 9845 Related Tickets: | Differential Revisions: Phab:D579 -------------------------------+------------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"b32c22760687a6a1a2e88fdba8de32f6951b5029/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="b32c22760687a6a1a2e88fdba8de32f6951b5029" Fix system linker on Mac OS X Summary: Flag `-l:` is GNU ld specific and not supported by the Mac OS X link editor. So we create a temporary file name lib. and link with the standard -l option on Linux and OS X. Fixes #9875 Test Plan: validate on Mac OS X Reviewers: austin, hvr, ezyang Reviewed By: ezyang Subscribers: carter, thomie, ezyang Differential Revision: https://phabricator.haskell.org/D579 GHC Trac Issues: #9875 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 29 16:34:04 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Dec 2014 16:34:04 -0000 Subject: [GHC] #9875: ld -l:filename.dylib does not appear to be portable In-Reply-To: <045.5761a7e104bd5de24e048bce5dd70a34@haskell.org> References: <045.5761a7e104bd5de24e048bce5dd70a34@haskell.org> Message-ID: <060.3521c54560438b0f47cc17ec9e64ad99@haskell.org> #9875: ld -l:filename.dylib does not appear to be portable -------------------------------+------------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: merge Priority: high | Milestone: 7.10.1 Component: GHCi | Version: 7.9 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: T2276_ghci Blocked By: | Blocking: 9845 Related Tickets: | Differential Revisions: Phab:D579 -------------------------------+------------------------------------------- Changes (by ezyang): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 29 17:35:07 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Dec 2014 17:35:07 -0000 Subject: [GHC] #9937: add updated prefetch API mention to the 7.10 release notes Message-ID: <045.aae52c0ceb53669bf5d53bc76be3d55f@haskell.org> #9937: add updated prefetch API mention to the 7.10 release notes -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 29 17:35:44 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Dec 2014 17:35:44 -0000 Subject: [GHC] #9937: add updated prefetch API mention to the 7.10 release notes In-Reply-To: <045.aae52c0ceb53669bf5d53bc76be3d55f@haskell.org> References: <045.aae52c0ceb53669bf5d53bc76be3d55f@haskell.org> Message-ID: <060.725b3f3a7bde18d4f5cdd365e6c9d8ed@haskell.org> #9937: add updated prefetch API mention to the 7.10 release notes -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by carter): * failure: None/Unknown => Documentation bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 29 17:58:59 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Dec 2014 17:58:59 -0000 Subject: [GHC] #9049: Expose srcLoc from the assertion architecture to allow better error messages In-Reply-To: <042.a0d4c757be085a0284ebca147547b4f3@haskell.org> References: <042.a0d4c757be085a0284ebca147547b4f3@haskell.org> Message-ID: <057.98963d672080332f6a5835445fce0ff6@haskell.org> #9049: Expose srcLoc from the assertion architecture to allow better error messages -------------------------------------+------------------------------------- Reporter: nh2 | Owner: gridaphobe Type: feature request | Status: patch Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D578 -------------------------------------+------------------------------------- Changes (by gridaphobe): * milestone: => 7.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 29 18:17:36 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Dec 2014 18:17:36 -0000 Subject: [GHC] #9918: GHC chooses an instance between two overlapping, but cannot resolve a clause within the similar closed type family In-Reply-To: <045.8b42c360bfa608017b9b2986029ca51e@haskell.org> References: <045.8b42c360bfa608017b9b2986029ca51e@haskell.org> Message-ID: <060.520d101878515002237863653d466bd5@haskell.org> #9918: GHC chooses an instance between two overlapping, but cannot resolve a clause within the similar closed type family -------------------------------------+------------------------------------- Reporter: qnikst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Thanks for the examples in comment:7. The first example can show up the very problem I was looking for! Consider this alternate ending to the first example there (which also needs `ScopedTypeVariables`): {{{ type family Inf x where Inf () = S (Inf ()) -- pattern-match on () avoids an eager occurs- check test2 (_ :: x) = test (undefined :: Inf x) -- test2 :: x -> Int main = test2 () }}} This will, of course, evaluate to `2`. But it arguably shouldn't, because `main` boils down to a comparison between `S (S (Inf ()))` and `Inf ()`, which is impossible to determine. The extra constraint that appears in the second example (the one with closed type families) essentially says that the two type-level numbers have a well-defined relationship. When infinity is involved, they don't, giving more reliable behavior (in extreme, perverse circumstances, admittedly). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 29 18:28:47 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Dec 2014 18:28:47 -0000 Subject: [GHC] #9938: cryptarithm2 fails with undefined reference to `transzuH9c1w14lEUN3zzdWCTsn8jG_ControlziMonadziTransziStateziLazzy_zdwzdcp0Alternative_info' Message-ID: <046.d5e03a3504491fde407beb1d28307afd@haskell.org> #9938: cryptarithm2 fails with undefined reference to `transzuH9c1w14lEUN3zzdWCTsn8jG_ControlziMonadziTransziStateziLazzy_zdwzdcp0Alternative_info' -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- I am observing this right now: {{{ ==nofib== cryptarithm2: size of Main.o follows... text data bss dec hex filename 25423 1304 0 26727 6867 Main.o ==nofib== cryptarithm2: time to link cryptarithm2 follows... Main.o: In Funktion `c79k_info': (.text+0x1a5b): Nicht definierter Verweis auf `transzuH9c1w14lEUN3zzdWCTsn8jG_ControlziMonadziTransziStateziLazzy_zdwzdcp0Alternative_info' Main.o: In Funktion `c7cP_info': (.text+0x2283): Nicht definierter Verweis auf `transzuH9c1w14lEUN3zzdWCTsn8jG_ControlziMonadziTransziStateziLazzy_zdwzdcp0Alternative_info' Main.o: In Funktion `c7ll_info': (.text+0x2f53): Nicht definierter Verweis auf `transzuH9c1w14lEUN3zzdWCTsn8jG_ControlziMonadziTransziStateziLazzy_zdwzdcp0Alternative_info' Main.o: In Funktion `c7p2_info': (.text+0x37cb): Nicht definierter Verweis auf `transzuH9c1w14lEUN3zzdWCTsn8jG_ControlziMonadziTransziStateziLazzy_zdwzdcp0Alternative_info' collect2: error: ld returned 1 exit status <> make[2]: *** [cryptarithm2] Fehler 1 Failed making all in cryptarithm2: 1 make[1]: *** [all] Fehler 1 Failed making all in spectral: 1 make: *** [all] Fehler 1 make: Verlasse Verzeichnis '/data1/ghc-builder/logs/ghc-tmp-REV/nofib' }}} Trying to minimize the problem, I came up with this file: {{{ module Main where import Control.Monad import Control.Monad.Trans.State solve :: Int -> StateT () [] () solve carry | carry > 0 = do guard (0 == carry) solve (carry -1) solve 0 = mzero main :: IO () main = return () }}} It only occurs when using this sequence (I?m also pasting the DEBUG output, in case it is useful): {{{ $ /home/jojo/build/haskell/ghc/inplace/bin/ghc-stage2 -O2 -c Main.hs WARNING: file compiler/specialise/Specialise.hs, line 677 specImport discarding: $w$cmany :: forall s_a1an (m_a1ao :: * -> *). MonadPlus m_a1ao => forall a_a1ap. StateT s_a1an m_a1ao a_a1ap -> StateT s_a1an m_a1ao [a_a1ap] want: False stable: False calls: $w$cmany _ @ [] $fMonadPlus[] WARNING: file compiler/specialise/Specialise.hs, line 677 specImport discarding: $w$csome :: forall s_a1ax (m_a1ay :: * -> *). MonadPlus m_a1ay => forall a_a1az. StateT s_a1ax m_a1ay a_a1az -> StateT s_a1ax m_a1ay [a_a1az] want: False stable: False calls: $w$csome _ @ [] $fMonadPlus[] WARNING: file compiler/specialise/Specialise.hs, line 677 specImport discarding: $w$cp0Alternative :: forall s_a1aT (m_a1aU :: * -> *). MonadPlus m_a1aU => (# Functor (StateT s_a1aT m_a1aU), forall a_a1aV. a_a1aV -> StateT s_a1aT m_a1aU a_a1aV, forall a_a1aW b_a1aX. StateT s_a1aT m_a1aU (a_a1aW -> b_a1aX) -> StateT s_a1aT m_a1aU a_a1aW -> StateT s_a1aT m_a1aU b_a1aX, forall a_a1aY b_a1aZ. StateT s_a1aT m_a1aU a_a1aY -> StateT s_a1aT m_a1aU b_a1aZ -> StateT s_a1aT m_a1aU b_a1aZ, forall a_a1b0 b_a1b1. StateT s_a1aT m_a1aU a_a1b0 -> StateT s_a1aT m_a1aU b_a1b1 -> StateT s_a1aT m_a1aU a_a1b0 #) want: False stable: False calls: $w$cp0Alternative _ @ [] $fMonadPlus[] WARNING: file compiler/specialise/Specialise.hs, line 1093 Missed specialisation opportunity for $fMonadStateT_$c>> [] 2 [] 1 [ALWAYS] $ /home/jojo/build/haskell/ghc/inplace/bin/ghc-stage2 -O2 -o cryptarithm2 Main.o Main.o: In function `r3He_info': (.text+0x52): undefined reference to `transzuH9c1w14lEUN3zzdWCTsn8jG_ControlziMonadziTransziStateziLazzy_zdwzdcp0Alternative_info' collect2: error: ld returned 1 exit status }}} It works fine if I compile directly using {{{ $ /home/jojo/build/haskell/ghc/inplace/bin/ghc-stage2 -O2 -o cryptarithm2 Main.hs }}} Changing the order of the cases in `solve` also makes the problem go away. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 29 18:38:02 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Dec 2014 18:38:02 -0000 Subject: [GHC] #9938: cryptarithm2 fails with undefined reference to `transzuH9c1w14lEUN3zzdWCTsn8jG_ControlziMonadziTransziStateziLazzy_zdwzdcp0Alternative_info' In-Reply-To: <046.d5e03a3504491fde407beb1d28307afd@haskell.org> References: <046.d5e03a3504491fde407beb1d28307afd@haskell.org> Message-ID: <061.7c27278d89c084ab18635b360906987e@haskell.org> #9938: cryptarithm2 fails with undefined reference to `transzuH9c1w14lEUN3zzdWCTsn8jG_ControlziMonadziTransziStateziLazzy_zdwzdcp0Alternative_info' -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"65e3e0b2ce125b906efca129c92673fc40cf79f6/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="65e3e0b2ce125b906efca129c92673fc40cf79f6" Test case for #9938 Marked as known_broken }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 29 20:24:13 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Dec 2014 20:24:13 -0000 Subject: [GHC] #7788: Recursive type family causes <> In-Reply-To: <046.ea3ef9ceaabda348ee27e147f6e7ebb3@haskell.org> References: <046.ea3ef9ceaabda348ee27e147f6e7ebb3@haskell.org> Message-ID: <061.4af30cca686714b4e296d0426a3ed802@haskell.org> #7788: Recursive type family causes <> -------------------------------------+------------------------------------- Reporter: shachaf | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.6.2 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by goldfire): Here's what I'm worried about here. This function is clearly very innocent: {{{ id :: a -> a id x = x }}} It compiles, obviously, without complaint. But, with 7.10, the following doesn't: {{{ type family F a where F a = F a id2 :: F a -> F a id2 x = x }}} This is slightly disturbing because `id2` is merely a specialization of `id`. I think there is an easy solution here, though: allow users to disable the optimisation that we've put into !TcFlatten (`try_to_reduce`). If a user says `-flazier-type-families`, then we turn off the optimization. Most type-family-heavy programs will simply compile much more slowly... but a few will compile in finite time that didn't previously. As a separate solution here, we probably should also detect when we're looping while evaluating a type family by tracking evaluation depth. I'd much rather get an error saying we've blown a limited stack size than to just loop. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 30 01:49:30 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Dec 2014 01:49:30 -0000 Subject: [GHC] #9939: Warn for duplicate superclass constraints Message-ID: <047.cbb3a535ba98b12eaa610d54289e6f43@haskell.org> #9939: Warn for duplicate superclass constraints -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- With the following code, GHC warns that there are duplicate constraints: {{{#!hs {-# LANGUAGE FlexibleInstances, UndecidableInstances #-} module Foo where class Foo a where foo :: Int -> a instance (Integral a, Integral a) => Foo a where foo x = (fromIntegral x) `div` 2 }}} However, when writing the code, I might start with: {{{#!hs {-# LANGUAGE FlexibleInstances, UndecidableInstances #-} module Foo where class Foo a where foo :: Int -> a instance Foo a where foo x = (fromIntegral x) `div` 2 }}} without any constraints on the instance. GHC complains that it needs `Num a` and `Integral a`, but of course `Num` is implied by `Integral`. I'm ''not'' asking that GHC figure this out on its own and only request the strongest constraint necessary. Rather, I'm suggesting that ''if'' I followed GHC's suggestion and wrote {{{#!hs {-# LANGUAGE FlexibleInstances, UndecidableInstances #-} module Foo where class Foo a where foo :: Int -> a instance (Num a, Integral a) => Foo a where foo x = (fromIntegral x) `div` 2 }}} then GHC should warn {{{ Duplicate constraint(s): Num a In the context: (Num a, Integral a) (Num a) is implied by (Integral a) }}} or something similar. The motivation for this feature request is that in large instances/programs, it is difficult for a human to keep track of superclasses. In large instances, GHC tends to request "weak" constraints first (say `Num`), then ask for progressively stronger constraints (say `Integral`). Again, I'm not suggesting that behavior should change. However, it tends to lead to instances that look like `(Num a, Real a, RealFrac a, RealFloat a) => ...` if by chance I happened to use methods from each class. It seems fairly simple for GHC to look at each constraint for an instance (or function), trace back up the class hierarchy to get a set of all implied constraints, and then warn if one set is a subset of another. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 30 02:22:07 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Dec 2014 02:22:07 -0000 Subject: [GHC] #9938: cryptarithm2 fails with undefined reference to `transzuH9c1w14lEUN3zzdWCTsn8jG_ControlziMonadziTransziStateziLazzy_zdwzdcp0Alternative_info' In-Reply-To: <046.d5e03a3504491fde407beb1d28307afd@haskell.org> References: <046.d5e03a3504491fde407beb1d28307afd@haskell.org> Message-ID: <061.35825a0997515dbdf520e5e0fed8d7e6@haskell.org> #9938: cryptarithm2 fails with undefined reference to `transzuH9c1w14lEUN3zzdWCTsn8jG_ControlziMonadziTransziStateziLazzy_zdwzdcp0Alternative_info' -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): I'm confused, isn't your minimized test case showing the expected behavior? GHC doesn't really know what's in `Main.o` and that it needs to link against transformers, so you have to specify `-package transformers` at link time. I don't understand how changing the order of the cases in `solve` could affect anything, and I also can't reproduce it here. Not sure what is going on with cryptarithm2 then, did it somehow gain a link-time dependency on transformers (whereas previously, perhaps, all the functions in transformers had been inlined)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 30 09:58:43 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Dec 2014 09:58:43 -0000 Subject: [GHC] #9508: Rename package key In-Reply-To: <045.9321326ff6fd1cf354acf4ce2c70bc86@haskell.org> References: <045.9321326ff6fd1cf354acf4ce2c70bc86@haskell.org> Message-ID: <060.233f1a37dc9c9d93190343047f08eaf6@haskell.org> #9508: Rename package key -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): I'd be happy to leave it as-is: see comment:3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 30 09:59:25 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Dec 2014 09:59:25 -0000 Subject: [GHC] #9243: Recompilation avoidance doesn't work for -fno-code/-fwrite-interface In-Reply-To: <045.eb0d37b8e28f9b0d21ba7b721e124a6b@haskell.org> References: <045.eb0d37b8e28f9b0d21ba7b721e124a6b@haskell.org> Message-ID: <060.2f7e8b3ac4e2032df3ceca7fc8ca52c8@haskell.org> #9243: Recompilation avoidance doesn't work for -fno-code/-fwrite-interface -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: patch Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D596 -------------------------------------+------------------------------------- Changes (by simonpj): * differential: D596 => Phab:D596 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 30 10:11:27 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Dec 2014 10:11:27 -0000 Subject: [GHC] #9722: ghcirun004 intermittently fails with ghc: ioManagerWakeup: write: Bad file descriptor In-Reply-To: <045.2ac77d27a9a71df853ff4839dd3c18d0@haskell.org> References: <045.2ac77d27a9a71df853ff4839dd3c18d0@haskell.org> Message-ID: <060.1184f6934260058376db7229426a1def@haskell.org> #9722: ghcirun004 intermittently fails with ghc: ioManagerWakeup: write: Bad file descriptor -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: GHCi | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: ghcirun004 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): I haven't seen it recently either. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 30 10:39:28 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Dec 2014 10:39:28 -0000 Subject: [GHC] #9938: cryptarithm2 fails with undefined reference to `transzuH9c1w14lEUN3zzdWCTsn8jG_ControlziMonadziTransziStateziLazzy_zdwzdcp0Alternative_info' In-Reply-To: <046.d5e03a3504491fde407beb1d28307afd@haskell.org> References: <046.d5e03a3504491fde407beb1d28307afd@haskell.org> Message-ID: <061.8a843db9cffcf564fdc73884170412ba@haskell.org> #9938: cryptarithm2 fails with undefined reference to `transzuH9c1w14lEUN3zzdWCTsn8jG_ControlziMonadziTransziStateziLazzy_zdwzdcp0Alternative_info' -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"9521a58a5f3ca38a0bde8b67be00a74e5fc3ccea/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="9521a58a5f3ca38a0bde8b67be00a74e5fc3ccea" Refine test case for #9938 By passing -O2, the bug appears depending on the order of clauses in "solve", hence adding T9938B as the other variant. Currently, T9938 is marked as broken, but maybe the bug is actually in T9938B, where something (possibly inlining, as suggested by rwbarton) affected the requirement to link against transformers. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 30 10:40:34 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Dec 2014 10:40:34 -0000 Subject: [GHC] #9938: cryptarithm2 fails with undefined reference to `transzuH9c1w14lEUN3zzdWCTsn8jG_ControlziMonadziTransziStateziLazzy_zdwzdcp0Alternative_info' In-Reply-To: <046.d5e03a3504491fde407beb1d28307afd@haskell.org> References: <046.d5e03a3504491fde407beb1d28307afd@haskell.org> Message-ID: <061.ec7d87a97a3383226724ad26034aed01@haskell.org> #9938: cryptarithm2 fails with undefined reference to `transzuH9c1w14lEUN3zzdWCTsn8jG_ControlziMonadziTransziStateziLazzy_zdwzdcp0Alternative_info' -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): > I don't understand how changing the order of the cases in solve could affect anything, and I also can't reproduce it here. Right, I can?t either. But when I pass `-O2`, I can! I added the other variant as a separate test case. Maybe the successful compilation of that is the bug? I hope that successful linking should not depend on the particular optimizations that went through. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 30 11:04:15 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Dec 2014 11:04:15 -0000 Subject: [GHC] #9936: Data.Fixed truncates 5.17 to 5.16 In-Reply-To: <049.6b8f69f5357b7d4ed3acd7f2538418ac@haskell.org> References: <049.6b8f69f5357b7d4ed3acd7f2538418ac@haskell.org> Message-ID: <064.9c9ebc3cba4fd1bc1290cea77604413e@haskell.org> #9936: Data.Fixed truncates 5.17 to 5.16 -------------------------------------+------------------------------------- Reporter: singpolyma | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #9231, #9240 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): It sounds as if the fix is simple. It would be great if someone wanted to offer a patch for this, with enough comments to explain the subtlety. Thanks! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 30 11:26:54 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Dec 2014 11:26:54 -0000 Subject: [GHC] #9918: GHC chooses an instance between two overlapping, but cannot resolve a clause within the similar closed type family In-Reply-To: <045.8b42c360bfa608017b9b2986029ca51e@haskell.org> References: <045.8b42c360bfa608017b9b2986029ca51e@haskell.org> Message-ID: <060.a1197a863eedaf055320db4f6cb1b53e@haskell.org> #9918: GHC chooses an instance between two overlapping, but cannot resolve a clause within the similar closed type family -------------------------------------+------------------------------------- Reporter: qnikst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): I conclude from this thread that * `OverlappingInstances` should probably obey the same rules as closed type families, for consistency. * But then both Oleg's versions would be rejected * "A foolish consistency is the hobgoblin of little minds". But there is a reason for the consistency, namely that we know that type inference might become unpredictable (i.e. succeed on Tuesday but fail on Friday, because of some difference in the order in which the solver solves constraints) if we allowed the more flexible form. * We don't yet know if there is any way to accept the programs Oleg wants (or something like them) without allowing unpredictability to slip in too. I suppose that we could lift the restriction (ie strengthen the "surely- apart" check) if some flag is set: * I believe that the unpredictability only strikes if you have infinite types, via a looping type family. And a programmer might well be willing to guaranteed that will not occur. * In that sense, it's a bit like `-XUndecidableInstances`: the programmer takes responsibility. * And, as such it should probably be a per-type-family (or per-closed- type-family) pragma, rather than a global flag. Maybe even `{-# UNDECIDABLE #-}`. I'd like to work this out; the inconsistency between overlappping instances and type families is troubling. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 30 11:41:44 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Dec 2014 11:41:44 -0000 Subject: [GHC] #9918: GHC chooses an instance between two overlapping, but cannot resolve a clause within the similar closed type family In-Reply-To: <045.8b42c360bfa608017b9b2986029ca51e@haskell.org> References: <045.8b42c360bfa608017b9b2986029ca51e@haskell.org> Message-ID: <060.d5510feb9cac669cc0628fb4d89eda6f@haskell.org> #9918: GHC chooses an instance between two overlapping, but cannot resolve a clause within the similar closed type family -------------------------------------+------------------------------------- Reporter: qnikst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by qnikst): Replying to [comment:10 simonpj]: Taking into account that this undecidability is used for purpose in number of libraries, (regions and hlists first comes into my mind, but there should be others) it worth to have a way to have this undecidability even in case if strenghtened "surely- apart" check will be used by default. And definitely this change will introduce some level of breakage in libraries. If "sulery-apart" check will be strengthened then `{-# UNDECIDABLE Foo #-}` solution looks very nice. And of cause per-type-family it looks much better (in the same sense as `XOverlappingInstances` that were deprecated in favor of `{-# OVERLAPPABLE #-}` pragma). And as far as I understand then in order to reach consistency it should be possible to use this pragma with closed type families and as a result first program will be accepted? In this case solution will be very good for me, as it will have a consistency by default and allow to switch from OverlappingInstances to closed type families in our case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 30 11:44:22 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Dec 2014 11:44:22 -0000 Subject: [GHC] #9938: GHC's link step needs to be told which packages to link (was: cryptarithm2 fails with undefined reference to `transzuH9c1w14lEUN3zzdWCTsn8jG_ControlziMonadziTransziStateziLazzy_zdwzdcp0Alternative_info') In-Reply-To: <046.d5e03a3504491fde407beb1d28307afd@haskell.org> References: <046.d5e03a3504491fde407beb1d28307afd@haskell.org> Message-ID: <061.936c117db9f7d2d631d9324cbb250d1f@haskell.org> #9938: GHC's link step needs to be told which packages to link -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Replying to [comment:4 nomeata]: > I hope that successful linking should not depend on the particular optimizations that went through. I'm afraid I suspect it does! * When compiling a source module, GHC can find imports from any exposed packages, in this case `transformers`. * But when linking `.o` files, GHC doesn't know which packages to link. So you mus specify on the command line; e.g. `-package transformers`. * If you inline enough things so that there are no remaining references to things from a package, then you don't need to include that package in the link command. This is pretty unusual. The Right Thing is, I guess, when given a `.o` file on the command line, to read its interface file, to find what packages it needs, and include those in any link step. Patch welcome! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 30 11:52:22 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Dec 2014 11:52:22 -0000 Subject: [GHC] #7788: Recursive type family causes <> In-Reply-To: <046.ea3ef9ceaabda348ee27e147f6e7ebb3@haskell.org> References: <046.ea3ef9ceaabda348ee27e147f6e7ebb3@haskell.org> Message-ID: <061.eae27ed6e68b0bc2e8b1b78a530e5576@haskell.org> #7788: Recursive type family causes <> -------------------------------------+------------------------------------- Reporter: shachaf | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.6.2 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm all for having an evaluation depth. But I'm cautious about adding a flag. Just saying "lazier" doesn't say much. If we could somehow promise "lazy", for some well-specified meaning of that term, then I'd go for that. But not "disable some implementation optimisation that happens to allow one program (that one one cares about) to typecheck". Currently we flatten type-function applications, and reduce them aggressively. I think it's pretty odd that `id2` typechecks with the optimisation disabled; I strongly suspect that a simple variant will not. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 30 12:07:23 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Dec 2014 12:07:23 -0000 Subject: [GHC] #9918: GHC chooses an instance between two overlapping, but cannot resolve a clause within the similar closed type family In-Reply-To: <045.8b42c360bfa608017b9b2986029ca51e@haskell.org> References: <045.8b42c360bfa608017b9b2986029ca51e@haskell.org> Message-ID: <060.5e35abbe654b5b9f480121b86d51e0dc@haskell.org> #9918: GHC chooses an instance between two overlapping, but cannot resolve a clause within the similar closed type family -------------------------------------+------------------------------------- Reporter: qnikst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): OK. Let's see what Richard and Oleg think. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 30 13:30:36 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Dec 2014 13:30:36 -0000 Subject: [GHC] #9922: Partial type signatures + extensions panic In-Reply-To: <047.bcb93dee275eec47e30ed9673a9b0d12@haskell.org> References: <047.bcb93dee275eec47e30ed9673a9b0d12@haskell.org> Message-ID: <062.3711c237bcbb9576ae2469fad365d95c@haskell.org> #9922: Partial type signatures + extensions panic -------------------------------------+------------------------------------- Reporter: monoidal | Owner: thomasw Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.9 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | Blocking: Blocked By: | Differential Revisions: Phab:D595 Related Tickets: | -------------------------------------+------------------------------------- Comment (by simonpj): Austin: let's merge this to 7.10.1. Thomas: I'm not very happy with the way that wild-card error reporting is done. I think we discussed this before, but left it on one side until it was all working. Which it now is. What I suggest is this: Things I dislike: * I dislike the `checkParitalTypeSignature` and `checkNoPartialType` stuff in `RdrHsSyn`. The only checks that belong in `RdrHsSym` are ones that prevent you building a syntax tree at all. All other checks are best done later, when good error reporting is easier, and you can recover from errors. * I particularly hate the `RnTypes.extractWildcards` stuff. It's like a whole extra renaming pass over the type, changing `HsWildCardTy` to `HsNamedWildCardTy` with an `Exact` `RdrName` in it. Yuk! Here is a possible plan: * Remove all the checking from `RdrHsSyn`, unless we can't build a syntax tree without it. * Collapse `HsWildcardTy` and `HsNamedWildcardTy` into one, with a boolean (or a `Named`/`Anonymous` flag) to distinguish. * Provide a specialised version of `rnLHsType`, perhpas `rnLHsTypeWithWildCards`, that does the inital pass to find the named wildcards and bring them into scope. This version is called in the places where you can have a type with wildcards, namely * `TypeSig` * `ExprWithTySig` * `rnHsBndrSig` * `rnLHsTypeWithWildCards` can work like this: 1. Collect all the named wildcards, and bring them into scope. This is a simple, ''pure'' function. 2. Call `rnLHsType`. When `rnLHsType` finds an anonymous wildcard, just make up a fresh name, rather than looking it up. 3. Collect all the wildcards (named or anonymous) to get a `[Name]`; again a pure function 4. Return the renamed type and the wildcard names That makes three passes, but each is simple. In fact (1) and (4) could perhaps be the same function, with a boolean flag to say which wildcards to return. * All this means that when `rnLHsType` is called directly (not via `rnLHsTypeWithWildCards`) on a type like `_ -> Int`, it will succeed, generateing a fresh name for the `_`. That's fine. In `tc_hs_type` we will find it is not in scope, so we can say "Unexpected wildcard in type", and the enclosing location information will nail down the details. * There are, I think, three places where `HsWithBndrs` is used: `HsDecls.HsTyPats`, `HsDecls.RuleBndr`, `HsPat.SigPatIn`. In the latter two I think that wildcards should be legal; in the first not so. (Do you have tests for all three?) So the caller of `rnHsBndrSig` should check for empty wildcards in the cases where there shouldn't be any. I this this is just in type/data family patterns. I have not throught throught the extra-constraints wild card, but I think a similar plan should work. Does this make sense? Might you do it? (To HEAD, of course.) Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 30 13:43:18 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Dec 2014 13:43:18 -0000 Subject: [GHC] #3064: Very long compile times with type functions In-Reply-To: <046.2a7b2611764311f7357001c522d303b9@haskell.org> References: <046.2a7b2611764311f7357001c522d303b9@haskell.org> Message-ID: <061.98bf146cfae8d75270db61bdb905d24a@haskell.org> #3064: Very long compile times with type functions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: low | Milestone: 7.12.1 Component: Compiler (Type | Version: 6.10.1 checker) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | perf/compiler/T3064 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): It may be "a little disappointing" but nevertheless I think it's a notable step forward: * It eliminates a tricky and hard-to-explain complication in the implementation. * It fixes a substantial performance regression that affects programs with deeply-nested superclasses, affecting both compile time and run time. * It eliminates a collection of regressions, whereby silent superclasses actually cause some programs to fail unexpectedly, for very hard-to- explain reasons. They are listed in the commit message. * Moreover, there is no good workaround if you actually hit those regressions. In contrast, there is an immediate and easy workaround if you hit the new regression. * None of this bites you unless you are sailing close to the wind (`UndecidableInstances`). As to whether this belongs in 7.10 I am agnostic. The performance improvements will help everyone slightly (especially in monad-transformer- heavy code). The behaviour change is there all right, but will affect very few people. I don't feel strongly either way. I am not arguing to push it into 7.10, but I will not argue against doing so either. Does anyone else have a view? The default decision is "no" because it is a change wrt RC1. Incidentally, you say "in perverse but realistic scenarios, might cause the superclass dictionary to loop". Indeed it is realistic. It would be all too easy to add by accident {{{ instance (UserOfRegs r CmmExpr) => UserOfRegs r CmmReg where ... }}} perhaps even in another module. Guarding against such subtle loops is a very good thing, in my view. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 30 13:45:45 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Dec 2014 13:45:45 -0000 Subject: [GHC] #9927: Should simplifier try more iterations? In-Reply-To: <047.578e70cae2a9663a3bc68c7bc786ce1f@haskell.org> References: <047.578e70cae2a9663a3bc68c7bc786ce1f@haskell.org> Message-ID: <062.8b983e7db8c4079bd95f3876fc3453f1@haskell.org> #9927: Should simplifier try more iterations? -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Try `-fmax-simplifier-iterations=N` to change the cutoff value. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 30 13:56:56 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Dec 2014 13:56:56 -0000 Subject: [GHC] #9922: Partial type signatures + extensions panic In-Reply-To: <047.bcb93dee275eec47e30ed9673a9b0d12@haskell.org> References: <047.bcb93dee275eec47e30ed9673a9b0d12@haskell.org> Message-ID: <062.1fccb4b6894277a64c2f0817fde7d58a@haskell.org> #9922: Partial type signatures + extensions panic -------------------------------------+------------------------------------- Reporter: monoidal | Owner: thomasw Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.9 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | Blocking: Blocked By: | Differential Revisions: Phab:D595 Related Tickets: | -------------------------------------+------------------------------------- Comment (by thomasw): Replying to [comment:5 simonpj]: > Thomas: I'm not very happy with the way that wild-card error reporting is done. I agree. I have thought about it too. An "opt-in to wildcards" approach would be much better than my current "opt-out" approach, which was bound to be incomplete. > I think we discussed this before, but left it on one side until it was all working. Which it now is. What I suggest is this: > .. > Does this make sense? Might you do it? (To HEAD, of course.) Looks like a good plan. I think your suggestion to provide a separate `rnLHsTypeWithWildCards` will help me overcome many of the problems I had when I last tried to refactor the renaming of wildcards. I'll start working on it as soon as the holidays are over, i.e. next week. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 30 14:52:02 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Dec 2014 14:52:02 -0000 Subject: [GHC] #9939: Warn for duplicate superclass constraints In-Reply-To: <047.cbb3a535ba98b12eaa610d54289e6f43@haskell.org> References: <047.cbb3a535ba98b12eaa610d54289e6f43@haskell.org> Message-ID: <062.bd9280a458da3958dd4730a48eaabd7e@haskell.org> #9939: Warn for duplicate superclass constraints -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Another example I hit recently. `Language.Haskell.TH.Syntax` used to have {{{ class (Applicative m, Monad m) => Quasi m where ... }}} When I saw this recently, I realized the `Applicative m` constraint is now redundant and so I removed it. However, it would have been helpful if GHC had issued a warning. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 30 14:56:40 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Dec 2014 14:56:40 -0000 Subject: [GHC] #9049: Expose srcLoc from the assertion architecture to allow better error messages In-Reply-To: <042.a0d4c757be085a0284ebca147547b4f3@haskell.org> References: <042.a0d4c757be085a0284ebca147547b4f3@haskell.org> Message-ID: <057.d5d89e4253b8bc5575e8879076bcbd22@haskell.org> #9049: Expose srcLoc from the assertion architecture to allow better error messages -------------------------------------+------------------------------------- Reporter: nh2 | Owner: gridaphobe Type: feature request | Status: patch Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D578 -------------------------------------+------------------------------------- Comment (by simonpj): Thanks. I've added some comments to Phab:D578. Here are some other thoughts: * Could you modify [wiki:ExplicitCallStack/ImplicitLocations] to describe the exact specification of what you propose? For example, the design means that there are two new types in the `base` library, defined in `GHC.Location`: * `SrcLoc` (for a source location) * `Location` (for a stack of source locations) Both are abstract, so you can't make a new `SrcLoc` or `Location`; only GHC can do that. Is that what we want? * You can add a section on open questions too, for things you aren't sure about. * I'm very keen that `SrcLoc` is used also by the `Typeable` library (and any other reflection libraries too). Currently `Data.Typeable.Internals` defines `TyCon` which contains package/module/name information, but it should just use a `SrcLoc`. We are proposing to redesign `Typeable` anyway (see [wiki:Typeable]) so we can do this `SrcLoc` stuff at the same time * Given this broader use, is `Location` the right name? It's really more like a `SrcLocStack`. * The stack would be even better if it said something like "foo called at " rather than just "". That would be easy enough to implement (the information is in the `CtOrigin` of the constraint), but again the data type would need to be elaborated a bit, something like {{{ data Location = Location [(String, SrcLoc)] }}} * At a grungy level, I wonder about all the copies of the same module- name and file-name strings. Maybe the desugarer should just generate one copy and use it? Or maybe CSE should gather them up (I don't think it does so at the moment.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 30 17:48:21 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Dec 2014 17:48:21 -0000 Subject: [GHC] #7788: Recursive type family causes <> In-Reply-To: <046.ea3ef9ceaabda348ee27e147f6e7ebb3@haskell.org> References: <046.ea3ef9ceaabda348ee27e147f6e7ebb3@haskell.org> Message-ID: <061.c4d2216f4d7d5834e18b2fbd2096c718@haskell.org> #7788: Recursive type family causes <> -------------------------------------+------------------------------------- Reporter: shachaf | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.6.2 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by simonpj): Richard, for the evaluation-depth thing, I think that all that is necessary is: * Call `bumpSubGoalDepth` on the `fe_loc` field of `fmode` in `try_to_reduce` in `TcFlatten.flatten_exact_fam_app_fully`. * And call `subGoalDepthExceeded` in the same function. Or the depth-exceeded check could be in `flatten_one`. Might you do this? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 31 00:03:20 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Dec 2014 00:03:20 -0000 Subject: [GHC] #9940: GHCi crashes when I hold down control-c for a short time, and then hold down any key that would normally result in typing. Message-ID: <045.57a3cba5fea4ade3aa4122b02fda65ee@haskell.org> #9940: GHCi crashes when I hold down control-c for a short time, and then hold down any key that would normally result in typing. -------------------------------------------+------------------------------- Reporter: Dingus | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.6.3 Keywords: crash, control-c | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------------+------------------------------- This is printed: (without the quotes at the beginning or end) " ghc.exe: panic! (the 'impossible' happened) (GHC version 7.6.3 for i386-unknown-mingw32): thread blocked indefinitely in an MVar operation Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug " I am able to reproduce it by: 1. starting ghci (with no arguments, or a file as an argument) 2. holding down contol-c for 2 seconds 3. holding down spacebar/a letter key for 2 seconds The timing varies. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 31 01:25:54 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Dec 2014 01:25:54 -0000 Subject: [GHC] #9918: GHC chooses an instance between two overlapping, but cannot resolve a clause within the similar closed type family In-Reply-To: <045.8b42c360bfa608017b9b2986029ca51e@haskell.org> References: <045.8b42c360bfa608017b9b2986029ca51e@haskell.org> Message-ID: <060.2cc235949fc2e481a546ce8cca23c109@haskell.org> #9918: GHC chooses an instance between two overlapping, but cannot resolve a clause within the similar closed type family -------------------------------------+------------------------------------- Reporter: qnikst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:10 simonpj]: > I conclude from this thread that > * `OverlappingInstances` should probably obey the same rules as closed type families, for consistency. Generally agreed here, with the same reservations that Simon writes. > > I suppose that we could lift the restriction (ie strengthen the "surely- apart" check) if some flag is set: > * I believe that the unpredictability only strikes if you have infinite types, via a looping type family. And a programmer might well be willing to guaranteed that will not occur. > * In that sense, it's a bit like `-XUndecidableInstances`: the programmer takes responsibility. > * And, as such it should probably be a per-type-family (or per-closed- type-family) pragma, rather than a global flag. Maybe even `{-# UNDECIDABLE #-}`. I'm not sure exactly what you mean here (mostly). The `{-# UNDECIDABLE #-}` route is almost surely a good idea, independent of anything else, as it follows the new pattern started by `{-# OVERLAPPABLE #-}` and friends. But, critically, a dangerous use of a strengthened apartness check would happen on a family '''without''' this pragma. For example: {{{ type family Equals a b where Equals a a = True Equals a b = False }}} This clearly has no loops and should compile without `{-# UNDECIDABLE #-}`. Yet, if we use the strengthened apartness check when choosing to reduce by the second equation, we can get into trouble. Specifically, should `Equals x [x]` reduce to `False`, for some skolem `x`? If, in some future module, we introduce `type family Loop where Loop = [Loop]`, then it would be terrible to have reduced `Equals x [x]` to `False`. But, of course, we have no way of knowing if `Loop` will come into being in the future. The nub of the problem, as I see it, is that the safety (for closed type families) or predictability (for class instances) of the system depends on some '''global''' no-looping property. I could see some `{-# UNSAFE_STRONGER_APARTNESS_CHECK #-}` pragma that could be put on `Equals` that would enable the stronger check and let the programmer bear the safety burden. However, this is a significant departure from other "let the programmer beware" issues in that, for closed type families, you can abuse this ability to implement `unsafeCoerce`. (This would not be the case for class instances.) So, getting back to Simon's proposal: what's your suggested behavior? I see what you want with `{-# UNDECIDABLE #-}`, but I don't see precisely how it would influence the apartness check. If we are going to start treating undecidable instances as different than regular ones, it would be worthwhile to make the termination checker smarter. Right now, a standard Peano multiplication type family requires `-XUndecidableInstances`. I think the assumed safety of that extension (I think folks are OK with a perhaps-looping compiler, as long as the produced binary, if any, is type-safe) allows people to use it without much hesitation, so there has been little (no?) pressure to improve the termination checker. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 31 01:31:14 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Dec 2014 01:31:14 -0000 Subject: [GHC] #3064: Very long compile times with type functions In-Reply-To: <046.2a7b2611764311f7357001c522d303b9@haskell.org> References: <046.2a7b2611764311f7357001c522d303b9@haskell.org> Message-ID: <061.cacfeb6c224ca12e1ef45c41d1f0c6e7@haskell.org> #3064: Very long compile times with type functions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: low | Milestone: 7.12.1 Component: Compiler (Type | Version: 6.10.1 checker) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | perf/compiler/T3064 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Good points in comment:21. I'm especially swayed by the ease with which this regression can be avoided, whereas previous problems were not. I do think, once a decision is made regarding 7.10 vs 7.12, a release note should be added. And, if possible, an error message that includes a note whenever the strictly-decreasing-superclass criterion bites would also be great. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 31 01:51:08 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Dec 2014 01:51:08 -0000 Subject: [GHC] #9918: GHC chooses an instance between two overlapping, but cannot resolve a clause within the similar closed type family In-Reply-To: <045.8b42c360bfa608017b9b2986029ca51e@haskell.org> References: <045.8b42c360bfa608017b9b2986029ca51e@haskell.org> Message-ID: <060.4f5aaff18ae089e7bbc68c4c5b0d2c37@haskell.org> #9918: GHC chooses an instance between two overlapping, but cannot resolve a clause within the similar closed type family -------------------------------------+------------------------------------- Reporter: qnikst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by qnikst): Seems I understood Simon differently. As far as I understood he advices make check for classes more strict, and less strict. So 1. For classes instances: {{{ instance F a (M a) where ... instance F a a where ... }}} Will no longer be accepted due to surely-apart check. And Equals typefamily will have the same rules as it has now. 2. As less programs will be accepted, and some really relies on the current behaviour, it's possible to introduce `{-# UNDECIDABLE #-}` pragma for type class that will remove new "surely-apart" check and instances will be accepted 3. (Simon didn't say it). In order to unify type families and type class bevaiour it's possible to allow `{-# UNDECIDANBLE #-}` pragma to be applied to type family. Yes, if it will be applied to a typefamily that should have surely-apart check (e.g. `Equals`) it will be broken. However if programmer takes responsibility and guarantee that this check is not needed (2 examples above) then he can use this pragma in order to make compiler accept this program. So as far as I understood this suggestion doesn't allow any new ill-typed program to be accepted, more over some programs that are accepted now will not be accepted then, but proposal provides a backdoor so programmer can have old behaviour. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 31 02:17:37 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Dec 2014 02:17:37 -0000 Subject: [GHC] #9941: How do I install GHC 7.8.1 and assign it a different command? Message-ID: <053.f23106015b4613a0857043f9db9df48a@haskell.org> #9941: How do I install GHC 7.8.1 and assign it a different command? -------------------------------------+------------------------------------- Reporter: | Owner: derekbarnes361 | Status: new Type: bug | Milestone: Priority: lowest | Version: 7.8.4 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I would like to install GHC 7.8.1, but would like to assign it different commands, so as not to clash with 7.6.3. For example: runghc with runghc7.8.1 ghci with ghci7.8.1 etc... Or similar. (ghci would be most important, for typed holes.) Basically, I want to be able to use GHC 7.8 and 7.6, so if there is a more direct way to do this tell me (A-B problem.) Note: Ubuntu 13.10 Send From : https://www.smore.com/v6vm-penomet-hydro-pump -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 31 02:20:52 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Dec 2014 02:20:52 -0000 Subject: [GHC] #9942: install GHC 7.8.1 at Ubuntu 13.10 Message-ID: <053.2bb2d9bd6a0f9edb2473765eb6d6844f@haskell.org> #9942: install GHC 7.8.1 at Ubuntu 13.10 -------------------------------------+------------------------------------- Reporter: | Owner: derekbarnes361 | Status: new Type: feature | Milestone: request | Version: 7.8.4 Priority: lowest | Operating System: Unknown/Multiple Component: Compiler | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Because you are on a unix-like system (Ubuntu) you can do the following: Choose a folder you like for installing ghc (e.g. in a subfolder of your home directory like $HOME/ghc7.8.1 or in a subfolder of /opt like /opt/ghc7.8.1 ? I would prefer the later one if you are the only user of your computer and the first one if this isn't the case). See this wikipedia article for explanations about the unix directory structure. Download the source code into that folder and follow the installation instructions: See also https://ghc.haskell.org/trac/ghc/wiki/Building/Using#Runtheconfigurescript In configure setp its important, that you set the --prefix to the folder you have chosen above (if you don't do this, ghc will be installed in /usr/local/ which you do not want)! For example: ./configure --prefix=/opt/ghc7.8.1 After the installations look for the folder with the created binaries (it will be called bin if you did not use another name for bindir). Lets imagine this folder is /opt/ghc7.8.1/bin. Now you have two possibilities: Solution with creating symlinks: Create symlinks in a folder which is in your $PATH pointing to the created binaries (for example /usr/local/bin or $HOME/bin ? I would use the first one, if you are the only user on your computer and the second if, if you are not). Therefore you have to use the command line tool ln. For example: sudo ln -s -T /opt/ghc7.8.1/bin/runghc /usr/local/bin/runghc7.8.1 After this command there is a file /usr/local/bin/runghc7.8.1 pointing to the binary /opt/ghc7.8.1/bin/runghc. Executing /usr/local/bin/runghc7.8.1 via typing runghc7.8.1 will now execute the runghc binary created in /opt (Note: sudo is not necessary if you create your symlink in $HOME/bin ? it is just needed because root can create files under /usr) Solution with bash aliases: Write in your $HOME/.bash_aliases (@Others: you can alternatively choose $HOME/.bashrc or $HOME/.profile depending of your system/preference) the following line: alias runghc7.8.1='/opt/ghc7.8.1/bin/runghc' Now typing runghc7.8.1 in your terminal is an shortcut (alias) for typing /opt/ghc7.8.1/bin/runghc and will execute this binary. Note, that with this solution typing runghc7.8.1 will just work, when you typed it into your terminal. There are cases, when it does not work (for example calling runghc7.8.1 in a script). Send From: [http://www.vigrxtrial.net/] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 31 06:21:42 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Dec 2014 06:21:42 -0000 Subject: [GHC] #9943: Replace "error" with "errorWithStackTrace" from GHC.Stack in base libs Message-ID: <050.203c2e197d8a38b0475372584b508376@haskell.org> #9943: Replace "error" with "errorWithStackTrace" from GHC.Stack in base libs -------------------------------------+------------------------------------- Reporter: | Owner: spacekitteh spacekitteh | Status: new Type: task | Milestone: 7.10.1 Priority: normal | Version: Component: Core | Operating System: Unknown/Multiple Libraries | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- It is basically the same as the standard error function but outputs a stack trace if one is available. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 31 06:51:19 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Dec 2014 06:51:19 -0000 Subject: [GHC] #9943: Replace "error" with "errorWithStackTrace" from GHC.Stack in base libs In-Reply-To: <050.203c2e197d8a38b0475372584b508376@haskell.org> References: <050.203c2e197d8a38b0475372584b508376@haskell.org> Message-ID: <065.5377f733344b6269a2e074e415dd1d42@haskell.org> #9943: Replace "error" with "errorWithStackTrace" from GHC.Stack in base libs -------------------------------------+------------------------------------- Reporter: spacekitteh | Owner: Type: task | spacekitteh Priority: normal | Status: new Component: Core Libraries | Milestone: 7.12.1 Resolution: | Version: Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by spacekitteh): * milestone: 7.10.1 => 7.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 31 07:24:22 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Dec 2014 07:24:22 -0000 Subject: [GHC] #9943: Replace "error" with "errorWithStackTrace" from GHC.Stack in base libs In-Reply-To: <050.203c2e197d8a38b0475372584b508376@haskell.org> References: <050.203c2e197d8a38b0475372584b508376@haskell.org> Message-ID: <065.e091b67e72a1ba60b0e9317d58aa781f@haskell.org> #9943: Replace "error" with "errorWithStackTrace" from GHC.Stack in base libs -------------------------------------+------------------------------------- Reporter: spacekitteh | Owner: Type: task | spacekitteh Priority: normal | Status: new Component: Core Libraries | Milestone: 7.12.1 Resolution: | Version: Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by hvr): Btw, it's not as simple as just set `error = errorWithStackTrace`; there needs to be a way to recover the string passed to `error` w/o the additional stack-trace from the `ErrorCall` exception value (which currently provides the originally passed `error`-message as its payload). {{{#!hs -- |This is thrown when the user calls 'error'. The @String@ is the -- argument given to 'error'. newtype ErrorCall = ErrorCall String deriving (Eq, Ord, Typeable) instance Exception ErrorCall instance Show ErrorCall where showsPrec _ (ErrorCall err) = showString err }}} See also this short conversation for some ideas: {{{ hvr> carter: btw, was my concern regarding modifying the payload of the ErrorCall exception ever addressed? carter> nopeee! :) carter> maybe we expose a pattern synonym as the constructor name carter> and have the real constructor have an extra field for the trace? hvr> could work carter> so show will still render the full mess carter> but everyone's old code wont break carter> because unless youre explicity catching it carter> it ends up just being showed right? carter> error "fix me" carter> hvr: pattern synonyms dont need to be eneabled in the use sites right? carter> hvr: err, the only reason for that change would be backwards compat right? hvr> carter: well, actually it's a nice property to be able to recover the exact string you pass to 'error' carter> hvr: i wasn't arguing against it :) hvr> carter: regardless of backward compat carter> ok carter> so breaking change to make it have two args? carter> or hide it with patternsyn? carter> or wait a year and try again? hvr> carter: you've got one year to figure out the perfect way :) carter> fineeeee carter> solution: break everything hvr> carter: otoh, maybe by then we may have some other facility which makes this redundant }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 31 08:52:31 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Dec 2014 08:52:31 -0000 Subject: [GHC] #9944: Performance issue Message-ID: <046.294f26f9df37b6976406f7cbb18967e5@haskell.org> #9944: Performance issue -------------------------------------+------------------------------------- Reporter: clinton | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- The runtime of the following code actually decreases if the number 2147483647 (2^31-1) is increased to 2147483648 (2^31). {{{#!hs f n = go 1 0 where go i c = if i == n then c + i else go (i+1) (c+i) main = print $ f (2147483647 :: Int) }}} I've attached two dumps from ghc-core, core7 is the 2147483647 case and core8 is the 2147483648 case, however the main differences are below: '''2147483647 case:''' {{{ _c3Qg: cmpq $2147483647,%r14 jne _c3Q9 _c3Qa: leaq 2147483647(%rsi),%rbx jmp *(%rbp) _c3Q9: addq %r14,%rsi incq %r14 jmp _c3Qg }}} '''2147483648 case:''' {{{ _c3Qg: movl $2147483648,%eax cmpq %rax,%r14 jne _c3Q9 _c3Qa: movl $2147483648,%eax movq %rsi,%rbx addq %rax,%rbx jmp *(%rbp) _c3Q9: addq %r14,%rsi incq %r14 jmp _c3Qg }}} Despite the extra instructions, the latter approach seems faster for my PC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 31 08:54:31 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Dec 2014 08:54:31 -0000 Subject: [GHC] #9944: Performance issue In-Reply-To: <046.294f26f9df37b6976406f7cbb18967e5@haskell.org> References: <046.294f26f9df37b6976406f7cbb18967e5@haskell.org> Message-ID: <061.260c94e8a480d9b547e78647d38e48a5@haskell.org> #9944: Performance issue -------------------------------------+------------------------------------- Reporter: clinton | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by clinton: Old description: > The runtime of the following code actually decreases if the number > 2147483647 (2^31-1) is increased to 2147483648 (2^31). > > {{{#!hs > f n = go 1 0 where > go i c = if i == n then c + i else go (i+1) (c+i) > > main = print $ f (2147483647 :: Int) > }}} > > I've attached two dumps from ghc-core, core7 is the 2147483647 case and > core8 is the 2147483648 case, however the main differences are below: > > '''2147483647 case:''' > {{{ > _c3Qg: > cmpq $2147483647,%r14 > jne _c3Q9 > _c3Qa: > leaq 2147483647(%rsi),%rbx > jmp *(%rbp) > _c3Q9: > addq %r14,%rsi > incq %r14 > jmp _c3Qg > }}} > > '''2147483648 case:''' > {{{ > _c3Qg: > movl $2147483648,%eax > cmpq %rax,%r14 > jne _c3Q9 > _c3Qa: > movl $2147483648,%eax > movq %rsi,%rbx > addq %rax,%rbx > jmp *(%rbp) > _c3Q9: > addq %r14,%rsi > incq %r14 > jmp _c3Qg > }}} > > Despite the extra instructions, the latter approach seems faster for my > PC. New description: The runtime of the following code actually decreases if the number 2147483647 (2^31^-1) is increased to 2147483648 (2^31^). {{{#!hs f n = go 1 0 where go i c = if i == n then c + i else go (i+1) (c+i) main = print $ f (2147483647 :: Int) }}} I've attached two dumps from ghc-core, core7 is the 2147483647 case and core8 is the 2147483648 case, however the main differences are below: '''2147483647 case:''' {{{ _c3Qg: cmpq $2147483647,%r14 jne _c3Q9 _c3Qa: leaq 2147483647(%rsi),%rbx jmp *(%rbp) _c3Q9: addq %r14,%rsi incq %r14 jmp _c3Qg }}} '''2147483648 case:''' {{{ _c3Qg: movl $2147483648,%eax cmpq %rax,%r14 jne _c3Q9 _c3Qa: movl $2147483648,%eax movq %rsi,%rbx addq %rax,%rbx jmp *(%rbp) _c3Q9: addq %r14,%rsi incq %r14 jmp _c3Qg }}} Despite the extra instructions, the latter approach seems faster for my PC. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 31 09:12:45 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Dec 2014 09:12:45 -0000 Subject: [GHC] #9944: Performance issue In-Reply-To: <046.294f26f9df37b6976406f7cbb18967e5@haskell.org> References: <046.294f26f9df37b6976406f7cbb18967e5@haskell.org> Message-ID: <061.036aff14abacd5d6eaca51cf550e2b00@haskell.org> #9944: Performance issue -------------------------------------+------------------------------------- Reporter: clinton | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): How much faster? How did you measure it? How did you trip over this? (I would never have guessed it would make a measurable difference.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 31 09:24:50 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Dec 2014 09:24:50 -0000 Subject: [GHC] #9944: Performance issue re: simple loop (was: Performance issue) In-Reply-To: <046.294f26f9df37b6976406f7cbb18967e5@haskell.org> References: <046.294f26f9df37b6976406f7cbb18967e5@haskell.org> Message-ID: <061.7f3786b58dbf651e7dcbdcce75455319@haskell.org> #9944: Performance issue re: simple loop -------------------------------------+------------------------------------- Reporter: clinton | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 31 09:36:32 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Dec 2014 09:36:32 -0000 Subject: [GHC] #9944: Performance issue re: simple loop In-Reply-To: <046.294f26f9df37b6976406f7cbb18967e5@haskell.org> References: <046.294f26f9df37b6976406f7cbb18967e5@haskell.org> Message-ID: <061.ab0487ea8d7a4fe15789fa5282ce2fc1@haskell.org> #9944: Performance issue re: simple loop -------------------------------------+------------------------------------- Reporter: clinton | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Old description: > The runtime of the following code actually decreases if the number > 2147483647 (2^31^-1) is increased to 2147483648 (2^31^). > > {{{#!hs > f n = go 1 0 where > go i c = if i == n then c + i else go (i+1) (c+i) > > main = print $ f (2147483647 :: Int) > }}} > > I've attached two dumps from ghc-core, core7 is the 2147483647 case and > core8 is the 2147483648 case, however the main differences are below: > > '''2147483647 case:''' > {{{ > _c3Qg: > cmpq $2147483647,%r14 > jne _c3Q9 > _c3Qa: > leaq 2147483647(%rsi),%rbx > jmp *(%rbp) > _c3Q9: > addq %r14,%rsi > incq %r14 > jmp _c3Qg > }}} > > '''2147483648 case:''' > {{{ > _c3Qg: > movl $2147483648,%eax > cmpq %rax,%r14 > jne _c3Q9 > _c3Qa: > movl $2147483648,%eax > movq %rsi,%rbx > addq %rax,%rbx > jmp *(%rbp) > _c3Q9: > addq %r14,%rsi > incq %r14 > jmp _c3Qg > }}} > > Despite the extra instructions, the latter approach seems faster for my > PC. New description: The runtime of the following code actually decreases if the number 2147483647 (2^31^-1) is increased to 2147483648 (2^31^). In addition, adding "module Main where" at the top of the file improves performance to the fast case regardless of what number is picked. {{{#!hs f n = go 1 0 where go i c = if i == n then c + i else go (i+1) (c+i) main = print $ f (2147483647 :: Int) }}} I've attached two dumps from ghc-core, core7 is the 2147483647 case and core8 is the 2147483648 case, however the main differences are below: '''2147483647 case:''' {{{ _c3Qg: cmpq $2147483647,%r14 jne _c3Q9 _c3Qa: leaq 2147483647(%rsi),%rbx jmp *(%rbp) _c3Q9: addq %r14,%rsi incq %r14 jmp _c3Qg }}} '''2147483648 case:''' {{{ _c3Qg: movl $2147483648,%eax cmpq %rax,%r14 jne _c3Q9 _c3Qa: movl $2147483648,%eax movq %rsi,%rbx addq %rax,%rbx jmp *(%rbp) _c3Q9: addq %r14,%rsi incq %r14 jmp _c3Qg }}} Despite the extra instructions, the latter approach seems faster for my PC. -- Comment (by clinton): Just "time". Difference for me is between 1.8 secs and 1.6 secs. Not a huge difference. Tripped over it because -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 31 09:50:23 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Dec 2014 09:50:23 -0000 Subject: [GHC] #9886: Undefined reference to `__sync_fetch_and_xor_8' In-Reply-To: <044.594e65ad21717924722ced76afd26d12@haskell.org> References: <044.594e65ad21717924722ced76afd26d12@haskell.org> Message-ID: <059.461e8443a7f0d268cf32e915d4db5199@haskell.org> #9886: Undefined reference to `__sync_fetch_and_xor_8' ----------------------------------------+---------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (CodeGen) | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------------+---------------------------------- Changes (by erikd): * owner: => erikd * version: 7.8.3 => 7.11 Comment: It seems that these `__sync_fetch_*` function were used around gcc 4.4 but have been replaced in gcc 4.8 with a different set of functions `__atomic_*`. Working on a patch to sort this out. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 31 09:53:32 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Dec 2014 09:53:32 -0000 Subject: [GHC] #9886: Undefined reference to `__sync_fetch_and_xor_8' In-Reply-To: <044.594e65ad21717924722ced76afd26d12@haskell.org> References: <044.594e65ad21717924722ced76afd26d12@haskell.org> Message-ID: <059.3eb02361cc0503c01b20f3cf92aa7163@haskell.org> #9886: Undefined reference to `__sync_fetch_and_xor_8' ----------------------------------------+---------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (CodeGen) | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------------+---------------------------------- Changes (by erikd): * cc: erikd (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 31 10:49:28 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Dec 2014 10:49:28 -0000 Subject: [GHC] #9943: Replace "error" with "errorWithStackTrace" from GHC.Stack in base libs In-Reply-To: <050.203c2e197d8a38b0475372584b508376@haskell.org> References: <050.203c2e197d8a38b0475372584b508376@haskell.org> Message-ID: <065.1f444013036091de666f79bbb79b1b03@haskell.org> #9943: Replace "error" with "errorWithStackTrace" from GHC.Stack in base libs -------------------------------------+------------------------------------- Reporter: spacekitteh | Owner: Type: task | spacekitteh Priority: normal | Status: closed Component: Core Libraries | Milestone: Resolution: invalid | Version: Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by spacekitteh): * status: new => closed * resolution: => invalid * milestone: 7.12.1 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 31 10:50:59 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Dec 2014 10:50:59 -0000 Subject: [GHC] #9943: Replace "error" with "errorWithStackTrace" from GHC.Stack in base libs In-Reply-To: <050.203c2e197d8a38b0475372584b508376@haskell.org> References: <050.203c2e197d8a38b0475372584b508376@haskell.org> Message-ID: <065.34fc76a59d30d46489693ac7679c1509@haskell.org> #9943: Replace "error" with "errorWithStackTrace" from GHC.Stack in base libs -------------------------------------+------------------------------------- Reporter: spacekitteh | Owner: Type: task | spacekitteh Priority: normal | Status: closed Component: Core Libraries | Milestone: Resolution: invalid | Version: Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by spacekitteh): Closed ticket in light of http://thread.gmane.org/gmane.comp.lang.haskell.libraries/23525/ this thread, which subsumes this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 31 15:56:15 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Dec 2014 15:56:15 -0000 Subject: [GHC] #9945: export list for System.Posix.Internals breaking the build on Windows Message-ID: <046.de9aafe108e71fe89d058ef5eea5b0ac@haskell.org> #9945: export list for System.Posix.Internals breaking the build on Windows -------------------------------------+------------------------------------- Reporter: MartinF | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Windows Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: #9852 Differential Revisions: | -------------------------------------+------------------------------------- The export list in System.Posix.Internals includes some names that, thanks to CPP, aren't defined when building on Windows. It was compiling fine a few days ago, so I think [Phab:D551] was the breaking change. I attach the `make` output from the failing step. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 31 16:00:45 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Dec 2014 16:00:45 -0000 Subject: [GHC] #9945: export list for System.Posix.Internals breaking the build on Windows In-Reply-To: <046.de9aafe108e71fe89d058ef5eea5b0ac@haskell.org> References: <046.de9aafe108e71fe89d058ef5eea5b0ac@haskell.org> Message-ID: <061.f451f55a888e78fccabe00106d86c63f@haskell.org> #9945: export list for System.Posix.Internals breaking the build on Windows -------------------------------------+------------------------------------- Reporter: MartinF | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #9852 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by MartinF): I'm thinking the fix should just be a matter of wrapping the relevant names in the export list in CPP conditionals, to match the CPP in the module body - so names are included in the export list IFF they're actually defined. That would restore the old behaviour from before the export list was added, anyway. I'm working on a patch to that end now. Shouldn't take long. Does that sound like the right course of action? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 31 16:01:59 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Dec 2014 16:01:59 -0000 Subject: [GHC] #9945: export list for System.Posix.Internals breaking the build on Windows In-Reply-To: <046.de9aafe108e71fe89d058ef5eea5b0ac@haskell.org> References: <046.de9aafe108e71fe89d058ef5eea5b0ac@haskell.org> Message-ID: <061.15e722f40364ad413be52b4a3200975d@haskell.org> #9945: export list for System.Posix.Internals breaking the build on Windows -------------------------------------+------------------------------------- Reporter: MartinF | Owner: MartinF Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #9852 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by MartinF): * owner: => MartinF -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 31 16:10:21 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Dec 2014 16:10:21 -0000 Subject: [GHC] #9945: export list for System.Posix.Internals breaking the build on Windows In-Reply-To: <046.de9aafe108e71fe89d058ef5eea5b0ac@haskell.org> References: <046.de9aafe108e71fe89d058ef5eea5b0ac@haskell.org> Message-ID: <061.50576da782559630882d754b76d233d7@haskell.org> #9945: export list for System.Posix.Internals breaking the build on Windows -------------------------------------+------------------------------------- Reporter: MartinF | Owner: MartinF Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #9852 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * cc: dfeuer (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 31 16:11:29 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Dec 2014 16:11:29 -0000 Subject: [GHC] #9852: Add missing export lists In-Reply-To: <045.0c137db4833268f838cfd23c79dcf251@haskell.org> References: <045.0c137db4833268f838cfd23c79dcf251@haskell.org> Message-ID: <060.0dbb31b534301c4634e0051c53d6be11@haskell.org> #9852: Add missing export lists -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: closed Priority: low | Milestone: 7.12.1 Component: Core Libraries | Version: 7.9 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9945 | Blocking: | Differential Revisions: Phab:D551 -------------------------------------+------------------------------------- Changes (by hvr): * related: => #9945 Comment: more fallout #9945 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 31 16:17:05 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Dec 2014 16:17:05 -0000 Subject: [GHC] #9945: export list for System.Posix.Internals breaking the build on Windows In-Reply-To: <046.de9aafe108e71fe89d058ef5eea5b0ac@haskell.org> References: <046.de9aafe108e71fe89d058ef5eea5b0ac@haskell.org> Message-ID: <061.d448185a2c6d27539d48a165ee7616a7@haskell.org> #9945: export list for System.Posix.Internals breaking the build on Windows -------------------------------------+------------------------------------- Reporter: MartinF | Owner: MartinF Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #9852 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by dfeuer): Fun times. I really thought I'd checked the CPP reasonably well, but this is the second failure. The real question is whether these conditionally- defined names are used outside the module, or whether they're intended only for internal use. If the latter, they just shouldn't be exported at all. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 31 16:41:45 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Dec 2014 16:41:45 -0000 Subject: [GHC] #9945: export list for System.Posix.Internals breaking the build on Windows In-Reply-To: <046.de9aafe108e71fe89d058ef5eea5b0ac@haskell.org> References: <046.de9aafe108e71fe89d058ef5eea5b0ac@haskell.org> Message-ID: <061.c18312d873147fe683a0163a8d378618@haskell.org> #9945: export list for System.Posix.Internals breaking the build on Windows -------------------------------------+------------------------------------- Reporter: MartinF | Owner: MartinF Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #9852 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by MartinF): Good call, I'll check while I'm at it. I've already discovered `is_console` was missing from the export list entirely, but CPP-conditionally used in `GHC.IO.FD.isTerminal`: {{{#!hs isTerminal :: FD -> IO Bool isTerminal fd = #if defined(mingw32_HOST_OS) if fdIsSocket fd then return False else is_console (fdFD fd) >>= return.toBool #else c_isatty (fdFD fd) >>= return.toBool #endif }}} I note it's used there `#if defined(mingw32_HOST_OS)`, but its definition in `System.Posix.Internals` is `#if !defined(HTYPE_TCFLAG_T)` - that doesn't seem right, but I don't know enough about what those constants mean to say what should be done about it (if anything). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 31 17:18:54 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Dec 2014 17:18:54 -0000 Subject: [GHC] #9945: export list for System.Posix.Internals breaking the build on Windows In-Reply-To: <046.de9aafe108e71fe89d058ef5eea5b0ac@haskell.org> References: <046.de9aafe108e71fe89d058ef5eea5b0ac@haskell.org> Message-ID: <061.e56cb06251d6d2d0f93f0135b799f636@haskell.org> #9945: export list for System.Posix.Internals breaking the build on Windows -------------------------------------+------------------------------------- Reporter: MartinF | Owner: MartinF Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #9852 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): I tripped over it too. The patch below "fixes" it, but it is obviously Not Right. Various functions are defined under THREE different sets of conditions * `#if !defined(HTYPE_TCFLAG_T)` * `#if !defined(mingw32_HOST_OS)` * `#if !defined(mingw32_HOST_OS) && !defined(__MINGW32__)` They should presumably be just one set of conditions? Anyway it would be great if someone could fix it properly. Simon {{{ diff --git a/libraries/base/System/Posix/Internals.hs b/libraries/base/System/Posix/Internals.hs index e2e32c3..344c09c 100644 --- a/libraries/base/System/Posix/Internals.hs +++ b/libraries/base/System/Posix/Internals.hs @@ -25,24 +25,43 @@ module System.Posix.Internals CFLock, CFilePath, CGroup, CLconv, CPasswd, CSigaction, CSigset, CStat, CTermios, CTm, CTms, CUtimbuf, CUtsname, FD, - c_access, c_chmod, c_close, c_creat, c_dup, c_dup2, c_fcntl_lock, - c_fcntl_read, c_fcntl_write, c_fork, c_fstat, c_ftruncate, c_getpid, - c_isatty, c_lflag, c_link, c_lseek, c_mkfifo, c_open, c_pipe, c_read, - c_s_isblk, c_s_ischr, c_s_isdir, c_s_isfifo, c_s_isreg, c_s_issock, - c_safe_open, c_safe_read, c_safe_write, c_sigaddset, c_sigemptyset, - c_sigprocmask, c_stat, c_tcgetattr, c_tcsetattr, c_umask, c_unlink, - c_utime, c_waitpid, c_write, const_echo, const_f_getfl, const_f_setfd, + c_access, c_chmod, c_close, c_creat, c_dup, c_dup2, + +#if !defined(mingw32_HOST_OS) && !defined(__MINGW32__) + c_fcntl_lock, c_fcntl_read, c_fcntl_write, c_fork, c_link, c_mkfifo, c_pipe, + c_sigemptyset, c_sigaddset, c_sigprocmask, c_tcgetattr, c_tcsetattr, + c_utime, c_waitpid, c_s_issock, + setCloseOnExec, +#endif +#if !defined(mingw32_HOST_OS) + peekFilePathLen, +#endif + +#if defined(HTYPE_TCFLAG_T) + tcSetAttr, + sizeof_termios, sizeof_sigset_t, c_lflag, poke_c_lflag, ptr_c_cc, + get_saved_termios, set_saved_termios, +#else + is_console, +#endif + + c_fstat, c_ftruncate, c_getpid, + c_isatty, c_lseek, c_open, c_read, + c_s_isblk, c_s_ischr, c_s_isdir, c_s_isfifo, c_s_isreg, + c_safe_open, c_safe_read, c_safe_write, + c_stat, c_umask, c_unlink, + c_write, const_echo, const_f_getfl, const_f_setfd, const_f_setfl, const_fd_cloexec, const_icanon, const_sig_block, const_sig_setmask, const_sigttou, const_tcsanow, const_vmin, const_vtime, dEFAULT_BUFFER_SIZE, fdFileSize, fdGetMode, fdStat, fdType, fileType, - getEcho, get_saved_termios, ioe_unknownfiletype, lstat, newFilePath, + getEcho, ioe_unknownfiletype, lstat, newFilePath, o_APPEND, o_BINARY, o_CREAT, o_EXCL, o_NOCTTY, o_NONBLOCK, o_RDONLY, - o_RDWR, o_TRUNC, o_WRONLY, peekFilePath, peekFilePathLen, poke_c_lflag, - ptr_c_cc, puts, sEEK_CUR, sEEK_END, sEEK_SET, s_isblk, s_ischr, s_isdir, - s_isfifo, s_isreg, s_issock, setCloseOnExec, setCooked, setEcho, - setNonBlockingFD, set_saved_termios, sizeof_sigset_t, sizeof_stat, - sizeof_termios, st_dev, st_ino, st_mode, st_mtime, st_size, statGetType, - tcSetAttr, withFilePath + o_RDWR, o_TRUNC, o_WRONLY, peekFilePath, + puts, sEEK_CUR, sEEK_END, sEEK_SET, s_isblk, s_ischr, s_isdir, + s_isfifo, s_isreg, s_issock, setCooked, setEcho, + setNonBlockingFD, sizeof_stat, + st_dev, st_ino, st_mode, st_mtime, st_size, statGetType, + withFilePath ) where #include "HsBaseConfig.h" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 31 17:32:51 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Dec 2014 17:32:51 -0000 Subject: [GHC] #9945: export list for System.Posix.Internals breaking the build on Windows In-Reply-To: <046.de9aafe108e71fe89d058ef5eea5b0ac@haskell.org> References: <046.de9aafe108e71fe89d058ef5eea5b0ac@haskell.org> Message-ID: <061.a26d5e847604fa26cf54f2082644e6c8@haskell.org> #9945: export list for System.Posix.Internals breaking the build on Windows -------------------------------------+------------------------------------- Reporter: MartinF | Owner: MartinF Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #9852 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by MartinF): Ah, you've beaten me to it. I've been working along effectively the same lines: {{{ diff --git a/libraries/base/System/Posix/Internals.hs b/libraries/base/System/Posix/Internals.hs index e2e32c3..d316826 100644 --- a/libraries/base/System/Posix/Internals.hs +++ b/libraries/base/System/Posix/Internals.hs @@ -25,24 +25,33 @@ module System.Posix.Internals CFLock, CFilePath, CGroup, CLconv, CPasswd, CSigaction, CSigset, CStat, CTermios, CTm, CTms, CUtimbuf, CUtsname, FD, - c_access, c_chmod, c_close, c_creat, c_dup, c_dup2, c_fcntl_lock, - c_fcntl_read, c_fcntl_write, c_fork, c_fstat, c_ftruncate, c_getpid, - c_isatty, c_lflag, c_link, c_lseek, c_mkfifo, c_open, c_pipe, c_read, - c_s_isblk, c_s_ischr, c_s_isdir, c_s_isfifo, c_s_isreg, c_s_issock, - c_safe_open, c_safe_read, c_safe_write, c_sigaddset, c_sigemptyset, - c_sigprocmask, c_stat, c_tcgetattr, c_tcsetattr, c_umask, c_unlink, - c_utime, c_waitpid, c_write, const_echo, const_f_getfl, const_f_setfd, - const_f_setfl, const_fd_cloexec, const_icanon, const_sig_block, - const_sig_setmask, const_sigttou, const_tcsanow, const_vmin, const_vtime, - dEFAULT_BUFFER_SIZE, fdFileSize, fdGetMode, fdStat, fdType, fileType, - getEcho, get_saved_termios, ioe_unknownfiletype, lstat, newFilePath, - o_APPEND, o_BINARY, o_CREAT, o_EXCL, o_NOCTTY, o_NONBLOCK, o_RDONLY, - o_RDWR, o_TRUNC, o_WRONLY, peekFilePath, peekFilePathLen, poke_c_lflag, - ptr_c_cc, puts, sEEK_CUR, sEEK_END, sEEK_SET, s_isblk, s_ischr, s_isdir, - s_isfifo, s_isreg, s_issock, setCloseOnExec, setCooked, setEcho, - setNonBlockingFD, set_saved_termios, sizeof_sigset_t, sizeof_stat, - sizeof_termios, st_dev, st_ino, st_mode, st_mtime, st_size, statGetType, - tcSetAttr, withFilePath + c_access, c_chmod, c_close, c_creat, c_dup, c_dup2, c_fstat, c_ftruncate, + c_getpid, c_isatty, c_lseek, c_open, c_read, c_s_isblk, c_s_ischr, + c_s_isdir, c_s_isfifo, c_s_isreg, c_safe_open, c_safe_read, c_safe_write, + c_stat, c_umask, c_unlink, c_write, const_echo, const_f_getfl, + const_f_setfd, const_f_setfl, const_fd_cloexec, const_icanon, + const_sig_block, const_sig_setmask, const_sigttou, const_tcsanow, + const_vmin, const_vtime, dEFAULT_BUFFER_SIZE, fdFileSize, fdGetMode, + fdStat, fdType, fileType, getEcho, ioe_unknownfiletype, lstat, + newFilePath, o_APPEND, o_BINARY, o_CREAT, o_EXCL, o_NOCTTY, o_NONBLOCK, + o_RDONLY, o_RDWR, o_TRUNC, o_WRONLY, peekFilePath, puts, sEEK_CUR, + sEEK_END, sEEK_SET, s_isblk, s_ischr, s_isdir, s_isfifo, s_isreg, + s_issock, setCooked, setEcho, setNonBlockingFD, sizeof_stat, st_dev, + st_ino, st_mode, st_mtime, st_size, statGetType, withFilePath, +#if !defined(mingw32_HOST_OS) && !defined(__MINGW32__) + c_fcntl_lock, c_fcntl_read, c_fcntl_write, c_fork, c_link, c_mkfifo, + c_pipe, c_s_issock, c_sigaddset, c_sigemptyset, c_sigprocmask, + c_tcgetattr, c_tcsetattr, c_utime, c_waitpid, setCloseOnExec, +#endif +#if !defined(mingw32_HOST_OS) + peekFilePathLen, +#endif +#if defined(HTYPE_TCFLAG_T) + c_lflag, get_saved_termios, poke_c_lflag, ptr_c_cc, set_saved_termios, + sizeof_sigset_t, sizeof_termios, tcSetAttr, +#else + is_console, +#endif ) where #include "HsBaseConfig.h" }}} What do `HTYPE_TCFLAG_T` / `mingw32_HOST_OS` / `__MINGW32__` mean exactly? Are their precise semantics written down somewhere? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 31 17:51:42 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Dec 2014 17:51:42 -0000 Subject: [GHC] #9945: export list for System.Posix.Internals breaking the build on Windows In-Reply-To: <046.de9aafe108e71fe89d058ef5eea5b0ac@haskell.org> References: <046.de9aafe108e71fe89d058ef5eea5b0ac@haskell.org> Message-ID: <061.f0ceb81c667130b41bf07c5065a3febe@haskell.org> #9945: export list for System.Posix.Internals breaking the build on Windows -------------------------------------+------------------------------------- Reporter: MartinF | Owner: MartinF Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #9852 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by dfeuer): Erik de Castro Lopo believes that conditional exports are generally wrong, and I think he's generally right. Can users of these conditional definitions be moved to `Internals`? Or can these definitions be broken out into a platform-specific module? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 31 18:13:19 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Dec 2014 18:13:19 -0000 Subject: [GHC] #9945: export list for System.Posix.Internals breaking the build on Windows In-Reply-To: <046.de9aafe108e71fe89d058ef5eea5b0ac@haskell.org> References: <046.de9aafe108e71fe89d058ef5eea5b0ac@haskell.org> Message-ID: <061.16476b91bbb63a669f31d7f2b06ccfaf@haskell.org> #9945: export list for System.Posix.Internals breaking the build on Windows -------------------------------------+------------------------------------- Reporter: MartinF | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #9852 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by MartinF): * owner: MartinF => Comment: Yikes. I claimed the job intending to make the na?ve fix, but that sort of more substantial change is probably beyond me at the moment - I'm very much still learning the ropes, having first downloaded the GHC source only a few days ago. So I think I'd better disown this & let those more familiar with the code take over. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 31 18:33:06 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Dec 2014 18:33:06 -0000 Subject: [GHC] #9943: Replace "error" with "errorWithStackTrace" from GHC.Stack in base libs In-Reply-To: <050.203c2e197d8a38b0475372584b508376@haskell.org> References: <050.203c2e197d8a38b0475372584b508376@haskell.org> Message-ID: <065.4df03f78d376475d9e646c0404be5274@haskell.org> #9943: Replace "error" with "errorWithStackTrace" from GHC.Stack in base libs -------------------------------------+------------------------------------- Reporter: spacekitteh | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by carter): * owner: spacekitteh => * status: closed => new * resolution: invalid => Comment: this ticket is still valid for tracking this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 31 18:34:42 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Dec 2014 18:34:42 -0000 Subject: [GHC] #9943: Replace "error" with "errorWithStackTrace" from GHC.Stack in base libs In-Reply-To: <050.203c2e197d8a38b0475372584b508376@haskell.org> References: <050.203c2e197d8a38b0475372584b508376@haskell.org> Message-ID: <065.e52b7c9f9a2baea68e5d728c649b7179@haskell.org> #9943: Replace "error" with "errorWithStackTrace" from GHC.Stack in base libs -------------------------------------+------------------------------------- Reporter: spacekitteh | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by carter): Chris and I spent some time working on this, its actually pretty tricky to implement even a nominally simple patch for this because you quickly run into navigating figuring out where to write the boot file for cutting a recursive module loop -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 31 21:52:25 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Dec 2014 21:52:25 -0000 Subject: [GHC] #9918: GHC chooses an instance between two overlapping, but cannot resolve a clause within the similar closed type family In-Reply-To: <045.8b42c360bfa608017b9b2986029ca51e@haskell.org> References: <045.8b42c360bfa608017b9b2986029ca51e@haskell.org> Message-ID: <060.28219f018afb661687f654603a9737c9@haskell.org> #9918: GHC chooses an instance between two overlapping, but cannot resolve a clause within the similar closed type family -------------------------------------+------------------------------------- Reporter: qnikst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): The straw-man proposal is that with `{-# UNDECIDABLE #-}` (or some other pragma name) on a closed type family, the surely-apart check is strengthened, allowing more reductions to fire. Richard, you rightly point out that if you put that on `Equal`, then `Equal x [x]` would return `False`, as you'd expect if all types were finite. But you also claim that if you can define an infinite type, then you can get `unsafeCoerce`. I believe you (c.f Section 6 of the [http://research.microsoft.com/en-us/um/people/simonpj/papers/ext-f/ Closed Type Families paper]). But can you exhibit an example? And if you can, can you translate it back into an example using overlapping classes, probably with equality superclasses? If so, perhaps our existing compiler is unsound! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 31 22:21:00 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Dec 2014 22:21:00 -0000 Subject: [GHC] #9946: Expose the source location of template-haskell Names Message-ID: <049.db4709f25d3264deb5da9ff8a9867c2f@haskell.org> #9946: Expose the source location of template-haskell Names -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: feature | Status: new request | Milestone: Priority: low | Version: 7.11 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I've often wanted to know where a particular `Name` is defined (specifically the filepath), but as far as I can tell, template-haskell doesn't currently support this. It'd be really nice to have a function {{{#!hs nameLoc :: Name -> Loc }}} to expose the definition site of the `Name`. I think this should be fairly straightforward to add since GHC carries the definition site around with its `Name`s, but I've never looked at the TH internals. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 31 22:54:24 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Dec 2014 22:54:24 -0000 Subject: [GHC] #9886: Undefined reference to `__sync_fetch_and_xor_8' In-Reply-To: <044.594e65ad21717924722ced76afd26d12@haskell.org> References: <044.594e65ad21717924722ced76afd26d12@haskell.org> Message-ID: <059.5a523c53f267d109393d59656cd41806@haskell.org> #9886: Undefined reference to `__sync_fetch_and_xor_8' ----------------------------------------+---------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (CodeGen) | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------------+---------------------------------- Comment (by erikd): For some reason GCC doesn't seem to have 8 bit versions of any of the atomic functions. No idea why. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 31 23:00:40 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Dec 2014 23:00:40 -0000 Subject: [GHC] #9886: Undefined reference to `__sync_fetch_and_xor_8' In-Reply-To: <044.594e65ad21717924722ced76afd26d12@haskell.org> References: <044.594e65ad21717924722ced76afd26d12@haskell.org> Message-ID: <059.ac7421040632f1a2e5e34d7c0f4e7280@haskell.org> #9886: Undefined reference to `__sync_fetch_and_xor_8' ----------------------------------------+---------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (CodeGen) | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------------+---------------------------------- Comment (by erikd): Bah, turns out it was a lack of the 64 bit versions of these that was the problem all along. -- Ticket URL: GHC The Glasgow Haskell Compiler