From ghc-devs at haskell.org Tue Sep 1 01:48:13 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Sep 2015 01:48:13 -0000 Subject: [GHC] #10806: Type error and type level (<=) together cause GHC to hang In-Reply-To: <048.9b3d349db1bfdcff1a2e281d43595c9a@haskell.org> References: <048.9b3d349db1bfdcff1a2e281d43595c9a@haskell.org> Message-ID: <063.33d6a36f35b530c1041ff3ec80b02f08@haskell.org> #10806: Type error and type level (<=) together cause GHC to hang -------------------------------------+------------------------------------- Reporter: htebalaka | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by htebalaka): Looking at this further, it seems like any type error in the file triggers the issue in the presence of triggersLoop. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 1 03:09:20 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Sep 2015 03:09:20 -0000 Subject: [GHC] #10818: GHC 7.10.2 takes much longer to compile some packages In-Reply-To: <052.bbf8ed2f6a4e18f5bbbbe47aede56c86@haskell.org> References: <052.bbf8ed2f6a4e18f5bbbbe47aede56c86@haskell.org> Message-ID: <067.4e759fee6525839128e80bf9fcbe54b6@haskell.org> #10818: GHC 7.10.2 takes much longer to compile some packages -------------------------------------+------------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by maoe): * cc: maoe (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 1 06:25:10 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Sep 2015 06:25:10 -0000 Subject: [GHC] #10819: Can't generate data decls deriving multiparam type classes with TH Message-ID: <045.f6bd7f45fafc0112a449414b624abe97@haskell.org> #10819: Can't generate data decls deriving multiparam type classes with TH -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Template | Version: 7.10.2 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- This applies to both data declarations and (more commonly) newtypes. Example: {{{ {-# LANGUAGE GeneralizedNewtypeDeriving #-} newtype T a = X { unT :: State Int a } deriving (MonadState Int) }}} The newtype declaration is impossible to express in Template Haskell's AST, as the field for the derived classes is {{{[Name]}}} when it should really be {{{Cxt}}}. A workaround is to generate a {{{StandaloneDerivD}}} for each derived multiparam class, but this requires that the user enable the {{{StandaloneDeriving}}} extension which can be unintuitive, especially as there's no way (as far as I can tell) to detect whether this extension is enabled and report a proper error message if it isn't. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 1 06:29:31 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Sep 2015 06:29:31 -0000 Subject: [GHC] #10820: Provide a way to detect what extensions are enabled via TH Message-ID: <045.fdd68b124ff34a39c484baed79715ead@haskell.org> #10820: Provide a way to detect what extensions are enabled via TH -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Template | Version: 7.10.2 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- This would be helpful for providing users with intuitive error messages if generated code relies on an extension that the user may not have enabled. Sample specification, to get things started: {{{ enabledExts :: Q [Extension] isExtEnabled :: Extension -> Q Bool data Extension = LiberalTypeSynonyms | RankNTypes | ... -- mirroring ExtensionFlag in DynFlags }}} See #10819 for an example case where this could be of use. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 1 06:31:07 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Sep 2015 06:31:07 -0000 Subject: [GHC] #10820: Provide a way to detect what extensions are enabled via TH In-Reply-To: <045.fdd68b124ff34a39c484baed79715ead@haskell.org> References: <045.fdd68b124ff34a39c484baed79715ead@haskell.org> Message-ID: <060.7f3ab9f558b7f40f4c0c2d62e7d4d85e@haskell.org> #10820: Provide a way to detect what extensions are enabled via TH -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by spinda: Old description: > This would be helpful for providing users with intuitive error messages > if generated code relies on an extension that the user may not have > enabled. > > Sample specification, to get things started: > > {{{ > enabledExts :: Q [Extension] > isExtEnabled :: Extension -> Q Bool > data Extension = LiberalTypeSynonyms | RankNTypes | ... > -- mirroring ExtensionFlag in DynFlags > }}} > > See #10819 for an example case where this could be of use. New description: This would be helpful for providing users with intuitive/explanatory error messages if generated code relies on an extension that the user may not have enabled. Sample specification, to get things started: {{{ enabledExts :: Q [Extension] isExtEnabled :: Extension -> Q Bool data Extension = LiberalTypeSynonyms | RankNTypes | ... -- mirroring ExtensionFlag in DynFlags }}} See #10819 for an example case where this could be of use. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 1 06:35:50 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Sep 2015 06:35:50 -0000 Subject: [GHC] #10821: Add a flag to avoid generation of .hi, .o, .dyn_* files Message-ID: <045.f0f41ad07a5d71b217261fb2fd5616e4@haskell.org> #10821: Add a flag to avoid generation of .hi, .o, .dyn_* files -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- When running tests involving GHC (eg. when developing GHC plugins), it is cumbersome and frustrating to have to constantly clean up the .hi, .o, and .dyn_* files that GHC leaves behind. There should be a way to tell GHC not to generate these files at all, or if they're needed during the build process, to clean them up on its own once it's finished with them. (Apologies if this is a duplicate issue -- "hi" and "o" are difficult terms to search on the bug tracker.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 1 06:36:06 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Sep 2015 06:36:06 -0000 Subject: [GHC] #10821: Add a flag to avoid generation of .hi, .o, .dyn_* files In-Reply-To: <045.f0f41ad07a5d71b217261fb2fd5616e4@haskell.org> References: <045.f0f41ad07a5d71b217261fb2fd5616e4@haskell.org> Message-ID: <060.55fe9f088aba9674f0466e162d3aeb8a@haskell.org> #10821: Add a flag to avoid generation of .hi, .o, .dyn_* files -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by spinda: Old description: > When running tests involving GHC (eg. when developing GHC plugins), it is > cumbersome and frustrating to have to constantly clean up the .hi, .o, > and .dyn_* files that GHC leaves behind. There should be a way to tell > GHC not to generate these files at all, or if they're needed during the > build process, to clean them up on its own once it's finished with them. > > (Apologies if this is a duplicate issue -- "hi" and "o" are difficult > terms to search on the bug tracker.) New description: When running tests involving GHC (eg. when developing GHC plugins), it is cumbersome and frustrating to have to constantly clean up the .hi, .o, and .dyn_* files that GHC leaves behind. There should be a way to tell GHC not to generate these files at all, or if they're really needed during the build process, to clean them up on its own once it's finished with them. (Apologies if this is a duplicate issue -- "hi" and "o" are difficult terms to search on the bug tracker.) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 1 06:39:11 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Sep 2015 06:39:11 -0000 Subject: [GHC] #10541: Expose kind information for type variables with reify In-Reply-To: <045.f61f8e7682823a4edaec414f800b149e@haskell.org> References: <045.f61f8e7682823a4edaec414f800b149e@haskell.org> Message-ID: <060.a3ba0c41ef298fe4ab5991a760836818@haskell.org> #10541: Expose kind information for type variables with reify -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by spinda): Hi -- just wanted to say that I don't need this anymore. Not sure if someone else does... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 1 06:42:00 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Sep 2015 06:42:00 -0000 Subject: [GHC] #10822: GHC inconsistently handles \\?\ for long paths on Windows Message-ID: <047.7e6bb9965cce015f93541e4a1a931ae5@haskell.org> #10822: GHC inconsistently handles \\?\ for long paths on Windows -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Windows Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- To demonstrate what I mean first: {{{ >ghc-pkg init \\?\c:\Users\michael\Desktop\some-pkg-db >dir \\?\c:\Users\Michael\Desktop\some-pkg-db Volume in drive \\?\c: is Windows8_OS Volume Serial Number is CEF7-874D Directory of \\?\c:\Users\Michael\Desktop\some-pkg-db 09/01/2015 09:38 AM . 09/01/2015 09:38 AM .. 09/01/2015 09:38 AM 40 package.cache 1 File(s) 40 bytes 2 Dir(s) 5,907,509,248 bytes free >ghc -package-db \\?\c:\Users\Michael\Desktop\some-pkg-db ghc: can't find a package database at \\?\c:\Users\Michael\Desktop\some- pkg-db }}} The problem: on Windows by default, paths are limited to 260 characters, which can become a real problem in practice when dealing with the standard library path hierarchy the Cabal library uses and any package with a decent name length. This was a real problem in practice, see: https://github.com/haskell/cabal/issues/2502 Windows has a workaround for this: you can prefix an absolute path with \\?\, see: https://msdn.microsoft.com/en- us/library/windows/desktop/aa365247%28v=vs.85%29.aspx#maxpath It would be very useful if such paths worked with GHC, but currently they do not. I don't yet know how deep the problem is. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 1 06:47:29 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Sep 2015 06:47:29 -0000 Subject: [GHC] #10820: Provide a way to detect what extensions are enabled via TH In-Reply-To: <045.fdd68b124ff34a39c484baed79715ead@haskell.org> References: <045.fdd68b124ff34a39c484baed79715ead@haskell.org> Message-ID: <060.f1deee8b7b421d8106075f920585306f@haskell.org> #10820: Provide a way to detect what extensions are enabled via TH -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * milestone: => 7.12.1 Comment: I've wanted this, too. It should be able to happen by 7.12. But, what data type to use for the extensions? Would it work to have `template-haskell` depend on `Cabal` to pull the extension type from there? My guess: no. Would it work to have `template-haskell` depend on `ghc` and pull the type from `DynFlags`? My guess: yes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 1 06:52:18 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Sep 2015 06:52:18 -0000 Subject: [GHC] #10541: Expose kind information for type variables with reify In-Reply-To: <045.f61f8e7682823a4edaec414f800b149e@haskell.org> References: <045.f61f8e7682823a4edaec414f800b149e@haskell.org> Message-ID: <060.9aa8a809d8b465e8b4e4ebf5e704152d@haskell.org> #10541: Expose kind information for type variables with reify -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.1 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => wontfix Comment: In that case, I'm going to close as wontfix. If you, or anyone else, needs this, please do reopen. I do like the idea of providing this functionality, but it's hard to motivate the time necessary if there are no eager users. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 1 06:54:58 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Sep 2015 06:54:58 -0000 Subject: [GHC] #10820: Provide a way to detect what extensions are enabled via TH In-Reply-To: <045.fdd68b124ff34a39c484baed79715ead@haskell.org> References: <045.fdd68b124ff34a39c484baed79715ead@haskell.org> Message-ID: <060.c1d7c5c0eb2426844748f53020c0e0eb@haskell.org> #10820: Provide a way to detect what extensions are enabled via TH -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by spinda): Would it work to have template-haskell depend on ghc and pull the type from DynFlags? My guess: yes. Wouldn't this create a mutually recursive package dependency, as {{{ghc}}} already depends on {{{template-haskell}}}? (see [https://github.com/ghc/ghc/blob/b4ed13000cf0cbbb5916727dad018d91c10f1fd8/compiler/ghc.cabal.in#L55 ghc.cabal.in] and [https://github.com/ghc/ghc/blob/master/compiler/typecheck/TcSplice.hs#L105 TcSplice]) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 1 07:12:33 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Sep 2015 07:12:33 -0000 Subject: [GHC] #10820: Provide a way to detect what extensions are enabled via TH In-Reply-To: <045.fdd68b124ff34a39c484baed79715ead@haskell.org> References: <045.fdd68b124ff34a39c484baed79715ead@haskell.org> Message-ID: <060.c874318734b53cb4580f635a7b1de88d@haskell.org> #10820: Provide a way to detect what extensions are enabled via TH -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Bah. Of course you're right. And I don't think it's a great idea to depend on `Cabal` because that package can be upgraded independently of GHC. Correct me if this wouldn't cause pain. I guess we could have Yet Another List Of Extensions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 1 08:14:22 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Sep 2015 08:14:22 -0000 Subject: [GHC] #10821: Add a flag to avoid generation of .hi, .o, .dyn_* files In-Reply-To: <045.f0f41ad07a5d71b217261fb2fd5616e4@haskell.org> References: <045.f0f41ad07a5d71b217261fb2fd5616e4@haskell.org> Message-ID: <060.fc08b4dc530d3003f389cffbc977313a@haskell.org> #10821: Add a flag to avoid generation of .hi, .o, .dyn_* files -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): You could use `ghc -outputdir=/tmp`, or one of the flags in https://downloads.haskell.org/~ghc/7.10.2/docs/html/users_guide/separate- compilation.html#options-output. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 1 11:25:34 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Sep 2015 11:25:34 -0000 Subject: [GHC] #8596: Add support for "reponse files" to workaround Windows command line length limitations In-Reply-To: <047.4af16120e3d32bd0dd2986d2dd5dd2de@haskell.org> References: <047.4af16120e3d32bd0dd2986d2dd5dd2de@haskell.org> Message-ID: <062.57d5d1f970f6ad0f2220804e8f67ded1@haskell.org> #8596: Add support for "reponse files" to workaround Windows command line length limitations -------------------------------------+------------------------------------- Reporter: joeyhess | Owner: snoyberg Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10777 #9685 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by philipp): Hi Michael, thanks for your patch. I compiled ghc 7.10.2 with your patch on windows. Unfortunately, I still get an error when I try to build my project. While trying to link the executable, I get {{{ gcc.exe: error: CreateProcess: No such file or directory }}} Any ideas what the reason could be? If I can help in diagnosing this further, please let me know. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 1 11:28:25 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Sep 2015 11:28:25 -0000 Subject: [GHC] #8596: Add support for "reponse files" to workaround Windows command line length limitations In-Reply-To: <047.4af16120e3d32bd0dd2986d2dd5dd2de@haskell.org> References: <047.4af16120e3d32bd0dd2986d2dd5dd2de@haskell.org> Message-ID: <062.dbd33970e7e34f0268aa84f76c468920@haskell.org> #8596: Add support for "reponse files" to workaround Windows command line length limitations -------------------------------------+------------------------------------- Reporter: joeyhess | Owner: snoyberg Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10777 #9685 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by snoyberg): Yes, the problem is that the GCC toolchain that ships with GHC 7.10 does not itself use response files internally when calling itself for linking. We diagnosed this here, including a short-term (hacky) fix: https://github.com/commercialhaskell/stack/issues/795#issuecomment-134758338 In order to get this included in GHC 7.10.3, https://ghc.haskell.org/trac/ghc/ticket/10726 has been set to merge status. Once that's backported, the ghc-7.10 branch should just work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 1 11:30:10 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Sep 2015 11:30:10 -0000 Subject: [GHC] #10726: Upgrade MingW-w64 distributions for windows In-Reply-To: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> References: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> Message-ID: <059.415466f90562e53117b965be2f9893d7@haskell.org> #10726: Upgrade MingW-w64 distributions for windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: task | Status: merge Priority: normal | Milestone: 7.10.3 Component: Build System | Version: 7.11 Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9218 #9014 | Differential Revisions: Phab:D1123 #10435 | -------------------------------------+------------------------------------- Comment (by snoyberg): Just adding a clarifying comment. The reason for the requested merge to 7.10 is so that gcc can use response files internally, fixing an issue with long linker command line options. This was originally raised in https://ghc.haskell.org/trac/ghc/ticket/8596. The discussion leading up to the requested merge is on Github at https://github.com/commercialhaskell/stack/issues/795#issuecomment-134758338 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 1 11:50:35 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Sep 2015 11:50:35 -0000 Subject: [GHC] #8596: Add support for "reponse files" to workaround Windows command line length limitations In-Reply-To: <047.4af16120e3d32bd0dd2986d2dd5dd2de@haskell.org> References: <047.4af16120e3d32bd0dd2986d2dd5dd2de@haskell.org> Message-ID: <062.52f9c11d632f01bb7ba0c38598000ca6@haskell.org> #8596: Add support for "reponse files" to workaround Windows command line length limitations -------------------------------------+------------------------------------- Reporter: joeyhess | Owner: snoyberg Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10777 #9685 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by philipp): Thanks! I can happily confirm that using the new version of mingw solved the problem for me :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 1 13:35:09 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Sep 2015 13:35:09 -0000 Subject: [GHC] #10793: Incorrect blocked on MVar detection In-Reply-To: <051.7658851bb71506c4b1bae1ee7211ff06@haskell.org> References: <051.7658851bb71506c4b1bae1ee7211ff06@haskell.org> Message-ID: <066.f7561b2cf10f0fc038dae3831796d347@haskell.org> #10793: Incorrect blocked on MVar detection -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 7.10.1 Resolution: wontfix | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonmar): Well, thinking about it a bit more, in this case it would be possible to do something differently. We have * a main thread, blocked on an MVar * a child thread, in an infinite loop * the MVar, reachable from both threads. All of these things are unreachable from the roots, so we definitely can't make progress without throwing an exception. Normally we throw exceptions to all the deadlocked threads in this case, because it's the only deterministic thing we can do. (picking a thread randomly to receive the exception doesn't seem good). We could refine it slightly so that if there are both NonTermination exceptions and BlockedIndefinitelyOnMVar exceptions, we only throw the NonTermination exceptions. We know that waking up the BlockedIndefinitelyOnMVar threads can't unblock the NonTermination threads, but the reverse might be true. That wouldn't change the more common case of this, which is where both threads are blocked on MVars: {{{ main = do v <- newEmptyMVar v2 <- newEmptyMVar forkFinally (takeMVar v2) (putMVar v) print =<< takeMVar v }}} here we'd still get both exceptions at the same time. So I'm not sure how I feel about doing something different for `NonTermination`, possibly making the situation more complicated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 1 15:46:34 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Sep 2015 15:46:34 -0000 Subject: [GHC] #10821: Add a flag to avoid generation of .hi, .o, .dyn_* files In-Reply-To: <045.f0f41ad07a5d71b217261fb2fd5616e4@haskell.org> References: <045.f0f41ad07a5d71b217261fb2fd5616e4@haskell.org> Message-ID: <060.8fc1d42750f5ac5a3607755920e0d389@haskell.org> #10821: Add a flag to avoid generation of .hi, .o, .dyn_* files -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): Note that actually just dumping them all in `/tmp` is not such a good idea, you should make a new temporary directory for each compilation run. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 1 18:21:41 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Sep 2015 18:21:41 -0000 Subject: [GHC] #10823: Expose keepAlive to Template Haskell Message-ID: <045.57db4451919a86b3fcad053f0c16d552@haskell.org> #10823: Expose keepAlive to Template Haskell -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- {{{keepAlive}}} is a [https://github.com/ghc/ghc/blob/efa7b3a474bc373201ab145c129262a73c86f959/compiler/typecheck/TcRnMonad.hs#L1276 function in TcRnMonad] that adds a {{{Name}}} to the set of {{{Name}}}s to keep when pruning out dead code. A concrete use case for exposing this to Template Haskell is in LiquidHaskell, which will soon function as a Core plugin. In LiquidHaskell, a subset of Haskell functions can be "lifted" to the logic level and used in types. For example: {{{ module Test (ok) where [lq| inline gt |] gt x y = x > y [lq| ok :: x:Int -> { v:Int | gt x v } |] ok x = x + 1 }}} LiquidHaskell runs a transformation from the {{{CoreBind}}} for {{{gt}}} to its internal representation of decidable logic. Since Core plugins are run after "dead" code is removed at the end of desugaring, and since {{{gt}}} is not exported, the {{{CoreBind}}} for {{{gt}}} would not reach the {{{CoreBinds}}} LH receives as a Core plugin. The solution for this is to be able to mark names with {{{keepAlive}}} from Template Haskell. Proposed specification: {{{ keepAlive :: Name -> Q () }}} where {{{Name}}} is a Template Haskell {{{Name}}}. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 1 18:22:28 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Sep 2015 18:22:28 -0000 Subject: [GHC] #10823: Expose keepAlive to Template Haskell In-Reply-To: <045.57db4451919a86b3fcad053f0c16d552@haskell.org> References: <045.57db4451919a86b3fcad053f0c16d552@haskell.org> Message-ID: <060.79ec0e359fa17206aac38c7f2335b22e@haskell.org> #10823: Expose keepAlive to Template Haskell -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by spinda): * component: Compiler => Template Haskell -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 1 19:20:27 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Sep 2015 19:20:27 -0000 Subject: [GHC] #10047: inconsistency in name binding between splice and quasiquotation In-Reply-To: <047.467ed7feed46ef69006cfd30a0e1c7fb@haskell.org> References: <047.467ed7feed46ef69006cfd30a0e1c7fb@haskell.org> Message-ID: <062.e94430b63a5be366fbb8dd045f869fc2@haskell.org> #10047: inconsistency in name binding between splice and quasiquotation -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: spinda Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: th/T10047 Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1199 -------------------------------------+------------------------------------- Changes (by spinda): * owner: => spinda * differential: => Phab:D1199 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 1 20:32:05 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Sep 2015 20:32:05 -0000 Subject: [GHC] #10824: Let-bindings of kind # are processed backwards Message-ID: <045.c0cfb865a77b8ab0d0da4471347445ce@haskell.org> #10824: Let-bindings of kind # are processed backwards -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Consider this module: {{{ {-# LANGUAGE MagicHash #-} import GHC.Exts main = do let x = error "bar" :: Int# y = error "foo" :: Int# print (I# x + I# y) }}} When you run this, you will get the error "foo" and not the error "bar". This is backwards! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 1 20:39:36 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Sep 2015 20:39:36 -0000 Subject: [GHC] #10825: Poor performance of optimized code. Message-ID: <047.7261042eeb6a92f89b4e63b1da792373@haskell.org> #10825: Poor performance of optimized code. -------------------------------------+------------------------------------- Reporter: AndriusS | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: #8814, #8835 Differential Revisions: | -------------------------------------+------------------------------------- This is possible duplicate of #8814, #8835. I am creating new ticket as I have fairly small example with no dependencies. The problem is that optimized code runs orders of magnitude slower than non-optimized. {{{#!hs import System.IO.Unsafe (unsafePerformIO) newtype MyList = MyList Int equalsLast :: MyList -> Int -> Bool equalsLast (MyList value) = (== value) fromList :: [Int] -> MyList fromList = MyList . last {- minimizing imports -} (<$>) = fmap replicateM' n x = sequence (replicate n x) readInt = read <$> getLine :: IO Int readAndMap :: Int -> (Int->Bool) -> IO [Bool] readAndMap n f = replicateM' n (f <$> readInt) {- if readAndMap is replaced by commented out line below, the problem goes away -} --readAndMap n f = map f <$> replicateM' n (readInt) fromList' :: [Int] -> MyList {- an attempt to further demostrate the issue. fromList'=fromList is very slow as well -} fromList' list = unsafePerformIO $ do putStrLn "fromList" return $ fromList list readMyList :: Int -> IO MyList readMyList n = fromList' <$> (replicateM' n $ read <$> getLine) main :: IO () main = do n1 <- read <$> getLine :: IO Int n2 <- read <$> getLine :: IO Int l <- readMyList n1 ans <- readAndMap n2 (equalsLast l) mapM_ print ans }}} If this code is compiled with no flags, it prints "fromList" once and runs in 0.3s. Compiled with "-O" prints "fromList" many times and takes over 6 seconds. Here's a Haskell script to generate input for program above: {{{#!hs main = sequence_ $ map print (n:n:[1..n]++[1..n]) where n = 10000 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 1 21:31:39 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Sep 2015 21:31:39 -0000 Subject: [GHC] #10820: Provide a way to detect what extensions are enabled via TH In-Reply-To: <045.fdd68b124ff34a39c484baed79715ead@haskell.org> References: <045.fdd68b124ff34a39c484baed79715ead@haskell.org> Message-ID: <060.3b0c3bcfc67fee671650a4ca7013f6b0@haskell.org> #10820: Provide a way to detect what extensions are enabled via TH -------------------------------------+------------------------------------- Reporter: spinda | Owner: spinda Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | th/T18020.hs Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1200 -------------------------------------+------------------------------------- Changes (by spinda): * owner: => spinda * testcase: => th/T18020.hs * differential: => Phab:D1200 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 1 21:46:56 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Sep 2015 21:46:56 -0000 Subject: [GHC] #10825: Poor performance of optimized code. In-Reply-To: <047.7261042eeb6a92f89b4e63b1da792373@haskell.org> References: <047.7261042eeb6a92f89b4e63b1da792373@haskell.org> Message-ID: <062.3179ece00b4c629e073f38b1579555c8@haskell.org> #10825: Poor performance of optimized code. -------------------------------------+------------------------------------- Reporter: AndriusS | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8814, #8835 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * owner: => bgamari Comment: Ooh, this looks like a very nice case to put on my performance-related- issues queue. Thanks for the small testcase. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 1 21:49:54 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Sep 2015 21:49:54 -0000 Subject: [GHC] #10825: Poor performance of optimized code. In-Reply-To: <047.7261042eeb6a92f89b4e63b1da792373@haskell.org> References: <047.7261042eeb6a92f89b4e63b1da792373@haskell.org> Message-ID: <062.3efc3a53236f2dee7c3b739df7ab6891@haskell.org> #10825: Poor performance of optimized code. -------------------------------------+------------------------------------- Reporter: AndriusS | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8814, #8835 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): Does `-fno-state-hack` make a difference? Since I see `replicateM` stuff. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 2 01:52:56 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Sep 2015 01:52:56 -0000 Subject: [GHC] #10486: Allow addTopDecls to create annotations In-Reply-To: <045.12d45e4d0a4bb9ca79be29175909ed59@haskell.org> References: <045.12d45e4d0a4bb9ca79be29175909ed59@haskell.org> Message-ID: <060.c2b5dd61ad0503bc1a19acbf9a034da5@haskell.org> #10486: Allow addTopDecls to create annotations -------------------------------------+------------------------------------- Reporter: spinda | Owner: spinda Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | testsuite/tests/annotations/should_compile/th/ Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1201 -------------------------------------+------------------------------------- Changes (by spinda): * owner: => spinda * testcase: => testsuite/tests/annotations/should_compile/th/ * differential: => Phab:D1201 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 2 02:20:13 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Sep 2015 02:20:13 -0000 Subject: [GHC] #10826: [Security] Safe Haskell can be bypassed via annotations Message-ID: <045.6042fe6f9f535df81b6d3e710bdd3ea9@haskell.org> #10826: [Security] Safe Haskell can be bypassed via annotations -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- {{{ module Test (hook) where import System.Process import System.IO.Unsafe {-# ANN hook (unsafePerformIO (putStrLn "Woops.")) #-} hook = undefined }}} {{{ ? Test ghc -fpackage-trust -XSafe Test_simple.hs [1 of 1] Compiling Test_simple ( Test_simple.hs, Test_simple.o ) [flags changed] Woops. Test_simple.hs:4:1: System.IO.Unsafe: Can't be safely imported! The module itself isn't safe. }}} GHC ultimately rejects the program due to the {{{System.IO.Unsafe}}} import, but this check doesn't occur until GHC has compiled and run the annotation expression, allowing arbitrary IO operations via {{{unsafePerformIO}}}. The solution is probably to move the import check from the end of renaming/typechecking to the start. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 2 02:22:30 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Sep 2015 02:22:30 -0000 Subject: [GHC] #10826: [Security] Safe Haskell can be bypassed via annotations In-Reply-To: <045.6042fe6f9f535df81b6d3e710bdd3ea9@haskell.org> References: <045.6042fe6f9f535df81b6d3e710bdd3ea9@haskell.org> Message-ID: <060.f314b59491598da4131152a80b643a15@haskell.org> #10826: [Security] Safe Haskell can be bypassed via annotations -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by spinda: Old description: > {{{ > module Test (hook) where > > import System.Process > import System.IO.Unsafe > > {-# ANN hook (unsafePerformIO (putStrLn "Woops.")) #-} > hook = undefined > }}} > > {{{ > ? Test ghc -fpackage-trust -XSafe Test_simple.hs > [1 of 1] Compiling Test_simple ( Test_simple.hs, Test_simple.o ) > [flags changed] > Woops. > > Test_simple.hs:4:1: > System.IO.Unsafe: Can't be safely imported! > The module itself isn't safe. > }}} > > GHC ultimately rejects the program due to the {{{System.IO.Unsafe}}} > import, but this check doesn't occur until GHC has compiled and run the > annotation expression, allowing arbitrary IO operations via > {{{unsafePerformIO}}}. > > The solution is probably to move the import check from the end of > renaming/typechecking to the start. New description: {{{ module Test (hook) where import System.IO.Unsafe {-# ANN hook (unsafePerformIO (putStrLn "Woops.")) #-} hook = undefined }}} {{{ ? Test ghc -fpackage-trust -XSafe Test_simple.hs [1 of 1] Compiling Test_simple ( Test_simple.hs, Test_simple.o ) [flags changed] Woops. Test_simple.hs:4:1: System.IO.Unsafe: Can't be safely imported! The module itself isn't safe. }}} GHC ultimately rejects the program due to the {{{System.IO.Unsafe}}} import, but this check doesn't occur until GHC has compiled and run the annotation expression, allowing arbitrary IO operations via {{{unsafePerformIO}}}. The solution is probably to move the import check from the end of renaming/typechecking to the start. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 2 03:25:30 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Sep 2015 03:25:30 -0000 Subject: [GHC] #10819: Can't generate data decls deriving multiparam type classes with TH In-Reply-To: <045.f6bd7f45fafc0112a449414b624abe97@haskell.org> References: <045.f6bd7f45fafc0112a449414b624abe97@haskell.org> Message-ID: <060.c1f274f834b2deac8b6314e1d4a3e711@haskell.org> #10819: Can't generate data decls deriving multiparam type classes with TH -------------------------------------+------------------------------------- Reporter: spinda | Owner: spinda Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | th/T18019.hs Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1202 -------------------------------------+------------------------------------- Changes (by spinda): * testcase: => th/T18019.hs * owner: => spinda * differential: => Phab:D1202 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 2 05:41:32 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Sep 2015 05:41:32 -0000 Subject: [GHC] #10825: Poor performance of optimized code. In-Reply-To: <047.7261042eeb6a92f89b4e63b1da792373@haskell.org> References: <047.7261042eeb6a92f89b4e63b1da792373@haskell.org> Message-ID: <062.92e06cc215e8101f672ef63467c9c419@haskell.org> #10825: Poor performance of optimized code. -------------------------------------+------------------------------------- Reporter: AndriusS | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8814, #8835 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by AndriusS): Yes, with `-fno-state-hack` everything works fine. This is probably a duplicate of #1168. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 2 06:28:28 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Sep 2015 06:28:28 -0000 Subject: [GHC] #10827: GHCi should support interpeting multiple packages/units with separate DynFlags Message-ID: <045.56917c0b2dd940e5429ceefba9639e36@haskell.org> #10827: GHCi should support interpeting multiple packages/units with separate DynFlags -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: GHC API | Version: 7.11 Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Stack and other tools are attempting to make the user-experience of developing multiple packages simultaneously better. Thus, if you have source packages p, q and r (which all depend on them), `stack build` builds all of them. They are quite interested in support `stack ghci` but there are problems: https://github.com/commercialhaskell/stack/issues/665 The essence of the problem is twofold: 1. If you ask GHCi to interpret modules from multiple packages (e.g. by having multiple source directories), GHCi currently only knows how to put all of them into the same home package. This will fail if two packages have a module with the same name; also, modules in the other packages will always see modules (even if they're supposed to be hidden). 2. A GHCi session only has one global set of dynamic flags, but each package may be compiled with its own set of DynFlags (e.g. package global LANGUAGE pragmas). This means the "default DynFlags" needs to be varied between packages. It's not too obvious to me how to fix (1) (at least, you'd have to make the HPT support sets of HomeModInfos from multiple packages), but (2) seems tractable: since we already track DynFlags on a per-module basis, we just have to arrange for a "package" level DynFlag to be applied to the correct ModSummarys. Similar functionality would be useful for Backpack. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 2 07:53:25 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Sep 2015 07:53:25 -0000 Subject: [GHC] #10828: TH can't represent all GADTs in its AST Message-ID: <045.8ead8c05c9800a5f7ba9e24f2356aece@haskell.org> #10828: TH can't represent all GADTs in its AST -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Template | Version: 7.10.2 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- For example, it's impossible to add a kind signature on a data type with `DataD`. In {{{Con}}} I believe it's possible to encode GADT constructor signatures using {{{NormalC}}} (haven't tried this yet), but ideally there would be another constructor specific to GADTs to go along with {{{RecC}}}, {{{InfixC}}}, and {{{ForallC}}}. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 2 08:10:56 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Sep 2015 08:10:56 -0000 Subject: [GHC] #10826: [Security] Safe Haskell can be bypassed via annotations In-Reply-To: <045.6042fe6f9f535df81b6d3e710bdd3ea9@haskell.org> References: <045.6042fe6f9f535df81b6d3e710bdd3ea9@haskell.org> Message-ID: <060.614cb8a11088ea75ad9d6b443e66bf07@haskell.org> #10826: [Security] Safe Haskell can be bypassed via annotations -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * cc: dterei (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 2 08:15:22 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Sep 2015 08:15:22 -0000 Subject: [GHC] #10826: [Security] Safe Haskell can be bypassed via annotations In-Reply-To: <045.6042fe6f9f535df81b6d3e710bdd3ea9@haskell.org> References: <045.6042fe6f9f535df81b6d3e710bdd3ea9@haskell.org> Message-ID: <060.6c5bbe6ad1c78a9d0d7be039e9ea90a2@haskell.org> #10826: [Security] Safe Haskell can be bypassed via annotations -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by spinda): I should note that checking imports after renaming/typechecking, instead of before, also opens up nasty possibilities with QuasiQuoters, since Safe Haskell leaves them enabled (despite disabling the rest of Template Haskell). I have a more involved proof of concept that uses these two in conjunction to both execute arbitrary IO operations and delve into the GHC internals through a QuasiQuoter to mark arbitrary modules as safe. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 2 11:22:42 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Sep 2015 11:22:42 -0000 Subject: [GHC] #5273: error and undefined should print a location In-Reply-To: <047.0c5631d5110d7e8dd17fdeae86e25a82@haskell.org> References: <047.0c5631d5110d7e8dd17fdeae86e25a82@haskell.org> Message-ID: <062.fa9b9ed839d5301e11e2d67ef05d40d3@haskell.org> #5273: error and undefined should print a location -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: feature request | Status: patch Priority: low | Milestone: 7.12.1 Component: Compiler | Version: 7.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 9049 | Differential Revisions: Phab:D861 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"6740d70d95cb81cea3859ff847afc61ec439db4f/ghc" 6740d70d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6740d70d95cb81cea3859ff847afc61ec439db4f" Use IP based CallStack in error and undefined This patch modifies `error`, `undefined`, and `assertError` to use implicit call-stacks to provide better error messages to users. There are a few knock-on effects: - `GHC.Classes.IP` is now wired-in so it can be used in the wired-in types for `error` and `undefined`. - `TysPrim.tyVarList` has been replaced with a new function `TysPrim.mkTemplateTyVars`. `tyVarList` made it easy to introduce subtle bugs when you need tyvars of different kinds. The naive ``` tv1 = head $ tyVarList kind1 tv2 = head $ tyVarList kind2 ``` would result in `tv1` and `tv2` sharing a `Unique`, thus substitutions would be applied incorrectly, treating `tv1` and `tv2` as the same tyvar. `mkTemplateTyVars` avoids this pitfall by taking a list of kinds and producing a single tyvar of each kind. - The types `GHC.SrcLoc.SrcLoc` and `GHC.Stack.CallStack` now live in ghc-prim. - The type `GHC.Exception.ErrorCall` has a new constructor `ErrorCallWithLocation` that takes two `String`s instead of one, the 2nd one being arbitrary metadata about the error (but usually the call-stack). A bi-directional pattern synonym `ErrorCall` continues to provide the old API. Updates Cabal, array, and haddock submodules. Reviewers: nh2, goldfire, simonpj, hvr, rwbarton, austin, bgamari Reviewed By: simonpj Subscribers: rwbarton, rodlogic, goldfire, maoe, simonmar, carter, liyang, bgamari, thomie Differential Revision: https://phabricator.haskell.org/D861 GHC Trac Issues: #5273 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 2 11:23:23 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Sep 2015 11:23:23 -0000 Subject: [GHC] #5273: error and undefined should print a location In-Reply-To: <047.0c5631d5110d7e8dd17fdeae86e25a82@haskell.org> References: <047.0c5631d5110d7e8dd17fdeae86e25a82@haskell.org> Message-ID: <062.0fdd8bef9850005cb18110a1b1ca7527@haskell.org> #5273: error and undefined should print a location -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: feature request | Status: closed Priority: low | Milestone: 7.12.1 Component: Compiler | Version: 7.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 9049 | Differential Revisions: Phab:D861 -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 2 11:45:15 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Sep 2015 11:45:15 -0000 Subject: [GHC] #5273: error and undefined should print a location In-Reply-To: <047.0c5631d5110d7e8dd17fdeae86e25a82@haskell.org> References: <047.0c5631d5110d7e8dd17fdeae86e25a82@haskell.org> Message-ID: <062.d5c4f0fa62701689a00b13745f6a0c49@haskell.org> #5273: error and undefined should print a location -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: feature request | Status: closed Priority: low | Milestone: 7.12.1 Component: Compiler | Version: 7.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 9049 | Differential Revisions: Phab:D861 -------------------------------------+------------------------------------- Comment (by bgamari): One remaining question here is how this should interact with DWARF-based stacktraces (see Phab:D1198). The two mechanisms exhibit different strengths, * IP-based stacktraces: * Always accurate * Cheap to gather stack but have small effect on code generation * Can only provide limited stack depth * DWARF-based stacktraces: * May not point you at exactly the right place * More expensive to gather stack but no effect on code generation * Can provide full stack (but perhaps it's best if we capped the depth to avoid costly unwinding of deep stacks) * Requires that code be built with `-g` Given they are to some extent complementary, perhaps we should produce both if available? Note: technically there are two costs to DWARF stack collection: 1. Unwinding the stack: the task of actually walking the stack and collection the relevant addresses 2. Looking up the addresses: the task of looking up symbol names and source location information for the addresses we collected in step 1. In my experience (2) tend to be much more expensive than (1). In Phab:D1198 step (2) should occur lazily, so it will only be paid if the necessary. Step (1) however necessarily happens unconditionally. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 2 11:49:20 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Sep 2015 11:49:20 -0000 Subject: [GHC] #10413: Incorrect offsets for array size indexing In-Reply-To: <048.fb282c815f959019fb8541a09f28e9ea@haskell.org> References: <048.fb282c815f959019fb8541a09f28e9ea@haskell.org> Message-ID: <063.d7fd91ebed3b8f9772fdf85327722983@haskell.org> #10413: Incorrect offsets for array size indexing -------------------------------------+------------------------------------- Reporter: fryguybob | Owner: fryguybob Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.1 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1194 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"010e1878c9c851a638211a03fd58bfa6bdd93081/ghc" 010e187/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="010e1878c9c851a638211a03fd58bfa6bdd93081" Fix trac #10413 Test Plan: Validate. Reviewers: austin, tibbe, bgamari Reviewed By: tibbe, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1194 GHC Trac Issues: #10413 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 2 11:49:20 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Sep 2015 11:49:20 -0000 Subject: [GHC] #10777: Overlong linker arguments on Windows leads to broken builds with confusing error messages In-Reply-To: <047.046a9f83230d0273c9346cd501403845@haskell.org> References: <047.046a9f83230d0273c9346cd501403845@haskell.org> Message-ID: <062.bdb77c09e6b5d19c0a6adfe3d392b367@haskell.org> #10777: Overlong linker arguments on Windows leads to broken builds with confusing error messages -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: snoyberg Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #8596 #9685 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"296bc70b5ff6c853f2782e9ec5aa47a52110345e/ghc" 296bc70/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="296bc70b5ff6c853f2782e9ec5aa47a52110345e" Use a response file for linker command line arguments #10777 On Windows, we're constrained to 32k bytes total for command line arguments. When building large projects, this limit can be exceeded. This patch changes GHC to always use response files for linker arguments, a feature first used by Microsoft compilers and added to GCC (over a decade ago). Alternatives here include: * Only use this method on Windows systems * Check the length of the command line arguments and use that to decide whether to use this method I did not pursue either of these, as I believe it would make the patch more likely to break in less tested situations. Test Plan: Confirm that linking still works in general. Ideally: compile a very large project on Windows with this patch. (I am attempting to do that myself now, but having trouble getting the Windows build tool chain up and running.) Reviewers: goldfire, hvr, rwbarton, austin, thomie, bgamari, Phyx Reviewed By: thomie, bgamari, Phyx Subscribers: erikd, awson, #ghc_windows_task_force, thomie Differential Revision: https://phabricator.haskell.org/D1158 GHC Trac Issues: #8596, #10777 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 2 11:49:20 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Sep 2015 11:49:20 -0000 Subject: [GHC] #8596: Add support for "reponse files" to workaround Windows command line length limitations In-Reply-To: <047.4af16120e3d32bd0dd2986d2dd5dd2de@haskell.org> References: <047.4af16120e3d32bd0dd2986d2dd5dd2de@haskell.org> Message-ID: <062.fbe26b724663f0fc7bfa42063988f8c4@haskell.org> #8596: Add support for "reponse files" to workaround Windows command line length limitations -------------------------------------+------------------------------------- Reporter: joeyhess | Owner: snoyberg Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10777 #9685 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"296bc70b5ff6c853f2782e9ec5aa47a52110345e/ghc" 296bc70/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="296bc70b5ff6c853f2782e9ec5aa47a52110345e" Use a response file for linker command line arguments #10777 On Windows, we're constrained to 32k bytes total for command line arguments. When building large projects, this limit can be exceeded. This patch changes GHC to always use response files for linker arguments, a feature first used by Microsoft compilers and added to GCC (over a decade ago). Alternatives here include: * Only use this method on Windows systems * Check the length of the command line arguments and use that to decide whether to use this method I did not pursue either of these, as I believe it would make the patch more likely to break in less tested situations. Test Plan: Confirm that linking still works in general. Ideally: compile a very large project on Windows with this patch. (I am attempting to do that myself now, but having trouble getting the Windows build tool chain up and running.) Reviewers: goldfire, hvr, rwbarton, austin, thomie, bgamari, Phyx Reviewed By: thomie, bgamari, Phyx Subscribers: erikd, awson, #ghc_windows_task_force, thomie Differential Revision: https://phabricator.haskell.org/D1158 GHC Trac Issues: #8596, #10777 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 2 11:55:31 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Sep 2015 11:55:31 -0000 Subject: [GHC] #10486: Allow addTopDecls to create annotations In-Reply-To: <045.12d45e4d0a4bb9ca79be29175909ed59@haskell.org> References: <045.12d45e4d0a4bb9ca79be29175909ed59@haskell.org> Message-ID: <060.40f7b8397356ac1e2949da98e5873795@haskell.org> #10486: Allow addTopDecls to create annotations -------------------------------------+------------------------------------- Reporter: spinda | Owner: spinda Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | testsuite/tests/annotations/should_compile/th/ Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1201 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"ba5554ec2753cc41f5e087a91f23e1f612a9eb29/ghc" ba5554ec/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ba5554ec2753cc41f5e087a91f23e1f612a9eb29" Allow annotations though addTopDecls (#10486) addTopDecls restricts what declarations it can be used to add. Adding annotations via this method works fine with no special changes apart from adding AnnD to the declaration whitelist. Test Plan: validate Reviewers: austin, goldfire, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1201 GHC Trac Issues: #10486 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 2 12:06:54 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Sep 2015 12:06:54 -0000 Subject: [GHC] #10486: Allow addTopDecls to create annotations In-Reply-To: <045.12d45e4d0a4bb9ca79be29175909ed59@haskell.org> References: <045.12d45e4d0a4bb9ca79be29175909ed59@haskell.org> Message-ID: <060.8146eb6f7702451234abedc451bf7c1a@haskell.org> #10486: Allow addTopDecls to create annotations -------------------------------------+------------------------------------- Reporter: spinda | Owner: spinda Type: feature request | Status: closed Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | testsuite/tests/annotations/should_compile/th/ Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1201 -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 2 12:10:02 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Sep 2015 12:10:02 -0000 Subject: [GHC] #10413: Incorrect offsets for array size indexing In-Reply-To: <048.fb282c815f959019fb8541a09f28e9ea@haskell.org> References: <048.fb282c815f959019fb8541a09f28e9ea@haskell.org> Message-ID: <063.068ca03cca8cf3df51edf43ea2f952bc@haskell.org> #10413: Incorrect offsets for array size indexing -------------------------------------+------------------------------------- Reporter: fryguybob | Owner: fryguybob Type: task | Status: merge Priority: low | Milestone: Component: Compiler | Version: 7.10.1 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1194 -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 2 13:39:26 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Sep 2015 13:39:26 -0000 Subject: [GHC] #10047: inconsistency in name binding between splice and quasiquotation In-Reply-To: <047.467ed7feed46ef69006cfd30a0e1c7fb@haskell.org> References: <047.467ed7feed46ef69006cfd30a0e1c7fb@haskell.org> Message-ID: <062.2a0ef0f91c7394b9794d0535405ff708@haskell.org> #10047: inconsistency in name binding between splice and quasiquotation -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: spinda Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: th/T10047 Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1199 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"c8f623e305ec0a51ac2406a1f754d244e05b96f5/ghc" c8f623e3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c8f623e305ec0a51ac2406a1f754d244e05b96f5" Expand declaration QQs first (#10047) Declaration QuasiQuoters do not cause a group split like $(...) splices, and are run and expanded before other declarations in the group. Resolves the lingering issue with #10047, and fixes broken tests qq007 and qq008. Test Plan: validate Reviewers: goldfire, austin, bgamari Reviewed By: bgamari Subscribers: goldfire, simonpj, thomie, spinda Differential Revision: https://phabricator.haskell.org/D1199 GHC Trac Issues: #10047 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 2 15:36:51 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Sep 2015 15:36:51 -0000 Subject: [GHC] #10829: Simplification in the RHS of rules Message-ID: <046.7ca7c028ab82ec2d7ad263cb88680067@haskell.org> #10829: Simplification in the RHS of rules -------------------------------------+------------------------------------- Reporter: afarmer | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: 10528 Differential Revisions: | -------------------------------------+------------------------------------- HERMIT users depend on RULES to specify equational properties. 7.10.2 performed both inlining and simplification in both sides of the rules, meaning they can't really be used for this. This breaks most HERMIT use cases. Note that this behavior was a change from 7.8 and prior, due to this commit: https://git.haskell.org/ghc.git/commitdiff/8af219adb914b292d0f8c737fe0a1e3f7fb19cf3 The following commit disables the inlining/simplification in the LHS of rules, which fixes half the problem, but it has yet to be merged and released (attached to ticket #10528): https://git.haskell.org/ghc.git/commitdiff/bc4b64ca5b99bff6b3d5051b57cb2bc52bd4c841 This ticket is to ask that inlining/simplification also be disabled in the RHS of rules. As an example of what is happening, we are seeing rules like this: {{{ repH :: [a] -> [a] -> [a] {-# RULES "repH ++" [~] forall xs ys. repH (xs ++ ys) = repH xs . repH ys #-} }}} get to HERMIT as: {{{ "repH ++" forall xs ys. repH (xs ++ ys) = let f = repH xs g = repH ys in \ z -> f (g z) }}} In this case it is just an unfolding of composition, but some rules get rather gross on the RHS. The extra junk makes equational reasoning with these rules very fiddly and sort of breaks the correspondence with the source-level code. For instance, it is almost impossible to apply these right-to-left, which is a common thing to do when performing equational reasoning. Some possible solutions: 1. Don't inline/apply rules in the RHS at all (just like the LHS). 2. Don't inline/apply rules in the RHS of rules marked with the NeverActive notation (rules intended for HERMIT use are generally marked NeverActive). Since NeverActive rules are not applied by GHC anyway, this should actually save compile-time work and not affect real programs/rules. Would either of those be acceptable/possible? Option 1 would be ideal, because it would match the behavior of 7.8 (AFAICT). Option 2 would be sufficient, however. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 2 15:37:16 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Sep 2015 15:37:16 -0000 Subject: [GHC] #10828: TH can't represent all GADTs in its AST In-Reply-To: <045.8ead8c05c9800a5f7ba9e24f2356aece@haskell.org> References: <045.8ead8c05c9800a5f7ba9e24f2356aece@haskell.org> Message-ID: <060.f1110fc414a046ff80b618e4c372e3d7@haskell.org> #10828: TH can't represent all GADTs in its AST -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): I believe the TH AST is fully expressive here (with one tiny caveat). It's just clunky. Take {{{ data T :: k -> * -> * where MkT :: T x Int }}} To encode into TH, you transform the definition to this: {{{ data T (a1 :: k) (a2 :: *) = forall . a2 ~ Int => MkT }}} which has a direct translation. The one tiny caveat is the new feature for deriving `Foldable` for GADTs, which distinguishes among the two forms above. (I can't find a reference to this change. Can you? It was described at Haskell Implementors' Workshop a few days ago. You, the reader, if you know the reference, please add it!) Is it worth refactoring the TH types to handle GADTs more directly? Perhaps. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 2 15:37:49 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Sep 2015 15:37:49 -0000 Subject: [GHC] #10828: TH can't represent all GADTs in its AST In-Reply-To: <045.8ead8c05c9800a5f7ba9e24f2356aece@haskell.org> References: <045.8ead8c05c9800a5f7ba9e24f2356aece@haskell.org> Message-ID: <060.91bfa9c73146cb85a702a7794cd09ddf@haskell.org> #10828: TH can't represent all GADTs in its AST -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * milestone: => 7.12.1 Comment: In any case, let's decide what to do and do it by the next release. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 2 15:39:43 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Sep 2015 15:39:43 -0000 Subject: [GHC] #10829: Simplification in the RHS of rules In-Reply-To: <046.7ca7c028ab82ec2d7ad263cb88680067@haskell.org> References: <046.7ca7c028ab82ec2d7ad263cb88680067@haskell.org> Message-ID: <061.d35e8fc60ba5c00ebb04557cf0eb597d@haskell.org> #10829: Simplification in the RHS of rules -------------------------------------+------------------------------------- Reporter: afarmer | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 10528 | Differential Revisions: -------------------------------------+------------------------------------- Description changed by afarmer: Old description: > HERMIT users depend on RULES to specify equational properties. > > 7.10.2 performed both inlining and simplification in both sides of the > rules, meaning they can't really be used for this. This breaks most > HERMIT use cases. Note that this behavior was a change from 7.8 and > prior, due to this commit: > > https://git.haskell.org/ghc.git/commitdiff/8af219adb914b292d0f8c737fe0a1e3f7fb19cf3 > > The following commit disables the inlining/simplification in the LHS of > rules, which fixes half the problem, but it has yet to be merged and > released (attached to ticket #10528): > > https://git.haskell.org/ghc.git/commitdiff/bc4b64ca5b99bff6b3d5051b57cb2bc52bd4c841 > > This ticket is to ask that inlining/simplification also be disabled in > the RHS of rules. > > As an example of what is happening, we are seeing rules like this: > > {{{ > repH :: [a] -> [a] -> [a] > > {-# RULES "repH ++" [~] forall xs ys. repH (xs ++ ys) = repH xs . repH ys > #-} > }}} > > get to HERMIT as: > > {{{ > "repH ++" forall xs ys. repH (xs ++ ys) = let f = repH xs > g = repH ys > in \ z -> f (g z) > }}} > > In this case it is just an unfolding of composition, but some rules get > rather gross on the RHS. The extra junk makes equational reasoning with > these rules very fiddly and sort of breaks the correspondence with the > source-level code. For instance, it is almost impossible to apply these > right-to-left, which is a common thing to do when performing equational > reasoning. > > Some possible solutions: > > 1. Don't inline/apply rules in the RHS at all (just like the LHS). > > 2. Don't inline/apply rules in the RHS of rules marked with the > NeverActive notation (rules intended for HERMIT use are generally marked > NeverActive). Since NeverActive rules are not applied by GHC anyway, this > should actually save compile-time work and not affect real > programs/rules. > > Would either of those be acceptable/possible? Option 1 would be ideal, > because it would match the behavior of 7.8 (AFAICT). Option 2 would be > sufficient, however. New description: HERMIT users depend on RULES to specify equational properties. 7.10.2 performed both inlining and simplification in both sides of the rules, meaning they can't really be used for this. This breaks most HERMIT use cases. Note that this behavior was a change from 7.8 and prior, due to this commit: https://git.haskell.org/ghc.git/commitdiff/8af219adb914b292d0f8c737fe0a1e3f7fb19cf3 The following commit disables the inlining/simplification in the LHS of rules, which fixes half the problem, but it has yet to be merged and released (attached to ticket #10528): https://git.haskell.org/ghc.git/commitdiff/bc4b64ca5b99bff6b3d5051b57cb2bc52bd4c841 This ticket is to ask that inlining/simplification also be disabled in the RHS of rules. As an example of what is happening, we are seeing rules like this: {{{ repH :: [a] -> [a] -> [a] {-# RULES "repH ++" [~] forall xs ys. repH (xs ++ ys) = repH xs . repH ys #-} }}} get to HERMIT as: {{{ "repH ++" forall xs ys. repH (xs ++ ys) = let f = repH xs g = repH ys in \ z -> f (g z) }}} In this case it is just an unfolding of composition, but some rules get rather gross on the RHS. The extra junk makes equational reasoning with these rules very fiddly and breaks the correspondence with the source- level code. For instance, it is almost impossible to apply these right-to- left, which is a common thing to do when performing equational reasoning. Some possible solutions: 1. Don't inline/apply rules in the RHS at all (just like the LHS). 2. Don't inline/apply rules in the RHS of rules marked with the NeverActive notation (rules intended for HERMIT use are generally marked NeverActive). Since NeverActive rules are not applied by GHC anyway, this should actually save compile-time work and not affect real programs/rules. Would either of those be acceptable/possible? Option 1 would be ideal, because it would match the behavior of 7.8 (AFAICT). Option 2 would be sufficient, however. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 2 15:46:27 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Sep 2015 15:46:27 -0000 Subject: [GHC] #10528: compile time performance regression with OverloadedStrings and Text In-Reply-To: <048.98ab82d16d4bd14b388cfa4fc2b927d4@haskell.org> References: <048.98ab82d16d4bd14b388cfa4fc2b927d4@haskell.org> Message-ID: <063.d9085cab4663dd7155940f80900de39c@haskell.org> #10528: compile time performance regression with OverloadedStrings and Text -------------------------------------+------------------------------------- Reporter: jakewheat | Owner: Type: bug | Status: merge Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * cc: bgamari (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 2 16:40:11 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Sep 2015 16:40:11 -0000 Subject: [GHC] #10828: TH can't represent all GADTs in its AST In-Reply-To: <045.8ead8c05c9800a5f7ba9e24f2356aece@haskell.org> References: <045.8ead8c05c9800a5f7ba9e24f2356aece@haskell.org> Message-ID: <060.48c50d60150a56e06adfab5d7b810d9f@haskell.org> #10828: TH can't represent all GADTs in its AST -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by spinda): re: kind signatures -- ah, you're right. It is a bit clunky, but perhaps not worth a breaking change to the structure of {{{DataD}}} improve. Although, if #10819 makes it in, then it could be worth slipping this in at the same time. I hadn't heard about the new {{{Foldable}}} deriving feature. Any reference to that would be helpful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 2 16:40:38 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Sep 2015 16:40:38 -0000 Subject: [GHC] #10828: TH could do a better job of representing GADTs (was: TH can't represent all GADTs in its AST) In-Reply-To: <045.8ead8c05c9800a5f7ba9e24f2356aece@haskell.org> References: <045.8ead8c05c9800a5f7ba9e24f2356aece@haskell.org> Message-ID: <060.69d1ea78ef4db6882c459b3aebfe2a8c@haskell.org> #10828: TH could do a better job of representing GADTs -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 2 16:49:09 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Sep 2015 16:49:09 -0000 Subject: [GHC] #10712: Regression: make TEST=exceptionsrun001 WAY=optasm is failing In-Reply-To: <045.e7e6b1fe63913ee0ef5a119e69380bb4@haskell.org> References: <045.e7e6b1fe63913ee0ef5a119e69380bb4@haskell.org> Message-ID: <060.9ee4371903d5bf1864cb3ff58d666699@haskell.org> #10712: Regression: make TEST=exceptionsrun001 WAY=optasm is failing -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | base/tests/exceptionsrun001 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"3b233793b2131c1c77be3b2d81f48e569c422439/ghc" 3b233793/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3b233793b2131c1c77be3b2d81f48e569c422439" Testsuite: mark 4 tests expect_broken_for(#10712, opt_ways) Please revert when #10712 is fixed. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 2 17:09:32 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Sep 2015 17:09:32 -0000 Subject: [GHC] #10829: Simplification in the RHS of rules In-Reply-To: <046.7ca7c028ab82ec2d7ad263cb88680067@haskell.org> References: <046.7ca7c028ab82ec2d7ad263cb88680067@haskell.org> Message-ID: <061.5c8c1d28bace3e834a51d92b5ad4ec31@haskell.org> #10829: Simplification in the RHS of rules -------------------------------------+------------------------------------- Reporter: afarmer | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 10528 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 2 20:23:39 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Sep 2015 20:23:39 -0000 Subject: [GHC] #10830: maximumBy has a space leak Message-ID: <051.80712d357123f27d6467f28abef6100b@haskell.org> #10830: maximumBy has a space leak -------------------------------------+------------------------------------- Reporter: | Owner: NeilMitchell | Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.10.2 libraries/base | Keywords: | Operating System: Windows Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Given the program: {{{#!hs import Data.List main = print $ maximumBy compare [1..10000] }}} Compiling with {{{-O2}}}, on GHC 7.8.3 this runs in constant stack space (works fine with {{{+RTS -K1K}}}). With GHC 7.10.2 I get: {{{ $ ghc --make Test.hs -O2 -rtsopts [1 of 1] Compiling Main ( Test.hs, Test.o ) Linking Test.exe ... $ Test +RTS -K100K Stack space overflow: current size 33680 bytes. Use `+RTS -Ksize -RTS' to increase it. }}} Not sure why it's failing at 33K instead of 100K, but it's certainly taking more than 1K as GHC 7.8.3 did. See #3416 for previous discussion of this issue. My guess is that in older versions of GHC the strictness analysis managed to kick in and optimise things. With the burnt bridges that no longer works. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 2 20:44:28 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Sep 2015 20:44:28 -0000 Subject: [GHC] #10830: maximumBy has a space leak In-Reply-To: <051.80712d357123f27d6467f28abef6100b@haskell.org> References: <051.80712d357123f27d6467f28abef6100b@haskell.org> Message-ID: <066.98024da9e1a44976b55a412e0bd55447@haskell.org> #10830: maximumBy has a space leak -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): Possible duplicate of #10788? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 2 20:50:56 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Sep 2015 20:50:56 -0000 Subject: [GHC] #10830: maximumBy has a space leak In-Reply-To: <051.80712d357123f27d6467f28abef6100b@haskell.org> References: <051.80712d357123f27d6467f28abef6100b@haskell.org> Message-ID: <066.38363feb3a808781909683ba907654f6@haskell.org> #10830: maximumBy has a space leak -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by NeilMitchell): I don't think so - maximum doesn't have a space leak, but maximumBy does, therefore it's a very different result. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 2 20:57:38 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Sep 2015 20:57:38 -0000 Subject: [GHC] #10831: DeriveFunctor not capable of deriving when wrapping Either Message-ID: <048.8298ed09a98386a50539acd12ba36fa5@haskell.org> #10831: DeriveFunctor not capable of deriving when wrapping Either -------------------------------------+------------------------------------- Reporter: htebalaka | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: MacOS X Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- GHC can derive Functor for Okay, but rejects the equivalent Bad. {{{#!hs {-# LANGUAGE DeriveFunctor #-} data Okay f g a b = Inl (f a b) | Inr (g a b) deriving (Functor) newtype Bad f g a b = Bad (Either (f a b) (g a b)) deriving (Functor) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 2 21:25:28 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Sep 2015 21:25:28 -0000 Subject: [GHC] #10823: Expose keepAlive to Template Haskell In-Reply-To: <045.57db4451919a86b3fcad053f0c16d552@haskell.org> References: <045.57db4451919a86b3fcad053f0c16d552@haskell.org> Message-ID: <060.08b633fe1ee1adb265a0ee39955df8d3@haskell.org> #10823: Expose keepAlive to Template Haskell -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): It's a bit of a hack, but there's a workaround here. Define this in some available module: {{{ data Anything = forall a. Mk a class KeepAlive (what :: Symbol) where whatToKeep :: proxy what -> Anything }}} And then generate this using existing TH: {{{ instance KeepAlive "gt" where whatToKeep _ = Mk gt }}} Then GHC will mark `gt` as used. This is ugly, but it should work well in practice. In the effort to keep TH from bloating too much, I would lean against adding new features to support operations that can be simulated well today. Feel free to try to convince me otherwise -- I'm not dead set in this position. But I'm worried about feature creep here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 2 21:26:00 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Sep 2015 21:26:00 -0000 Subject: [GHC] #10823: Expose keepAlive to Template Haskell In-Reply-To: <045.57db4451919a86b3fcad053f0c16d552@haskell.org> References: <045.57db4451919a86b3fcad053f0c16d552@haskell.org> Message-ID: <060.2cd4ed654be0e458afe1730587a005e0@haskell.org> #10823: Expose keepAlive to Template Haskell -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * milestone: => 7.12.1 Comment: We should either do it or abandon this by the next release. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 2 21:57:43 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Sep 2015 21:57:43 -0000 Subject: [GHC] #10823: Expose keepAlive to Template Haskell In-Reply-To: <045.57db4451919a86b3fcad053f0c16d552@haskell.org> References: <045.57db4451919a86b3fcad053f0c16d552@haskell.org> Message-ID: <060.d1872c5af75ab42f782f4f3d96ce9887@haskell.org> #10823: Expose keepAlive to Template Haskell -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by spinda): Is the use of type-level literals essential here? That requires the user to have {{{DataKinds}}} enabled. Otherwise, the hack can fill our use case, I think. On the other hand, I worry about Template Haskell code having to depend too much on tricks that happen to work but aren't a guaranteed, stable, documented part of the interface. See, for example, the issue with quasiquoter behavior that appeared in #10047: suddenly, the "trick" that quasiquoters didn't split declaration groups went away, because it wasn't part of the actual spec. By contrast, functionality exposed through an explicit piece of the Template Haskell API will not suddenly disappear as a consequence of a tangential patch. //That said//, as I write this, I've realized that there may be another way to approach our particular issue. {{{[lq| inline gt |]}}} attaches an annotation to {{{gt}}}, so perhaps the solution should be to tell the desugarer not to consider any function with an annotation attached as dead code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 2 22:56:18 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Sep 2015 22:56:18 -0000 Subject: [GHC] #10830: maximumBy has a space leak In-Reply-To: <051.80712d357123f27d6467f28abef6100b@haskell.org> References: <051.80712d357123f27d6467f28abef6100b@haskell.org> Message-ID: <066.2009406c8bd030d8830cc765347f9bee@haskell.org> #10830: maximumBy has a space leak -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): In 7.8, the core is nice and fully inlined: {{{#!hs Rec { main_lgo main_lgo = \ z_a1k8 ds2_a1k9 -> case ds2_a1k9 of _ { [] -> z_a1k8; : x_a1kh xs_a1ki -> case compareInteger z_a1k8 x_a1kh of _ { __DEFAULT -> main_lgo x_a1kh xs_a1ki; GT -> main_lgo z_a1k8 xs_a1ki } } end Rec } }}} In HEAD, we have a call to `foldr1`: {{{#!hs main5 = \ x_a2pT y_a2pU -> case compareInteger x_a2pT y_a2pU of _ { __DEFAULT -> y_a2pU; GT -> x_a2pT } main2 = enumDeltaToInteger1 main4 main3 main1 = \ eta_B1 -> case foldr1 main5 main2 of _ { __DEFAULT -> (# eta_B1, () #) } }}} I think you are right that this is some BBP-fallout. Note that `maximumBy` is implemented in `Data.Foldable` using `foldr1`. If I make `foldr1` inlinable (by using a local worker), I get {{{#!hs Rec { -- RHS size: {terms: 19, types: 9, coercions: 0} main_go main_go = \ ds2_a1Fi eta_a1Fj -> case ds2_a1Fi of _ { [] -> eta_a1Fj; : y_a1Fr ys_a1Fs -> case compareInteger eta_a1Fj y_a1Fr of _ { __DEFAULT -> main_go ys_a1Fs y_a1Fr; GT -> main_go ys_a1Fs eta_a1Fj } } end Rec } }}} which is equivalent to the 7.8 code. Given that we inline `foldr`, I do not see a reason not to inline `foldr1`. DR coming soon... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 2 23:00:31 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Sep 2015 23:00:31 -0000 Subject: [GHC] #10830: maximumBy has a space leak In-Reply-To: <051.80712d357123f27d6467f28abef6100b@haskell.org> References: <051.80712d357123f27d6467f28abef6100b@haskell.org> Message-ID: <066.756623b0559bda5cd997ff3c6e465b52@haskell.org> #10830: maximumBy has a space leak -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1205 -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => patch * differential: => Phab:D1205 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 2 23:04:28 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Sep 2015 23:04:28 -0000 Subject: [GHC] #10830: maximumBy has a space leak In-Reply-To: <051.80712d357123f27d6467f28abef6100b@haskell.org> References: <051.80712d357123f27d6467f28abef6100b@haskell.org> Message-ID: <066.751e85a6819699d84085f079f7dfa2b1@haskell.org> #10830: maximumBy has a space leak -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1205 -------------------------------------+------------------------------------- Comment (by thomie): > Not sure why it's failing at 33K instead of 100K See #10445. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 3 03:54:15 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Sep 2015 03:54:15 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.06ead30d4ec7c1d89f20d47f646986de@haskell.org> #6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: | TypeFamilies, Injective Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4259 | Differential Revisions: Phab:D202 -------------------------------------+------------------------------------- Comment (by Jan Stolarek ): In [changeset:"374457809de343f409fbeea0a885877947a133a2/ghc" 37445780/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="374457809de343f409fbeea0a885877947a133a2" Injective type families For details see #6018, Phab:D202 and the wiki page: https://ghc.haskell.org/trac/ghc/wiki/InjectiveTypeFamilies This patch also wires-in Maybe data type and updates haddock submodule. Test Plan: ./validate Reviewers: simonpj, goldfire, austin, bgamari Subscribers: mpickering, bgamari, alanz, thomie, goldfire, simonmar, carter Differential Revision: https://phabricator.haskell.org/D202 GHC Trac Issues: #6018 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 3 03:57:45 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Sep 2015 03:57:45 -0000 Subject: [GHC] #10830: maximumBy has a space leak In-Reply-To: <051.80712d357123f27d6467f28abef6100b@haskell.org> References: <051.80712d357123f27d6467f28abef6100b@haskell.org> Message-ID: <066.56d1d0fc44ad750ef26394c5e328cc51@haskell.org> #10830: maximumBy has a space leak -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1205 -------------------------------------+------------------------------------- Comment (by NeilMitchell): @thomie: Note that #10445 are instances of GHC failing at a higher stack size than you requested, while above is an example of it failing at a lower stack size. Not sure if that makes it different or not though. Thanks @nomeata! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 3 03:59:40 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Sep 2015 03:59:40 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.142597f1df8c16c4f705ab3c37576fec@haskell.org> #6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature request | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.4.1 Resolution: fixed | Keywords: | TypeFamilies, Injective Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T6018, | T6018fail, T6018rnfail, T6018th, | T6018failclosed1, T6018failclosed2, | T6018failclosed3, T6018failclosed4, | T6018failclosed5, T6018failclosed6, | T6018failclosed7, T6018failclosed8, | T6018failclosed9, | T6018failclosed10, | T6018failclosed11, | T6018failclosed12, T6018ghci, | T6018ghcifail, T6018ghcirnfail Blocked By: | Blocking: Related Tickets: #4259 | Differential Revisions: Phab:D202 -------------------------------------+------------------------------------- Changes (by jstolarek): * testcase: => T6018, T6018fail, T6018rnfail, T6018th, T6018failclosed1, T6018failclosed2, T6018failclosed3, T6018failclosed4, T6018failclosed5, T6018failclosed6, T6018failclosed7, T6018failclosed8, T6018failclosed9, T6018failclosed10, T6018failclosed11, T6018failclosed12, T6018ghci, T6018ghcifail, T6018ghcirnfail * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 3 04:05:56 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Sep 2015 04:05:56 -0000 Subject: [GHC] #10832: Generalize injective type families Message-ID: <048.1487f224b00112fe37d31a1812a748a4@haskell.org> #10832: Generalize injective type families -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.11 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- With injective type families we can now declare that type family result determines the arguments. But ITFs are not yet as expressive as functional dependencies. For example with FDs I can say: {{{#!hs data Nat = Zero | Succ a class Add a b r | a b -> r, r a -> b instance Add Zero b b instance (Add a b r) => Add (Succ a) b (Succ r) }}} Here we declare that the result and the first argument taken together uniquely determine the second argument. This is not currently possible with ITFs: {{{#!hs type family AddTF a b = r | r a -> b where AddTF Zero b = b AddTF (Succ a) b = Succ (AddTF a b) }}} But we want to be able to say that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 3 04:40:36 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Sep 2015 04:40:36 -0000 Subject: [GHC] #10833: Use injective type families when dealing with givens Message-ID: <048.a87fa063590f3f8feefba56badb8ff21@haskell.org> #10833: Use injective type families when dealing with givens -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #6018 Differential Revisions: | -------------------------------------+------------------------------------- Consider this code: {{{#!hs type family Id a = r | r -> a id :: (Id a ~ Id b) => a -> b id x = x }}} GHC currently rejects it because it does not use type family injectivity information when dealing with the given constraints. Implementing this requires changing Core. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 3 04:40:48 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Sep 2015 04:40:48 -0000 Subject: [GHC] #10832: Generalize injective type families In-Reply-To: <048.1487f224b00112fe37d31a1812a748a4@haskell.org> References: <048.1487f224b00112fe37d31a1812a748a4@haskell.org> Message-ID: <063.ac7c3381b7a410031f4e6604ea0735a5@haskell.org> #10832: Generalize injective type families -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #6018 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by jstolarek): * related: => #6018 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 3 04:41:09 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Sep 2015 04:41:09 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.b2a08c545faf09de8fbdde47729fcadb@haskell.org> #6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature request | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.4.1 Resolution: fixed | Keywords: | TypeFamilies, Injective Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T6018, | T6018fail, T6018rnfail, T6018th, | T6018failclosed1, T6018failclosed2, | T6018failclosed3, T6018failclosed4, | T6018failclosed5, T6018failclosed6, | T6018failclosed7, T6018failclosed8, | T6018failclosed9, | T6018failclosed10, | T6018failclosed11, | T6018failclosed12, T6018ghci, | T6018ghcifail, T6018ghcirnfail Blocked By: | Blocking: Related Tickets: #4259, #10832, | Differential Revisions: Phab:D202 #10833 | -------------------------------------+------------------------------------- Changes (by jstolarek): * related: #4259 => #4259, #10832, #10833 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 3 05:11:00 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Sep 2015 05:11:00 -0000 Subject: [GHC] #10834: Test suite: Resistance against CallStack line number changes Message-ID: <046.372e1ba74666ffe2b42f459bc5880774@haskell.org> #10834: Test suite: Resistance against CallStack line number changes -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Hi, I just got this: {{{ Actual stderr output differs from expected: --- ./ghci/scripts/T10501.stderr.normalised 2015-09-03 00:20:22.622940998 +0000 +++ ./ghci/scripts/T10501.run.stderr.normalised 2015-09-03 00:20:22.622940998 +0000 @@ -1,6 +1,6 @@ *** Exception: Prelude.head: empty list CallStack: - error, called at libraries/base/GHC/List.hs:1009:3 in base:GHC.List + error, called at libraries/base/GHC/List.hs:1011:3 in base:GHC.List *** Exception: Prelude.undefined CallStack: error, called at libraries/base/GHC/Err.hs:42:14 in base:GHC.Err *** unexpected failure for T10501(ghci) }}} Having the test suite so fragile is annoying. Would it be possible to ignore line number differences in call stacks? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 3 06:37:26 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Sep 2015 06:37:26 -0000 Subject: [GHC] #10826: [Security] Safe Haskell can be bypassed via annotations In-Reply-To: <045.6042fe6f9f535df81b6d3e710bdd3ea9@haskell.org> References: <045.6042fe6f9f535df81b6d3e710bdd3ea9@haskell.org> Message-ID: <060.98905a83a65013e6ce54ff2af7eff8d3@haskell.org> #10826: [Security] Safe Haskell can be bypassed via annotations -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * priority: normal => highest * milestone: => 7.10.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 3 06:50:18 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Sep 2015 06:50:18 -0000 Subject: [GHC] #1830: Automatic derivation of Lift In-Reply-To: <044.3eb409743bc4021eb94e63cb46f573bc@haskell.org> References: <044.3eb409743bc4021eb94e63cb46f573bc@haskell.org> Message-ID: <059.db3950b5220f33b4af4478f4d5203311@haskell.org> #1830: Automatic derivation of Lift -------------------------------------+------------------------------------- Reporter: guest | Owner: | RyanGlScott Type: feature request | Status: new Priority: normal | Milestone: ? Component: Template Haskell | Version: 6.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1168 -------------------------------------+------------------------------------- Comment (by goldfire): Following on from Simon's comment:14, I think it would be helpful to see a discussion of `-XDeriveLift` on a forum/mailing list. I do see there's lots of packages that use `th-lift`, but perhaps these packages and their authors are quite happy continuing to do so. I think Simon and I just want to make sure there's more than one lone ranger out there who wants this before the GHC Team commits to maintaining it into perpetuity! :) Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 3 07:05:52 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Sep 2015 07:05:52 -0000 Subject: [GHC] #10823: Expose keepAlive to Template Haskell In-Reply-To: <045.57db4451919a86b3fcad053f0c16d552@haskell.org> References: <045.57db4451919a86b3fcad053f0c16d552@haskell.org> Message-ID: <060.8800fa2d16dbc193d2f49f35ce010efb@haskell.org> #10823: Expose keepAlive to Template Haskell -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:4 spinda]: > Is the use of type-level literals essential here? That requires the user to have {{{DataKinds}}} enabled. Otherwise, the hack can fill our use case, I think. No. It's just a convenient way to make sure that the instance head is unique. Any such mechanism should work. > > On the other hand, I worry about Template Haskell code having to depend too much on tricks that happen to work but aren't a guaranteed, stable, documented part of the interface. Agreed. Except that this is depending on a guaranteed, stable, documented feature: that ''all'' instance are always exported from a module. Thus if a definition is mentioned in an instance, GHC will never drop it. So this isn't a TH hack so much, but a GHC language hack. > //That said//, as I write this, I've realized that there may be another way to approach our particular issue. {{{[lq| inline gt |]}}} attaches an annotation to {{{gt}}}, so perhaps the solution should be to tell the desugarer not to consider any function with an annotation attached as dead code. This is ''much'' better. Care to repurpose the ticket? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 3 07:17:23 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Sep 2015 07:17:23 -0000 Subject: [GHC] #10823: Don't mark functions with annotations as dead (was: Expose keepAlive to Template Haskell) In-Reply-To: <045.57db4451919a86b3fcad053f0c16d552@haskell.org> References: <045.57db4451919a86b3fcad053f0c16d552@haskell.org> Message-ID: <060.f82fe1368796279a584629eb8a8406ae@haskell.org> #10823: Don't mark functions with annotations as dead -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Old description: > {{{keepAlive}}} is a > [https://github.com/ghc/ghc/blob/efa7b3a474bc373201ab145c129262a73c86f959/compiler/typecheck/TcRnMonad.hs#L1276 > function in TcRnMonad] that adds a {{{Name}}} to the set of {{{Name}}}s > to keep when pruning out dead code. > > A concrete use case for exposing this to Template Haskell is in > LiquidHaskell, which will soon function as a Core plugin. In > LiquidHaskell, a subset of Haskell functions can be "lifted" to the logic > level and used in types. For example: > > {{{ > module Test (ok) where > > [lq| inline gt |] > gt x y = x > y > > [lq| ok :: x:Int -> { v:Int | gt x v } |] > ok x = x + 1 > }}} > > LiquidHaskell runs a transformation from the {{{CoreBind}}} for {{{gt}}} > to its internal representation of decidable logic. Since Core plugins are > run after "dead" code is removed at the end of desugaring, and since > {{{gt}}} is not exported, the {{{CoreBind}}} for {{{gt}}} would not reach > the {{{CoreBinds}}} LH receives as a Core plugin. > > The solution for this is to be able to mark names with {{{keepAlive}}} > from Template Haskell. > > Proposed specification: > > {{{ > keepAlive :: Name -> Q () > }}} > > where {{{Name}}} is a Template Haskell {{{Name}}}. New description: A concrete example is in LiquidHaskell, which will soon function as a Core plugin. In LiquidHaskell, a subset of Haskell functions can be "lifted" to the logic level and used in types. For example: {{{ module Test (ok) where [lq| inline gt |] gt x y = x > y [lq| ok :: x:Int -> { v:Int | gt x v } |] ok x = x + 1 }}} {{{[lq| inline gt |]}}} generates an annotation on {{{gt}}}, which LiquidHaskell picks up at the plugin stage. It then tries to run a transformation from the {{{CoreBind}}} for {{{gt}}} to its internal representation of decidable logic. But since Core plugins are run after "dead" code is removed at the end of desugaring, and since {{{gt}}} is not exported, the {{{CoreBind}}} for {{{gt}}} does not reach the {{{CoreBinds}}} LH receives as a Core plugin. The solution for this is to prevent the desugarer from discarding {{{CoreBinds}}} for things with attached annotations. -- Comment (by spinda): Agreed. Except that this is depending on a guaranteed, stable, documented feature: that all instance are always exported from a module. Thus if a definition is mentioned in an instance, GHC will never drop it. So this isn't a TH hack so much, but a GHC language hack. Good point. Although, I think "instance are always exported from a module" may not be 100% true in the presence of Backpack, but it should be true enough for this to continue to work. This is much better. Care to repurpose the ticket? Done. The fix for the new issue should be much easier to implement anyway. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 3 10:30:37 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Sep 2015 10:30:37 -0000 Subject: [GHC] #10835: Regression in standalone Data deriving for phantom types Message-ID: <048.e488f2f2d397e40d5fcfbc59cce5f092@haskell.org> #10835: Regression in standalone Data deriving for phantom types -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Thise code {{{#!hs {-# LANGUAGE DeriveDataTypeable, StandaloneDeriving, PolyKinds #-} module M where import Data.Data import Data.Typeable data Phantom t = Phantom deriving Typeable deriving instance Typeable t => Data (Phantom t) }}} compiles with 7.8.4 but not with 7.10.2. The error is {{{ data.hs:8:1: Could not deduce (Typeable Phantom) arising from the superclasses of an instance declaration from the context (Typeable t) bound by the instance declaration at data.hs:8:1-48 In the instance declaration for ?Data (Phantom t)? }}} PolyKinds here is a hack I came up with to make this compile with 7.8; but ideally, this code should compile whether PolyKinds is enabled or not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 3 10:41:57 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Sep 2015 10:41:57 -0000 Subject: [GHC] #10835: Regression in standalone Data deriving for phantom types In-Reply-To: <048.e488f2f2d397e40d5fcfbc59cce5f092@haskell.org> References: <048.e488f2f2d397e40d5fcfbc59cce5f092@haskell.org> Message-ID: <063.058987a09005d02b8f928b8aea176a93@haskell.org> #10835: Regression in standalone Data deriving for phantom types -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by Feuerbach: Old description: > Thise code > > {{{#!hs > {-# LANGUAGE DeriveDataTypeable, StandaloneDeriving, PolyKinds #-} > module M where > import Data.Data > import Data.Typeable > > data Phantom t = Phantom > deriving Typeable > deriving instance Typeable t => Data (Phantom t) > > }}} > > compiles with 7.8.4 but not with 7.10.2. The error is > > {{{ > data.hs:8:1: > Could not deduce (Typeable Phantom) > arising from the superclasses of an instance declaration > from the context (Typeable t) > bound by the instance declaration at data.hs:8:1-48 > In the instance declaration for ?Data (Phantom t)? > }}} > > PolyKinds here is a hack I came up with to make this compile with 7.8; > but ideally, this code should compile whether PolyKinds is enabled or > not. New description: Thise code {{{#!hs {-# LANGUAGE DeriveDataTypeable, StandaloneDeriving, PolyKinds #-} module M where import Data.Data import Data.Typeable data Phantom t = Phantom deriving Typeable deriving instance Typeable t => Data (Phantom t) }}} compiles with 7.8.4 but not with 7.10.2. The error is {{{ data.hs:8:1: Could not deduce (Typeable Phantom) arising from the superclasses of an instance declaration from the context (Typeable t) bound by the instance declaration at data.hs:8:1-48 In the instance declaration for ?Data (Phantom t)? }}} PolyKinds here is a hack I came up with to make this compile with 7.8 (without it, the code doesn't compile with either version); but ideally, this code should compile whether PolyKinds is enabled or not. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 3 13:07:24 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Sep 2015 13:07:24 -0000 Subject: [GHC] #10834: Test suite: Resistance against CallStack line number changes In-Reply-To: <046.372e1ba74666ffe2b42f459bc5880774@haskell.org> References: <046.372e1ba74666ffe2b42f459bc5880774@haskell.org> Message-ID: <061.0556b0325bf71d6fdf47ba81b464fb69@haskell.org> #10834: Test suite: Resistance against CallStack line number changes -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Test Suite | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: Phab:D1206 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch * related: => Phab:D1206 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 3 14:49:32 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Sep 2015 14:49:32 -0000 Subject: [GHC] #10834: Test suite: Resistance against CallStack line number changes In-Reply-To: <046.372e1ba74666ffe2b42f459bc5880774@haskell.org> References: <046.372e1ba74666ffe2b42f459bc5880774@haskell.org> Message-ID: <061.8cc229c0a9e27ee00e0108bcffdbc593@haskell.org> #10834: Test suite: Resistance against CallStack line number changes -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Test Suite | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: Phab:D1206 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): Heh, I knew I could rely on you, thomie. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 3 16:12:48 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Sep 2015 16:12:48 -0000 Subject: [GHC] #10823: Don't mark functions with annotations as dead In-Reply-To: <045.57db4451919a86b3fcad053f0c16d552@haskell.org> References: <045.57db4451919a86b3fcad053f0c16d552@haskell.org> Message-ID: <060.b12b17138fdd5fd115a9ff1743fbd47f@haskell.org> #10823: Don't mark functions with annotations as dead -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): > `[lq| inline gt |]` attaches an annotation to gt, so perhaps the solution should be to tell the desugarer not to consider any function with an annotation attached as dead code. I'd be happy with that. But can you remind us HOW `lq` "attaches an annotation"? It it documented in the user manual? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 3 17:19:42 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Sep 2015 17:19:42 -0000 Subject: [GHC] #10836: Better error reporting for closed type families Message-ID: <048.66b5b5c8ba8fcc7fd5bf86c3bc169961@haskell.org> #10836: Better error reporting for closed type families -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Consider this code: {{{#!hs {-# LANGUAGE TypeFamilies #-} module Bug where type family Foo a = r | r -> a type instance Foo Int = Int type instance Foo Bool = Int type family Bar a = r | r -> a type instance Bar Int = Int type instance Bar Bool = Int }}} Both definitions are incorrect as they violate their injectivity annotation. When I compile the module GHC reports errors on both definitons: {{{ Bug.hs:9:15: error: Type family equations violate injectivity annotation: Foo Bool = Int Foo Int = Int Bug.hs:13:15: error: Type family equations violate injectivity annotation: Bar Bool = Int Bar Int = Int }}} When I convert these to closed type families: {{{#!hs {-# LANGUAGE TypeFamilies #-} module Bug where type family Foo a = r | r -> a where Foo Int = Int Foo Bool = Int type family Bar a = r | r -> a where Bar Int = Int Bar Bool = Int }}} GHC only reports error on `Foo` but not on `Bar`: {{{ Bug.hs:8:5: error: Type family equations violate injectivity annotation: Foo Int = Int Foo Bool = Int In the equations for closed type family ?Foo? In the type family declaration for ?Foo? }}} Only when I fix the error on `Foo` I get the error on `Bar`. This is mostly annoying. A spectacular example of when this is really a problem can be seen in the testsuite: for open type families all the failing injectivity tests are in one test `T6018fail` but for closed type families there are twelve separate tests (`T6018closedfail01` through `T6018closedfail12`). I pinned down the problem to these lines in `TcTyClsDecls.tcTyClGroup`: {{{#!hs ; checkNoErrs $ mapM_ (recoverM (return ()) . checkValidTyCl) tyclss -- We recover, which allows us to report multiple validity errors -- the checkNoErrs is necessary to fix #7175. }}} As stated by the comment, removing `checkNoErrs` fixes the problem but breaks #7175. Commit message for d0ddde58f928a6b156d8061c406226c4fbb7cd22 suggests that this can't be easily fixed. Richard Eisenberg also remarks: "It's all about the irrefutable pattern in `rejigConRes` for matching up result types of GADTs." -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 3 17:27:58 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Sep 2015 17:27:58 -0000 Subject: [GHC] #10836: Better error reporting for closed type families In-Reply-To: <048.66b5b5c8ba8fcc7fd5bf86c3bc169961@haskell.org> References: <048.66b5b5c8ba8fcc7fd5bf86c3bc169961@haskell.org> Message-ID: <063.435822b52ff30e4582a0f021128939e6@haskell.org> #10836: Better error reporting for closed type families -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: T10836 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by jstolarek): * testcase: => T10836 Comment: I added a test case (expected to fail). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 3 20:34:48 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Sep 2015 20:34:48 -0000 Subject: [GHC] #10837: Constant-time indexing of closed type family axioms Message-ID: <048.d99ce2299f3cf4c3e12cff389baa1f66@haskell.org> #10837: Constant-time indexing of closed type family axioms -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Right now `CoAxiom` stores a list of `CoAxBranch`es in a `BranchList`. But it would be useful to actually have a constant-time indexing into axioms. One code fragment when I really wanted to have this feature is in `TcValidity.checkValidCoAxiom`: {{{#!hs -- Replace n-th element in the list. Assumes 0-based indexing. replace_br :: [CoAxBranch] -> Int -> CoAxBranch -> [CoAxBranch] replace_br brs n br = take n brs ++ [br] ++ drop (n+1) brs }}} I believe this code could be rewritten in a much more efficient way using constant-time indexing. The new data structure should most likely have a type that indicates whether the axiom is branched or not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 3 21:09:28 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Sep 2015 21:09:28 -0000 Subject: [GHC] #10838: hsig files don't have good enough error checking for wired-in types Message-ID: <045.41f34a07c7f54dad24eaa71df940bd49@haskell.org> #10838: hsig files don't have good enough error checking for wired-in types -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (Type checker) | Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- If I have the signature: {{{ {-# LANGUAGE NoImplicitPrelude #-} module MyPrelude where data Int a }}} And I compile it with `ghc MyPrelude.hsig -sig-of "MyPrelude is base:Prelude"` this won't actually give an error, despite `Int` having the wrong kind. The bug seems to be because `Int` is wired in and this case is not handled. Filing this so I don't forget to fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 3 21:43:28 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Sep 2015 21:43:28 -0000 Subject: [GHC] #10823: Don't mark functions with annotations as dead In-Reply-To: <045.57db4451919a86b3fcad053f0c16d552@haskell.org> References: <045.57db4451919a86b3fcad053f0c16d552@haskell.org> Message-ID: <060.aa735dc53d83163064d95eec4f81e22b@haskell.org> #10823: Don't mark functions with annotations as dead -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by spinda): {{{lq}}} is a [https://hackage.haskell.org/package/template- haskell-2.5.0.0/docs/Language-Haskell-TH-Quote.html#t:QuasiQuoter QuasiQuoter], and in the declaration context it produces a list of {{{Dec}}} containing a {{{PragmaD (AnnP (ValueAnnotation (mkName "gt")) IsInline)}}}. GHC picks this up, converts it to {{{HsDecl}}}, and feeds it through the renaming/typechecking phase along with all the other declarations in the group. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 3 22:05:01 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Sep 2015 22:05:01 -0000 Subject: [GHC] #10834: Test suite: Resistance against CallStack line number changes In-Reply-To: <046.372e1ba74666ffe2b42f459bc5880774@haskell.org> References: <046.372e1ba74666ffe2b42f459bc5880774@haskell.org> Message-ID: <061.7ad1eed09609208e8a3dd337da680186@haskell.org> #10834: Test suite: Resistance against CallStack line number changes -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Test Suite | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: Phab:D1206 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"79cdb2544d2c68050dbd147936a31e8eb06a4c67/ghc" 79cdb25/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="79cdb2544d2c68050dbd147936a31e8eb06a4c67" Testsuite: ignore line number differences in call stacks (#10834) Differential Revision: https://phabricator.haskell.org/D1206 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 3 22:06:11 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Sep 2015 22:06:11 -0000 Subject: [GHC] #10834: Test suite: Resistance against CallStack line number changes In-Reply-To: <046.372e1ba74666ffe2b42f459bc5880774@haskell.org> References: <046.372e1ba74666ffe2b42f459bc5880774@haskell.org> Message-ID: <061.fe9a04b515e807165341002422acbb26@haskell.org> #10834: Test suite: Resistance against CallStack line number changes -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Test Suite | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: Phab:D1206 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => closed * resolution: => fixed * milestone: => 7.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 3 23:36:49 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Sep 2015 23:36:49 -0000 Subject: [GHC] #10823: Don't mark functions with annotations as dead In-Reply-To: <045.57db4451919a86b3fcad053f0c16d552@haskell.org> References: <045.57db4451919a86b3fcad053f0c16d552@haskell.org> Message-ID: <060.b0254fe8c309274aa9a7afe10afb1562@haskell.org> #10823: Don't mark functions with annotations as dead -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Can this be reproduced without TH? If a definition is mentioned only in an annotation, will it still be marked as dead? Regardless, a minimal example demonstrating this would be great. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 3 23:43:04 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Sep 2015 23:43:04 -0000 Subject: [GHC] #10839: Consistent pretty-printing of type families Message-ID: <048.28810866bbeb92c031eb9149a92b094c@haskell.org> #10839: Consistent pretty-printing of type families -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.11 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Say I have this silly open type family declaration: {{{#!hs type family F a type instance F a = a type instance F a = Int }}} GHC complains: {{{ Foo.hs:8:15: error: Conflicting family instance declarations: F a -- Defined at Foo.hs:8:15 F a -- Defined at Foo.hs:9:15 }}} Now let's do some silliness with a closed type family: {{{#!hs type family F a where F a = a F a = Int }}} GHC warns: {{{ T6018.hs:9:5: warning: Type family instance equation is overlapped: F a = Int }}} Finally, some silliness with a kind-polymorphic type family: {{{#!hs type family Gc (a :: k) (b :: k) = r | r -> k where Gc a b = Int }}} GHC complains: {{{ T6018.hs:9:5: error: Type family equation violates injectivity annotation. Injective kind variable ?k? is not inferable from the RHS type variables. In the RHS of type family equation: forall (k :: BOX) (a :: k) (b :: k). Gc a b = Int In the equations for closed type family ?Gc? In the type family declaration for ?Gc? }}} There are some inconsistencies in pprinting of type family equations: * for open type families we print the location where the equation was defined but we do not print the RHS * for closed type families we print the RHS but we do not print the location in the source file * kind-polymorphic equations are not indented I would like to have a consistent pretty-printing of type family equations, one that prints the RHS, source code location and indents kind- polymorphic equations. The difference in pretty printing between open and closed type families comes from the difference between pprinting `CoAxBranch` and `FamInst`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 4 00:02:22 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Sep 2015 00:02:22 -0000 Subject: [GHC] #10823: Don't mark functions with annotations as dead In-Reply-To: <045.57db4451919a86b3fcad053f0c16d552@haskell.org> References: <045.57db4451919a86b3fcad053f0c16d552@haskell.org> Message-ID: <060.e637bdb39b62ac8a378011380edb0aa3@haskell.org> #10823: Don't mark functions with annotations as dead -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Old description: > A concrete example is in LiquidHaskell, which will soon function as a > Core plugin. In LiquidHaskell, a subset of Haskell functions can be > "lifted" to the logic level and used in types. For example: > > {{{ > module Test (ok) where > > [lq| inline gt |] > gt x y = x > y > > [lq| ok :: x:Int -> { v:Int | gt x v } |] > ok x = x + 1 > }}} > > {{{[lq| inline gt |]}}} generates an annotation on {{{gt}}}, which > LiquidHaskell picks up at the plugin stage. It then tries to run a > transformation from the {{{CoreBind}}} for {{{gt}}} to its internal > representation of decidable logic. But since Core plugins are run after > "dead" code is removed at the end of desugaring, and since {{{gt}}} is > not exported, the {{{CoreBind}}} for {{{gt}}} does not reach the > {{{CoreBinds}}} LH receives as a Core plugin. > > The solution for this is to prevent the desugarer from discarding > {{{CoreBinds}}} for things with attached annotations. New description: A concrete example is in LiquidHaskell, which will soon function as a Core plugin. In LiquidHaskell, a subset of Haskell functions can be "lifted" to the logic level and used in types. For example: {{{ module Test (ok) where [lq| inline gt |] gt x y = x > y [lq| ok :: x:Int -> { v:Int | gt x v } |] ok x = x + 1 }}} {{{[lq| inline gt |]}}} generates an annotation on {{{gt}}}, which LiquidHaskell picks up at the plugin stage. It then tries to run a transformation from the {{{CoreBind}}} for {{{gt}}} to its internal representation of decidable logic. But since Core plugins are run after "dead" code is removed at the end of desugaring, and since {{{gt}}} is not exported, the {{{CoreBind}}} for {{{gt}}} does not reach the {{{CoreBinds}}} LH receives as a Core plugin. The solution for this is to prevent the desugarer from discarding {{{CoreBinds}}} for things with attached annotations. ---- Minimal example (without TH): {{{ module AnnTest (thing) where {-# ANN thing False #-} thing :: Int thing = 7 }}} {{{ ? ghc -O0 -ddump-simpl AnnTest.hs [1 of 1] Compiling AnnTest ( AnnTest.hs, AnnTest.o ) ==================== Simplified expression ==================== GHC.Desugar.toAnnotationWrapper @ GHC.Types.Bool Data.Data.$fDataBool GHC.Types.False ==================== Tidy Core ==================== Result size of Tidy Core = {terms: 3, types: 1, coercions: 0} thing :: Int [GblId, Caf=NoCafRefs, Str=DmdType] thing = GHC.Types.I# 7 }}} {{{ module AnnTest () where {-# ANN thing False #-} thing :: Int thing = 7 }}} {{{ ? ghc -O0 -ddump-simpl AnnTest.hs [1 of 1] Compiling AnnTest ( AnnTest.hs, AnnTest.o ) ==================== Simplified expression ==================== GHC.Desugar.toAnnotationWrapper @ GHC.Types.Bool Data.Data.$fDataBool GHC.Types.False ==================== Tidy Core ==================== Result size of Tidy Core = {terms: 0, types: 0, coercions: 0} }}} -- Comment (by spinda): Yes, it can be reproduced without TH. Minimal example attached to the ticket description. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 4 00:12:27 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Sep 2015 00:12:27 -0000 Subject: [GHC] #10830: maximumBy has a space leak In-Reply-To: <051.80712d357123f27d6467f28abef6100b@haskell.org> References: <051.80712d357123f27d6467f28abef6100b@haskell.org> Message-ID: <066.8a3358db0b2fa769dca7cfee9ad25d40@haskell.org> #10830: maximumBy has a space leak -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1205 -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"85915e9b73a662f3cc474323ec370d4f61817474/ghc" 85915e9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="85915e9b73a662f3cc474323ec370d4f61817474" Make Data.List.foldr1 inline Previously, foldr1 would be defiend recursively and thus not inline. This is bad, for example, when maximumBy has a strict comparison function: Before the BBP, it was implemented via foldl1, which inlined and yielded good code. With BBP, it goes via foldr1, so we better inline this as well. Fixes #10830. Differential Revision: https://phabricator.haskell.org/D1205 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 4 00:13:01 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Sep 2015 00:13:01 -0000 Subject: [GHC] #10830: maximumBy has a space leak In-Reply-To: <051.80712d357123f27d6467f28abef6100b@haskell.org> References: <051.80712d357123f27d6467f28abef6100b@haskell.org> Message-ID: <066.e7a12f3a33d8526f33dd2644594367c9@haskell.org> #10830: maximumBy has a space leak -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1205 -------------------------------------+------------------------------------- Changes (by nomeata): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 4 00:14:43 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Sep 2015 00:14:43 -0000 Subject: [GHC] #10830: maximumBy has a space leak In-Reply-To: <051.80712d357123f27d6467f28abef6100b@haskell.org> References: <051.80712d357123f27d6467f28abef6100b@haskell.org> Message-ID: <066.93251f1ed106a7816c0834238e2d4ffa@haskell.org> #10830: maximumBy has a space leak -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1205 -------------------------------------+------------------------------------- Comment (by rwbarton): Is #10788 related, btw? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 4 00:18:45 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Sep 2015 00:18:45 -0000 Subject: [GHC] #10830: maximumBy has a space leak In-Reply-To: <051.80712d357123f27d6467f28abef6100b@haskell.org> References: <051.80712d357123f27d6467f28abef6100b@haskell.org> Message-ID: <066.9ae2b093277fb220d86a42ca7fb68f0f@haskell.org> #10830: maximumBy has a space leak -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.3 Component: libraries/base | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1205 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: => 7.10.3 Comment: If 7.10.3 ever exists (no commitment!), then this should go in. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 4 00:23:03 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Sep 2015 00:23:03 -0000 Subject: [GHC] #10823: Don't mark functions with annotations as dead In-Reply-To: <045.57db4451919a86b3fcad053f0c16d552@haskell.org> References: <045.57db4451919a86b3fcad053f0c16d552@haskell.org> Message-ID: <060.1920552fa5fca809f4b67c10fab3db95@haskell.org> #10823: Don't mark functions with annotations as dead -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): I don't really understand why "Don't mark functions with annotations as dead" is sensible behavior, given the totally general-purpose nature of annotations. For example if I used a plugin that uses annotations in one of the ways mentioned on the Wiki page * Store extra information relevant to a plugin but which is added by that plugin itself, such as a strictness analysis plugin that adds a demand signature to functions, which can be inspected later on by the same plugin when it comes to compile modules that depend on that one I wouldn't expect or want every function to be kept live as a side effect. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 4 00:28:58 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Sep 2015 00:28:58 -0000 Subject: [GHC] #10823: Don't mark functions with annotations as dead In-Reply-To: <045.57db4451919a86b3fcad053f0c16d552@haskell.org> References: <045.57db4451919a86b3fcad053f0c16d552@haskell.org> Message-ID: <060.ffba97c7ee6b8037752c11144e201640@haskell.org> #10823: Don't mark functions with annotations as dead -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): It would be nice if you could just refer to `gt`-the-value from an annotation on `ok` to keep `gt` live (because `ok` is live), but I don't understand annotations enough to know whether that works or could work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 4 00:57:08 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Sep 2015 00:57:08 -0000 Subject: [GHC] #10823: Don't mark functions with annotations as dead In-Reply-To: <045.57db4451919a86b3fcad053f0c16d552@haskell.org> References: <045.57db4451919a86b3fcad053f0c16d552@haskell.org> Message-ID: <060.4d1c6f4e2fbd2a05c31d6801e2d9e80a@haskell.org> #10823: Don't mark functions with annotations as dead -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by spinda): It would be nice if you could just refer to gt-the-value from an annotation on ok to keep gt live (because ok is live), but I don't understand annotations enough to know whether that works or could work. I think it could, but annotation payloads (including names within them) are just arbitrary values, so this would require walking the tree of the data and trying to pull out uses of TH's {{{Name}}} constructor. That might get hairy. I don't really understand why "Don't mark functions with annotations as dead" is sensible behavior, given the totally general-purpose nature of annotations. You're right, this wouldn't necessarily make sense for all annotations. In the end, I think the trick suggested by goldfire would be fine for LiquidHaskell's particular use case, since it builds on language behavior that won't likely change soon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 4 05:12:51 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Sep 2015 05:12:51 -0000 Subject: [GHC] #10839: Consistent pretty-printing of type families In-Reply-To: <048.28810866bbeb92c031eb9149a92b094c@haskell.org> References: <048.28810866bbeb92c031eb9149a92b094c@haskell.org> Message-ID: <063.4c7a5299327c9620728b2e53750dbd77@haskell.org> #10839: Consistent pretty-printing of type families -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: msosn Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by msosn): * owner: => msosn -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 4 05:34:18 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Sep 2015 05:34:18 -0000 Subject: [GHC] #10823: Don't mark functions with annotations as dead In-Reply-To: <045.57db4451919a86b3fcad053f0c16d552@haskell.org> References: <045.57db4451919a86b3fcad053f0c16d552@haskell.org> Message-ID: <060.b2a97d95363a120212e30d96944daa8f@haskell.org> #10823: Don't mark functions with annotations as dead -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Perhaps if we had a library type {{{ data KeepAlive = KeepAlive }}} then you could add a `KeepAlive` annotation {{{ {-# ANN thing KeepAlive #-} }}} with the intent that anything with a `KeepAlive` annotation (rather than with ''any'' annotation) is kept alive -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 4 06:33:32 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Sep 2015 06:33:32 -0000 Subject: [GHC] #10826: [Security] Safe Haskell can be bypassed via annotations In-Reply-To: <045.6042fe6f9f535df81b6d3e710bdd3ea9@haskell.org> References: <045.6042fe6f9f535df81b6d3e710bdd3ea9@haskell.org> Message-ID: <060.96a4ebabb682a94dc0ee761b4d89d83b@haskell.org> #10826: [Security] Safe Haskell can be bypassed via annotations -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by kanetw): I don't think it's possible to run the import check before typechecking/renaming as it requires a TcGblEnv (see checkSafeImports). You could run rnImports/maybe tcRnImports first, then check safety based on those imports, then do the rest. But I'm not sure whether that'll be sufficient for Safe Haskell. I'll take a closer look tomorrow. I have a patch that just plain disables annotations under Safe Haskell; if that's acceptable (as a workaround at least) I can post it on Phab. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 4 07:49:03 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Sep 2015 07:49:03 -0000 Subject: [GHC] #10824: Strict let-bindings are processed backwards (was: Let-bindings of kind # are processed backwards) In-Reply-To: <045.c0cfb865a77b8ab0d0da4471347445ce@haskell.org> References: <045.c0cfb865a77b8ab0d0da4471347445ce@haskell.org> Message-ID: <060.bc8f4f2453a4bccad256f4c261575d69@haskell.org> #10824: Strict let-bindings are processed backwards -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by ezyang: Old description: > Consider this module: > > {{{ > {-# LANGUAGE MagicHash #-} > import GHC.Exts > main = do let x = error "bar" :: Int# > y = error "foo" :: Int# > print (I# x + I# y) > }}} > > When you run this, you will get the error "foo" and not the error "bar". > This is backwards! New description: Consider this module: {{{ main = do let !x = error "bar" !y = error "foo" print (x + y) }}} or this analogous module: {{{ {-# LANGUAGE MagicHash #-} import GHC.Exts main = do let x = error "bar" :: Int# y = error "foo" :: Int# print (I# x + I# y) }}} When you run these, you will get the error "foo" and not the error "bar". This is backwards! -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 4 07:50:00 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Sep 2015 07:50:00 -0000 Subject: [GHC] #10840: Periodic alarm signals can cause a retry loop to get stuck Message-ID: <049.c792fb7fbab25e12997f6231b1f3472d@haskell.org> #10840: Periodic alarm signals can cause a retry loop to get stuck -------------------------------------+------------------------------------- Reporter: Rufflewind | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- The [https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Signals periodic alarm signals emitted by the GHC RTS] can [https://github.com/haskell/directory/issues/35 hang the program under certain circumstances]. In particular, any retry-loop of the form {{{#!c while (interruptible_syscall() == FAILED && errno == EINTR); }}} can cause a hang if the syscall takes a long time and cannot be resumed, as it will forced to restart from the beginning each time it gets interrupted. If the syscall takes longer than the interval between successive alarm signals, it will be stuck in this loop forever. This was found to occur with `statfs64` (indirectly called by `realpath`) and `open` on SSHFS on Mac OS X. [https://mail.haskell.org/pipermail/ghc-devs/2015-September/009770.html Using a safe foreign import seems to mitigate the issue], but [https://mail.haskell.org/pipermail/ghc-devs/2015-September/009793.html according to Simon Marlow this is probably an accident]. So far there seems to be no way to guarantee the suspension of signals except through low-level tools like `pthread_setmask`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 4 08:23:33 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Sep 2015 08:23:33 -0000 Subject: [GHC] #10047: inconsistency in name binding between splice and quasiquotation In-Reply-To: <047.467ed7feed46ef69006cfd30a0e1c7fb@haskell.org> References: <047.467ed7feed46ef69006cfd30a0e1c7fb@haskell.org> Message-ID: <062.837bc0b65babeb9a24153de717247dc6@haskell.org> #10047: inconsistency in name binding between splice and quasiquotation -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: spinda Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 7.8.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: th/T10047 Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1199 -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 4 10:59:00 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Sep 2015 10:59:00 -0000 Subject: [GHC] #5611: Asynchronous exception discarded after safe FFI call In-Reply-To: <048.a1f4840a208dec01f4783b6a8911d995@haskell.org> References: <048.a1f4840a208dec01f4783b6a8911d995@haskell.org> Message-ID: <063.0d4809a46a5ec380529f24d968dadb71@haskell.org> #5611: Asynchronous exception discarded after safe FFI call -------------------------------------+------------------------------------- Reporter: joeyadams | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.2.1 Component: Runtime System | Version: 7.0.3 Resolution: | Keywords: FFI, | exception Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * owner: simonmar => * status: closed => new * resolution: fixed => * cc: ezyang (added) Comment: This test just failed on me, but just once, not repeatedly. It printed `child: Done waiting` intead of `user error (Exception delivered successfully)`. I was validating an unrelated patch on Phabricator: https://phabricator.haskell.org/harbormaster/build/5908/ (Phab:D1209) CC ezyang, since he worked on this problem before, according to comment:1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 4 11:22:40 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Sep 2015 11:22:40 -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.606de2507d6302479b3ec91b9017b940@haskell.org> #9943: Replace "error" with "errorWithStackTrace" from GHC.Stack in base libs -------------------------------------+------------------------------------- Reporter: spacekitteh | Owner: Type: task | Status: closed Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5273 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #5273 * milestone: => 7.12.1 Comment: This program: {{{ import Control.Exception main = do Left (ex@(ErrorCallWithLocation a b)) <- try $ print (head [] :: ()) putStrLn a putStrLn b throwIO ex }}} Now prints: {{{ Prelude.head: empty list CallStack: error, called at libraries/base/GHC/List.hs:1009:3 in base:GHC.List Test: Prelude.head: empty list }}} I'm not sure why the custom exception handler is needed. Perhaps that will be cleared up later. I think this ticket can be closed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 4 13:59:31 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Sep 2015 13:59:31 -0000 Subject: [GHC] #1851: "make install-strip" should work In-Reply-To: <044.55b2dd35d7abad74f0ebfed90c4f828d@haskell.org> References: <044.55b2dd35d7abad74f0ebfed90c4f828d@haskell.org> Message-ID: <059.36eeb7c75c15315020a9032e965721fb@haskell.org> #1851: "make install-strip" should work -------------------------------------+------------------------------------- Reporter: igloo | Owner: thomie Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"64761ce9a899954a12d8e3ae8b400c5ad9648137/ghc" 64761ce/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="64761ce9a899954a12d8e3ae8b400c5ad9648137" Build system: implement `make install-strip` (#1851) Reviewed by: bgamari Differential Revision: https://phabricator.haskell.org/D1209 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 4 14:00:57 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Sep 2015 14:00:57 -0000 Subject: [GHC] #1851: "make install-strip" should work In-Reply-To: <044.55b2dd35d7abad74f0ebfed90c4f828d@haskell.org> References: <044.55b2dd35d7abad74f0ebfed90c4f828d@haskell.org> Message-ID: <059.4e4c1355492b400d9c53564f3e03be1d@haskell.org> #1851: "make install-strip" should work -------------------------------------+------------------------------------- Reporter: igloo | Owner: thomie Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.10.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed Comment: gidyn: should be fixed in 7.12. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 4 14:02:39 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Sep 2015 14:02:39 -0000 Subject: [GHC] #9087: Executables in the Linux binaries are not stripped In-Reply-To: <045.32e06e6ec3c181db27d068784d01610c@haskell.org> References: <045.32e06e6ec3c181db27d068784d01610c@haskell.org> Message-ID: <060.df5ef036101a44a875e952bd8b1bac1f@haskell.org> #9087: Executables in the Linux binaries are not stripped -------------------------------------+------------------------------------- Reporter: refold | Owner: thomie Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.8.2 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #1851 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * milestone: => 7.12.1 Comment: I fixed the Cabal bug (https://github.com/haskell/cabal/pull/2782) and added a `make install-strip` target that strips executables. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 4 14:36:05 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Sep 2015 14:36:05 -0000 Subject: [GHC] #10830: maximumBy has a space leak In-Reply-To: <051.80712d357123f27d6467f28abef6100b@haskell.org> References: <051.80712d357123f27d6467f28abef6100b@haskell.org> Message-ID: <066.a149eb301ad4c1cf4177afd0aa438e6f@haskell.org> #10830: maximumBy has a space leak -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.3 Component: libraries/base | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1205 -------------------------------------+------------------------------------- Comment (by nomeata): Replying to [comment:9 rwbarton]: > Is #10788 related, btw? Only morally related, not technially: `minimumBy` goes via `Foldable` stuff, so we end up with `foldr1`, while `minimum` is (yet) a member of the class and for lists, a direct definition is given, which has the inlining difficulties discussed in #10788. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 4 16:33:58 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Sep 2015 16:33:58 -0000 Subject: [GHC] #10840: Periodic alarm signals can cause a retry loop to get stuck In-Reply-To: <049.c792fb7fbab25e12997f6231b1f3472d@haskell.org> References: <049.c792fb7fbab25e12997f6231b1f3472d@haskell.org> Message-ID: <064.505e7e3a2a855343c886b774dabacf89@haskell.org> #10840: Periodic alarm signals can cause a retry loop to get stuck -------------------------------------+------------------------------------- Reporter: Rufflewind | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonmar): * cc: simonmar (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 4 18:51:25 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Sep 2015 18:51:25 -0000 Subject: [GHC] #10841: Run handler on STM retry Message-ID: <045.10ea2aa941550aac6248eb677ce6a5a6@haskell.org> #10841: Run handler on STM retry -------------------------------------+------------------------------------- Reporter: shlevy | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: libraries | Version: 7.10.2 (other) | Keywords: stm | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- It would be nice to have a function like: {{{#!hs -- | Perform a series of STM actions atomically. -- -- Whenever the transaction retries, run the handler. If it doesn't return 'Nothing', -- stop the retrying and return the value given by the handler. atomicallyWithRetryHandler :: STM a -> IO (Maybe a) -> IO a }}} This would allow tracking retry statistics, printing debug messages on each retry, etc. without resorting to unsafeIOToSTM which can't safely do things like printing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 4 19:59:36 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Sep 2015 19:59:36 -0000 Subject: [GHC] #10842: "Reactive" Template Haskell Message-ID: <050.6f7bb562017372f9e5bba0241a40c1a7@haskell.org> #10842: "Reactive" Template Haskell -------------------------------------+------------------------------------- Reporter: | Owner: MikeIzbicki | Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: 9699 Differential Revisions: | -------------------------------------+------------------------------------- When metaprogramming, I often encounter the situation where I want GHC to do something for every definition in scope. For example, I recently posted a simple library called [https://github.com/mikeizbicki/ifcxt/ ifcxt] that relies on defining `instance IfCxt cxt` for every `instance cxt` that gets defined (where `cxt` is an arbitrary class instance). Currently, the library has a TH function that generates these `IfCxt cxt` instances, but it can only work for instances that already exist at the time the TH function is called. Any instances created afterward get silently ignored. To solve this problem, I would like to be able to register TH functions with the compiler that get executed everytime the compiler adds a definition. This might take the form of a function like: {{{ registerTH :: (Dec -> Q [Dec]) -> Q () }}} When `regesterTH` is called, it would add the argument function to an internal list. Then, whenever the compiler defines a new declaration, it calls each function in the list on that declaration to see what new declarations should be added to the code. AFAICT, there are two main drawbacks to this proposal. One, end users do not have to specifically invoke a TH function to get TH code to run. This would allow library authors to take over people's programs in possibly unexpected ways. So this might justify an additional extension beyond just `-XTemplateHaskell` to signal the potentially dangerous nature of the code, or implementing this feature by extending the compiler plugin interface. Second, it would be very easy to accidentally send the compiler into infinite loops if two registered functions don't take care to behave properly with each other. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 4 20:05:55 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Sep 2015 20:05:55 -0000 Subject: [GHC] #10841: Run handler on STM retry In-Reply-To: <045.10ea2aa941550aac6248eb677ce6a5a6@haskell.org> References: <045.10ea2aa941550aac6248eb677ce6a5a6@haskell.org> Message-ID: <060.ea818e392d5f59ff0eb2db2a6dbb2197@haskell.org> #10841: Run handler on STM retry -------------------------------------+------------------------------------- Reporter: shlevy | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries | Version: 7.10.2 (other) | Resolution: | Keywords: stm Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by shlevy): Alternate type signature: {{{#!haskell (a -> STM b) -> a -> IO a -> IO b }}} The idea being that a potentially different transaction is run every time (or not at all if the function wants to). But that may be just asking for people to shoot themselves in the foot. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 4 21:14:59 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Sep 2015 21:14:59 -0000 Subject: [GHC] #10839: Consistent pretty-printing of type families In-Reply-To: <048.28810866bbeb92c031eb9149a92b094c@haskell.org> References: <048.28810866bbeb92c031eb9149a92b094c@haskell.org> Message-ID: <063.872d7a69f1080953023fc230ce975483@haskell.org> #10839: Consistent pretty-printing of type families -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: msosn Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Yay @msosn. Thanks! Let us know if you need assistance. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 4 21:22:30 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Sep 2015 21:22:30 -0000 Subject: [GHC] #10823: Don't mark functions with annotations as dead In-Reply-To: <045.57db4451919a86b3fcad053f0c16d552@haskell.org> References: <045.57db4451919a86b3fcad053f0c16d552@haskell.org> Message-ID: <060.58ffef071277c46e64b410165480b96b@haskell.org> #10823: Don't mark functions with annotations as dead -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Replying to comment:14: It seems that this suggestion is equivalent to having a new pragma `{-# KEEP_ALIVE thing #-}`. Or even just `{-# KEEP_ALIVE #-}` preceding the declaration. So, my question is: why do this using `ANN`? Or, conversely, does it make sense to do ''all'' identifier specific pragmas using `ANN`? (I'm thinking of things like `INLINABLE`.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 4 22:26:39 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Sep 2015 22:26:39 -0000 Subject: [GHC] #10826: [Security] Safe Haskell can be bypassed via annotations In-Reply-To: <045.6042fe6f9f535df81b6d3e710bdd3ea9@haskell.org> References: <045.6042fe6f9f535df81b6d3e710bdd3ea9@haskell.org> Message-ID: <060.f02f75bf6b7c6a5f349acbc22361bfc3@haskell.org> #10826: [Security] Safe Haskell can be bypassed via annotations -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): No reason to install a workaround if we can just fix the problem. But, I must ask: is it possible ever to inspect annotations from Safe Haskell? I think probably not within Haskell, but perhaps someone wants to read .hi files (do these have annotations?) after they're compiled via Safe Haskell. Is this correct? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 4 22:38:20 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Sep 2015 22:38:20 -0000 Subject: [GHC] #10826: [Security] Safe Haskell can be bypassed via annotations In-Reply-To: <045.6042fe6f9f535df81b6d3e710bdd3ea9@haskell.org> References: <045.6042fe6f9f535df81b6d3e710bdd3ea9@haskell.org> Message-ID: <060.acc3a8437db6f5da936ecc7f1251df02@haskell.org> #10826: [Security] Safe Haskell can be bypassed via annotations -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by kanetw): Not as far as I know. They're only accessible via the GHC API or TH and that's unsafe Haskell, never mind that you have to explicitly unhide `ghc` for the first way. .hi files do have annotations stored, so you could read them with an external tool. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 4 23:03:31 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Sep 2015 23:03:31 -0000 Subject: [GHC] #10840: Periodic alarm signals can cause a retry loop to get stuck In-Reply-To: <049.c792fb7fbab25e12997f6231b1f3472d@haskell.org> References: <049.c792fb7fbab25e12997f6231b1f3472d@haskell.org> Message-ID: <064.3b759a72a998570d5a1a45d383ddfd5f@haskell.org> #10840: Periodic alarm signals can cause a retry loop to get stuck -------------------------------------+------------------------------------- Reporter: Rufflewind | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hamish): * cc: hamish (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 01:35:28 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 01:35:28 -0000 Subject: [GHC] #10672: GHCi linker does not understand C++ exception tables on Windows (was: checkProddableBlock crash during Template Haskell linking) In-Reply-To: <045.04cee7c60b130b0ccc29791ed61c4f5f@haskell.org> References: <045.04cee7c60b130b0ccc29791ed61c4f5f@haskell.org> Message-ID: <060.b736f2bc7628b61418320fbe8b5bc795@haskell.org> #10672: GHCi linker does not understand C++ exception tables on Windows -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: Runtime System | Version: 7.10.1 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #9297 #10563 | Differential Revisions: #8237 #9907 | -------------------------------------+------------------------------------- Changes (by ezyang): * component: Compiler => Runtime System (Linker) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 01:40:38 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 01:40:38 -0000 Subject: [GHC] #1477: ghci shouldn't link entire package In-Reply-To: <044.3177f4a5de264e67b2c8e4394ff3a68d@haskell.org> References: <044.3177f4a5de264e67b2c8e4394ff3a68d@haskell.org> Message-ID: <059.a23dd16511fceacddbfec5f99ca3fdfa@haskell.org> #1477: ghci shouldn't link entire package -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: feature request | Status: closed Priority: normal | Milestone: ? Component: Runtime System | Version: 6.6.1 (Linker) | Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * failure: => None/Unknown * component: GHCi => Runtime System (Linker) * resolution: => wontfix Comment: This would cause major complications for GHCi, as you would need to somehow be able to load the other symbols lazily when you loaded a new library that actually needed them. Additionally, dynamic linking would have the same problem unless the platform supports lazy dynamic loading. The indicated solution is to split the package into three. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 01:47:29 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 01:47:29 -0000 Subject: [GHC] #6107: GHCi runtime linker cannot link with duplicate common symbols In-Reply-To: <046.ed2058fbb6b102a7e0a7609832647662@haskell.org> References: <046.ed2058fbb6b102a7e0a7609832647662@haskell.org> Message-ID: <061.eb350f6228ab072cc323de23774395b8@haskell.org> #6107: GHCi runtime linker cannot link with duplicate common symbols -------------------------------------+------------------------------------- Reporter: exFalso | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Runtime System | Version: 7.4.1 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 8228 | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * component: Compiler => Runtime System (Linker) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 01:48:50 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 01:48:50 -0000 Subject: [GHC] #8127: iOS patch no 19: Linking In-Reply-To: <056.cfb2c89196b093d46cda3044197779e0@haskell.org> References: <056.cfb2c89196b093d46cda3044197779e0@haskell.org> Message-ID: <071.5550bc626815abaafd0dd8b939bac400@haskell.org> #8127: iOS patch no 19: Linking -------------------------------------+------------------------------------- Reporter: | Owner: StephenBlackheath | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 (Linking) | Resolution: | Keywords: Operating System: MacOS X | Architecture: arm Type of failure: GHC doesn't work | Test Case: at all | Blocked By: | Blocking: 7724 Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * component: Compiler => Compiler (Linking) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 01:49:21 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 01:49:21 -0000 Subject: [GHC] #8127: iOS patch no 19: Linking In-Reply-To: <056.cfb2c89196b093d46cda3044197779e0@haskell.org> References: <056.cfb2c89196b093d46cda3044197779e0@haskell.org> Message-ID: <071.e0a33396c0a49f3ba82ab74b3ba0c4d4@haskell.org> #8127: iOS patch no 19: Linking -------------------------------------+------------------------------------- Reporter: | Owner: StephenBlackheath | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 (Linking) | Resolution: | Keywords: easy Operating System: MacOS X | Architecture: arm Type of failure: GHC doesn't work | Test Case: at all | Blocked By: | Blocking: 7724 Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * keywords: => easy -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 01:50:37 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 01:50:37 -0000 Subject: [GHC] #8229: Linking in Windows is slow In-Reply-To: <045.f2fe9210b16252447cedd8c4a7748b17@haskell.org> References: <045.f2fe9210b16252447cedd8c4a7748b17@haskell.org> Message-ID: <060.7d217d8ac9c0623ea343b00156b851d6@haskell.org> #8229: Linking in Windows is slow -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => fixed Comment: With updated mingw it looks like linker is doing better, marking as fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 01:51:27 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 01:51:27 -0000 Subject: [GHC] #8238: Implement unloading of shared libraries In-Reply-To: <047.e2bbc066d014f0f597cdb8b788581350@haskell.org> References: <047.e2bbc066d014f0f597cdb8b788581350@haskell.org> Message-ID: <062.d267d51afc4bbf1804ffe6d361910f20@haskell.org> #8238: Implement unloading of shared libraries -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.12.1 Component: Runtime System | Version: 7.7 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 8039 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => patch * component: Runtime System => Runtime System (Linker) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 01:59:00 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 01:59:00 -0000 Subject: [GHC] #8614: Duplicate symbol error when loading text twice In-Reply-To: <042.f86f42b094fe0faf9d18aa4da57dfc8a@haskell.org> References: <042.f86f42b094fe0faf9d18aa4da57dfc8a@haskell.org> Message-ID: <057.ddacf58490777b2e707aa1a755e58880@haskell.org> #8614: Duplicate symbol error when loading text twice -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #7030 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * component: Compiler => Runtime System (Linker) Comment: So, it turns out that there is a linking failure in the pasted transcript. So it looks like the bug is that we are not properly unloading the objects we loaded prior to the failure; namely, text has something which is not unloaded. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 02:02:04 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 02:02:04 -0000 Subject: [GHC] #8713: Avoid libraries if unneeded (librt, libdl, libpthread) In-Reply-To: <045.e65f03bd077c86ec4c44c9abb727b716@haskell.org> References: <045.e65f03bd077c86ec4c44c9abb727b716@haskell.org> Message-ID: <060.9c1a3761dbc856905657513d41721337@haskell.org> #8713: Avoid libraries if unneeded (librt, libdl, libpthread) -------------------------------+----------------------------------------- Reporter: ip1981 | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: Other | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+----------------------------------------- Changes (by ezyang): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 02:06:33 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 02:06:33 -0000 Subject: [GHC] #8926: GHC makes unsound references in object code In-Reply-To: <052.93f7af489c413776f218da91117a1ded@haskell.org> References: <052.93f7af489c413776f218da91117a1ded@haskell.org> Message-ID: <067.7a67a089a61ebd22bcebaca026e0ac80@haskell.org> #8926: GHC makes unsound references in object code -------------------------------------+------------------------------------- Reporter: anton.dubovik | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * owner: => ezyang Comment: I haven't looked at the code but I think I fixed this: #2182. Just need to test. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 02:09:35 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 02:09:35 -0000 Subject: [GHC] #9237: GHC not recognizing INPUT(-llibrary) in linker scripts In-Reply-To: <051.f95f4904e896de4fcf955563f575c874@haskell.org> References: <051.f95f4904e896de4fcf955563f575c874@haskell.org> Message-ID: <066.710dfe812af133351a7aec29d541f1b6@haskell.org> #9237: GHC not recognizing INPUT(-llibrary) in linker scripts -------------------------------------+------------------------------------- Reporter: mmikolajczyk | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.2 (Linking) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: 2615, 10046 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * component: Compiler => Compiler (Linking) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 02:10:13 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 02:10:13 -0000 Subject: [GHC] #9277: GHCi panic: Loading temp shared object failed: Symbol not found In-Reply-To: <045.813f344587210915a54c6a71c5a099a3@haskell.org> References: <045.813f344587210915a54c6a71c5a099a3@haskell.org> Message-ID: <060.72ed8dccbca8ef4fda18bd1f881ed4b6@haskell.org> #9277: GHCi panic: Loading temp shared object failed: Symbol not found -------------------------------------+------------------------------------- Reporter: mietek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.2 (Linker) | Keywords: panic, Resolution: | dynamic linking Operating System: MacOS X | Architecture: x86_64 | (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #8935, #9034, | Differential Revisions: #9074, #9278 | -------------------------------------+------------------------------------- Changes (by ezyang): * component: GHCi => Runtime System (Linker) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 02:30:00 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 02:30:00 -0000 Subject: [GHC] #9280: GHCi crash: illegal text-relocation to _ in _ from _ in _ for architecture x86_64; relocation R_X86_64_PC32 against undefined symbol _ can not be used when making a shared object In-Reply-To: <045.75366a6d8bb8f153b367bf0a7d539b25@haskell.org> References: <045.75366a6d8bb8f153b367bf0a7d539b25@haskell.org> Message-ID: <060.cf7da5630708214e22fd253efaf1d91f@haskell.org> #9280: GHCi crash: illegal text-relocation to _ in _ from _ in _ for architecture x86_64; relocation R_X86_64_PC32 against undefined symbol _ can not be used when making a shared object -------------------------------------+------------------------------------- Reporter: mietek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Resolution: | Keywords: crash, | dynamic linking Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): I don't know; the symbol could be referred to by another C file which we actually know symbols of. It seems that though you shouldnt do this... It also shouldn't fail. So there may very well be a legitimate bug here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 02:31:32 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 02:31:32 -0000 Subject: [GHC] #9481: Linker does not correctly resolve symbols in previously loaded objects In-Reply-To: <044.0f3c08e0d5a42fe8ecdcbe7daafad442@haskell.org> References: <044.0f3c08e0d5a42fe8ecdcbe7daafad442@haskell.org> Message-ID: <059.02e816c9d3b38564220361814cfb1dcb@haskell.org> #9481: Linker does not correctly resolve symbols in previously loaded objects -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.2 (Linker) | Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * component: Compiler => Runtime System (Linker) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 02:35:12 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 02:35:12 -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.6e81d86dbe9fa1faeb1d4cd8e97f4012@haskell.org> #9868: ghc: panic! Dynamic linker not initialised -------------------------------------+------------------------------------- Reporter: Jamedjo | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Runtime System | Version: 7.8.3 (Linker) | Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * component: Compiler => Runtime System (Linker) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 02:36:29 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 02:36:29 -0000 Subject: [GHC] #10046: Linker script patch in rts/Linker.c doesn't work for (non-C or non-en..) locales In-Reply-To: <046.8d9180bf5eb50fbc94b5b6fcc0a45647@haskell.org> References: <046.8d9180bf5eb50fbc94b5b6fcc0a45647@haskell.org> Message-ID: <061.dd6702b526a12251a90cfc8e0e04d6a7@haskell.org> #10046: Linker script patch in rts/Linker.c doesn't work for (non-C or non-en..) locales -------------------------------------+------------------------------------- Reporter: hgolden | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Runtime System | Version: 7.8.4 (Linker) | Keywords: linker Resolution: | script Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: 2615, 9237 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * component: Runtime System => Runtime System (Linker) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 02:39:50 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 02:39:50 -0000 Subject: [GHC] #10352: Properly link Haskell shared libs on ELF systems In-Reply-To: <045.f54c0b53e462b1ea305eb5f3c38d7688@haskell.org> References: <045.f54c0b53e462b1ea305eb5f3c38d7688@haskell.org> Message-ID: <060.16a50a04798a2e086c4b5164f9af93e0@haskell.org> #10352: Properly link Haskell shared libs on ELF systems -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (Linking) | Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * component: Package system => Compiler (Linking) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 02:41:38 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 02:41:38 -0000 Subject: [GHC] #10355: Dynamic linker not initialised In-Reply-To: <046.b020405a0b5eb69acc1047433b42d151@haskell.org> References: <046.b020405a0b5eb69acc1047433b42d151@haskell.org> Message-ID: <061.bb885fa21fc49e83e378fc7fc865009a@haskell.org> #10355: Dynamic linker not initialised -------------------------------------+------------------------------------- Reporter: dpiponi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.1 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 9868 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * component: Compiler => Runtime System (Linker) * related: => 9868 Comment: Related #9868 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 02:41:55 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 02:41:55 -0000 Subject: [GHC] #10355: Dynamic linker not initialised In-Reply-To: <046.b020405a0b5eb69acc1047433b42d151@haskell.org> References: <046.b020405a0b5eb69acc1047433b42d151@haskell.org> Message-ID: <061.30cc2d8e3d5da9a80285d2606ca09dba@haskell.org> #10355: Dynamic linker not initialised -------------------------------------+------------------------------------- Reporter: dpiponi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.1 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9868 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * related: 9868 => #9868 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 02:44:46 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 02:44:46 -0000 Subject: [GHC] #10436: Excessive numbers of packages loaded for TH In-Reply-To: <045.b8bbf0247835752ace9434694fd31689@haskell.org> References: <045.b8bbf0247835752ace9434694fd31689@haskell.org> Message-ID: <060.c3c4717fd55eabe6db86f2f1a3a95cb8@haskell.org> #10436: Excessive numbers of packages loaded for TH -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #2437 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * related: => #2437 Comment: I think this is #2437 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 02:45:24 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 02:45:24 -0000 Subject: [GHC] #10454: ghc.exe: warning: _tzset from msvcrt is linked instead of __imp__tzset In-Reply-To: <050.2db21865438175ee626af0337216c86d@haskell.org> References: <050.2db21865438175ee626af0337216c86d@haskell.org> Message-ID: <065.6658dc3c4f2a23573913117dd302eace@haskell.org> #10454: ghc.exe: warning: _tzset from msvcrt is linked instead of __imp__tzset -------------------------------------+------------------------------------- Reporter: MetaMemoryT | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.1 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect | (amd64) warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * component: Compiler => Runtime System (Linker) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 02:47:53 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 02:47:53 -0000 Subject: [GHC] #10563: GHC 7.10.1 Win7 x86_64 crash when building reflex-dom-0.1.1 In-Reply-To: <044.865cad2cae7a0515bb63b8ae4cd3b513@haskell.org> References: <044.865cad2cae7a0515bb63b8ae4cd3b513@haskell.org> Message-ID: <059.a7580953b9bd745a483b4162cea59c7e@haskell.org> #10563: GHC 7.10.1 Win7 x86_64 crash when building reflex-dom-0.1.1 -------------------------------------+------------------------------------- Reporter: tejon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: #10672 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * related: => #10672 Comment: Yeah GhcDebugged=YES should be OK. See also #10672 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 02:48:59 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 02:48:59 -0000 Subject: [GHC] #10671: inplace/bin/ghc-stage1 doesn't respect --with-ld override In-Reply-To: <043.3dbf7fc0356f7f2fdf48023120606ded@haskell.org> References: <043.3dbf7fc0356f7f2fdf48023120606ded@haskell.org> Message-ID: <058.898a9465670ca8d8ad6f4e6091584cc0@haskell.org> #10671: inplace/bin/ghc-stage1 doesn't respect --with-ld override -------------------------------------+------------------------------------- Reporter: mfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 (Linking) | Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * component: Build System => Compiler (Linking) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 02:50:05 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 02:50:05 -0000 Subject: [GHC] #10777: Overlong linker arguments on Windows leads to broken builds with confusing error messages In-Reply-To: <047.046a9f83230d0273c9346cd501403845@haskell.org> References: <047.046a9f83230d0273c9346cd501403845@haskell.org> Message-ID: <062.57fa0a46717a76ccd7725a458fd93517@haskell.org> #10777: Overlong linker arguments on Windows leads to broken builds with confusing error messages -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: snoyberg Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #8596 #9685 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => merge Comment: Merge maybe? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 02:51:56 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 02:51:56 -0000 Subject: [GHC] #10799: "I found a duplicate definition for symbol: __x86.get_pc_thunk.bx" in package network In-Reply-To: <047.a777ede82e63f4bc5c43944be8461ea4@haskell.org> References: <047.a777ede82e63f4bc5c43944be8461ea4@haskell.org> Message-ID: <062.692ebc52444876300f9bd67718ed011b@haskell.org> #10799: "I found a duplicate definition for symbol: __x86.get_pc_thunk.bx" in package network -------------------------------------+------------------------------------- Reporter: blueonyx | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Linking) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #9657 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * component: GHC API => Compiler (Linking) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 02:52:30 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 02:52:30 -0000 Subject: [GHC] #3372: Allow for multiple linker instances In-Reply-To: <049.b54da97038a1da97405ea7b63a99f067@haskell.org> References: <049.b54da97038a1da97405ea7b63a99f067@haskell.org> Message-ID: <064.4ecadb87e0c22941605dc76b005b002b@haskell.org> #3372: Allow for multiple linker instances -------------------------------------+------------------------------------- Reporter: jcpetruzza | Owner: Type: feature request | Status: new Priority: low | Milestone: 7.12.1 Component: Runtime System | Version: (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 3658 | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * component: Compiler => Runtime System (Linker) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 02:53:03 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 02:53:03 -0000 Subject: [GHC] #3713: Track -dynamic/-fPIC to avoid obscure linker errors In-Reply-To: <047.d92ae3d0696eeed98ccca2fecc965354@haskell.org> References: <047.d92ae3d0696eeed98ccca2fecc965354@haskell.org> Message-ID: <062.02fbb52df858b7de51c3dc45a09cb92d@haskell.org> #3713: Track -dynamic/-fPIC to avoid obscure linker errors -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: low | Milestone: 7.12.1 Component: Compiler | Version: 6.10.4 (Linking) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * component: Compiler => Compiler (Linking) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 02:53:29 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 02:53:29 -0000 Subject: [GHC] #5197: Support static linker semantics for archives and weak symbols In-Reply-To: <045.5d7250522a4c91dac0c31e2ca3e7d4e2@haskell.org> References: <045.5d7250522a4c91dac0c31e2ca3e7d4e2@haskell.org> Message-ID: <060.0efafb62176a3abc526984f628d41836@haskell.org> #5197: Support static linker semantics for archives and weak symbols -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: feature request | Status: new Priority: low | Milestone: 7.12.1 Component: Runtime System | Version: 7.0.3 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * component: Runtime System => Runtime System (Linker) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 02:54:16 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 02:54:16 -0000 Subject: [GHC] #7746: Support loading/unloading profiled objects from a profiled executable In-Reply-To: <045.ca53cc09f11562f645334cf2f2e456a1@haskell.org> References: <045.ca53cc09f11562f645334cf2f2e456a1@haskell.org> Message-ID: <060.5a3f3ed8406d960bd9a792ecd2763569@haskell.org> #7746: Support loading/unloading profiled objects from a profiled executable -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: lowest | Milestone: ? Component: Runtime System | Version: 7.7 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 5435, 8039 | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * priority: low => lowest * component: Runtime System => Runtime System (Linker) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 02:57:27 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 02:57:27 -0000 Subject: [GHC] #10779: .so files in 64-bit Debian builds are 4% larger than they have to be In-Reply-To: <045.450bda01d4ecd6d42c485573e682c5ca@haskell.org> References: <045.450bda01d4ecd6d42c485573e682c5ca@haskell.org> Message-ID: <060.fc0c744978577ceeaac90d656132a9b2@haskell.org> #10779: .so files in 64-bit Debian builds are 4% larger than they have to be -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.2 (Linking) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * component: Build System => Compiler (Linking) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 02:57:56 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 02:57:56 -0000 Subject: [GHC] #2805: Test ffi009(ghci) fails on PPC Mac OS X In-Reply-To: <050.49e5533b97232a9f431fe6cab3b29ebd@haskell.org> References: <050.49e5533b97232a9f431fe6cab3b29ebd@haskell.org> Message-ID: <065.b1d8be2ebf260131675ebe5933475294@haskell.org> #2805: Test ffi009(ghci) fails on PPC Mac OS X -------------------------------------+------------------------------------- Reporter: thorkilnaur | Owner: Type: bug | Status: new Priority: lowest | Milestone: 7.12.1 Component: Runtime System | Version: 6.11 (Linker) | Resolution: | Keywords: Operating System: MacOS X | Architecture: powerpc Type of failure: None/Unknown | Test Case: | ffi009(ghci) Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * component: GHCi => Runtime System (Linker) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 02:58:26 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 02:58:26 -0000 Subject: [GHC] #2933: LDFLAGS ignored by build system In-Reply-To: <045.854117476da424db3736910ffba011f0@haskell.org> References: <045.854117476da424db3736910ffba011f0@haskell.org> Message-ID: <060.db4256fefa6679f5f9dad75008775ea3@haskell.org> #2933: LDFLAGS ignored by build system -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: lowest | Milestone: 7.12.1 Component: Compiler | Version: 6.10.1 (Linking) | Resolution: | Keywords: Operating System: Solaris | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * component: Build System => Compiler (Linking) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 02:59:43 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 02:59:43 -0000 Subject: [GHC] #3571: Bizzarely bloated binaries In-Reply-To: <044.a58781a47fed5e173c154c742b96ee46@haskell.org> References: <044.a58781a47fed5e173c154c742b96ee46@haskell.org> Message-ID: <059.78d6d42f38d6af81d79e2a743e5e75e7@haskell.org> #3571: Bizzarely bloated binaries -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: lowest | Milestone: 7.12.1 Component: Compiler | Version: 6.10.4 (Linking) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * component: Compiler => Compiler (Linking) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 03:02:51 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 03:02:51 -0000 Subject: [GHC] #8736: GHCi doesn't load .dyn_o files appropriately In-Reply-To: <052.b282b771a49ddd09f40719b07cb558fa@haskell.org> References: <052.b282b771a49ddd09f40719b07cb558fa@haskell.org> Message-ID: <067.00a132514701d97cff23000144fca356@haskell.org> #8736: GHCi doesn't load .dyn_o files appropriately -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: | thoughtpolice Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: GHCi | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9282 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * component: Compiler => GHCi -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 03:03:53 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 03:03:53 -0000 Subject: [GHC] #9386: GHCi cannot load .so in ./ In-Reply-To: <047.6d829b9ae97b1073447115aeba1e6bb7@haskell.org> References: <047.6d829b9ae97b1073447115aeba1e6bb7@haskell.org> Message-ID: <062.3acebd912d259bc36ecd1dfd75b5ea67@haskell.org> #9386: GHCi cannot load .so in ./ -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.3 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D593 -------------------------------------+------------------------------------- Changes (by ezyang): * component: Compiler => Runtime System (Linker) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 03:05:26 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 03:05:26 -0000 Subject: [GHC] #4899: Non-standard compile plus Template Haskell produces spurious "unknown symbol" linker error In-Reply-To: <044.cc75c61157a490805e5541a3122426d9@haskell.org> References: <044.cc75c61157a490805e5541a3122426d9@haskell.org> Message-ID: <059.cabbc00e61a9086666b9efe1a434a2ed@haskell.org> #4899: Non-standard compile plus Template Haskell produces spurious "unknown symbol" linker error -------------------------------------+------------------------------------- Reporter: jepst | Owner: simonmar Type: bug | Status: new Priority: low | Milestone: 7.12.1 Component: GHCi | Version: 7.0.1 Resolution: | Keywords: template | link prof dynamic Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * component: Compiler => GHCi -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 03:54:00 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 03:54:00 -0000 Subject: [GHC] #10563: GHC 7.10.1 Win7 x86_64 crash when building reflex-dom-0.1.1 In-Reply-To: <044.865cad2cae7a0515bb63b8ae4cd3b513@haskell.org> References: <044.865cad2cae7a0515bb63b8ae4cd3b513@haskell.org> Message-ID: <059.2a542fd4b2ccfabb3d32d218b35f5c0b@haskell.org> #10563: GHC 7.10.1 Win7 x86_64 crash when building reflex-dom-0.1.1 -------------------------------------+------------------------------------- Reporter: tejon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 (Linking) | Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: #10672 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by JohnWiegley): * component: Compiler => Compiler (Linking) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 03:57:12 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 03:57:12 -0000 Subject: [GHC] #9498: GHC links against unversioned .so files In-Reply-To: <049.d32b3f82e5dcd1a97fdfbd3f9b5afd1e@haskell.org> References: <049.d32b3f82e5dcd1a97fdfbd3f9b5afd1e@haskell.org> Message-ID: <064.7242a6cfbc1c18513eacdd4e22d0f26d@haskell.org> #9498: GHC links against unversioned .so files -------------------------------------+------------------------------------- Reporter: Kritzefitz | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.6.3 (Linking) | Resolution: | Keywords: Debian Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * component: Compiler (FFI) => Compiler (Linking) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 03:57:33 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 03:57:33 -0000 Subject: [GHC] #10777: Overlong linker arguments on Windows leads to broken builds with confusing error messages In-Reply-To: <047.046a9f83230d0273c9346cd501403845@haskell.org> References: <047.046a9f83230d0273c9346cd501403845@haskell.org> Message-ID: <062.f382032ff50afa724c7430f7c6c8be81@haskell.org> #10777: Overlong linker arguments on Windows leads to broken builds with confusing error messages -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: snoyberg Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Linking) | Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #8596 #9685 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by JohnWiegley): * component: Compiler => Compiler (Linking) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 03:59:37 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 03:59:37 -0000 Subject: [GHC] #9989: GHCI is slow for precompiled code In-Reply-To: <046.94b9207f80786e5d4d2d3451b686df6a@haskell.org> References: <046.94b9207f80786e5d4d2d3451b686df6a@haskell.org> Message-ID: <061.643b3970c6c34f7578e588df0019afe5@haskell.org> #9989: GHCI is slow for precompiled code -------------------------------------+------------------------------------- Reporter: remdezx | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.3 (Linker) | Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * component: GHC API => Runtime System (Linker) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 04:00:16 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 04:00:16 -0000 Subject: [GHC] #5620: Dynamic linking and threading does not work on Windows In-Reply-To: <046.0549cfb6865d8f8da0c4dd410e165104@haskell.org> References: <046.0549cfb6865d8f8da0c4dd410e165104@haskell.org> Message-ID: <061.f84e8c3b8ca06fdf0f13660625b7e274@haskell.org> #5620: Dynamic linking and threading does not work on Windows ---------------------------------------+--------------------------------- Reporter: Lennart | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler (Linking) | Version: 7.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------------+--------------------------------- Changes (by ezyang): * component: Runtime System => Compiler (Linking) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 04:00:37 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 04:00:37 -0000 Subject: [GHC] #8290: lookupSymbol API is unsafe In-Reply-To: <045.df7ffdb732cb71d0a322e1094e9d2a99@haskell.org> References: <045.df7ffdb732cb71d0a322e1094e9d2a99@haskell.org> Message-ID: <060.7d9b3272373952c1cc02986f40e472fa@haskell.org> #8290: lookupSymbol API is unsafe -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.9 (Linker) | 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 ezyang): * component: Runtime System => Runtime System (Linker) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 04:01:18 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 04:01:18 -0000 Subject: [GHC] #4824: Windows: Dynamic linking doesn't work out-of-the-box In-Reply-To: <044.2138733a8a74d1ded868da9698df5a9d@haskell.org> References: <044.2138733a8a74d1ded868da9698df5a9d@haskell.org> Message-ID: <059.293bfc9912ca9fb9e80e777f520d6d6a@haskell.org> #4824: Windows: Dynamic linking doesn't work out-of-the-box -------------------------------------+------------------------------------- Reporter: Orphi | Owner: Type: bug | Status: new Priority: low | Milestone: 7.12.1 Component: Runtime System | Version: 7.0.1 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5620 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * component: Runtime System => Runtime System (Linker) * related: => #5620 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 04:04:54 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 04:04:54 -0000 Subject: [GHC] #8926: GHC makes unsound references in object code In-Reply-To: <052.93f7af489c413776f218da91117a1ded@haskell.org> References: <052.93f7af489c413776f218da91117a1ded@haskell.org> Message-ID: <067.3cd2394c7ea18fcb6155b98c5ac7d070@haskell.org> #8926: GHC makes unsound references in object code -------------------------------------+------------------------------------- Reporter: anton.dubovik | Owner: ezyang Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => fixed Comment: Fixed in GHC 7.10: {{{ ezyang at sabre:~/Dev/labs/ghc_linker_error$ env PATH=$HOME/Dev/ghc-7.10.1/usr/bin/:$PATH ./run.sh Warning: The package list for 'hackage.haskell.org' is 16 days old. Run 'cabal update' to get the latest list of available packages. Resolving dependencies... Configuring FooPackage-0.1... Building FooPackage-0.1... Preprocessing library FooPackage-0.1... [1 of 1] Compiling FooPackage ( src/FooPackage.hs, dist/build/FooPackage.o ) In-place registering FooPackage-0.1... Creating package registration file: /tmp/pkgConf-FooPackage-026451.1 Installing library in /home/ezyang/.cabal/lib/x86_64-linux- ghc-7.10.1/FooPackage-0.1-6k6XRTbGJ6GNsmBvgCmwhc Registering FooPackage-0.1... Installed FooPackage-0.1 [1 of 3] Compiling QuxClient ( QuxClient.hs, obj/QuxClient.o ) [2 of 3] Compiling BarClient ( BarClient.hs, obj/BarClient.o ) [3 of 3] Compiling Client1 ( Client1.hs, obj/Client1.o ) Linking exes/Client1.exe ... [2 of 2] Compiling Client2 ( Client2.hs, obj/Client2.o ) Linking exes/Client2.exe ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 04:05:10 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 04:05:10 -0000 Subject: [GHC] #8926: GHC makes unsound references in object code In-Reply-To: <052.93f7af489c413776f218da91117a1ded@haskell.org> References: <052.93f7af489c413776f218da91117a1ded@haskell.org> Message-ID: <067.4e8584aca73934645c8c811c59cb50f7@haskell.org> #8926: GHC makes unsound references in object code -------------------------------------+------------------------------------- Reporter: anton.dubovik | Owner: ezyang Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 04:07:02 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 04:07:02 -0000 Subject: [GHC] #9825: ghc "panic! (the 'impossible' happened)" building vimus on NixOS In-Reply-To: <047.e4f44909e905adacb4005302519ba187@haskell.org> References: <047.e4f44909e905adacb4005302519ba187@haskell.org> Message-ID: <062.7b9fb4cedf6cba63a271cf74cef2ccce@haskell.org> #9825: ghc "panic! (the 'impossible' happened)" building vimus on NixOS -------------------------------------+------------------------------------- Reporter: jzellner | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.3 (Linker) | Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Compile-time | Test Case: crash | Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by JohnWiegley): * component: Compiler => Runtime System (Linker) Comment: Can you narrow this problem down at all, and still reproduce the problem? As stated, there isn't a whole lot to go on, and I would like to discover if this is an issue with the runtime linker. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 04:11:23 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 04:11:23 -0000 Subject: [GHC] #8290: lookupSymbol API is unsafe In-Reply-To: <045.df7ffdb732cb71d0a322e1094e9d2a99@haskell.org> References: <045.df7ffdb732cb71d0a322e1094e9d2a99@haskell.org> Message-ID: <060.887ef52519a3604a68086d87447ee29e@haskell.org> #8290: lookupSymbol API is unsafe -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: low | Milestone: Component: Runtime System | Version: 7.9 (Linker) | 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 ezyang): * priority: normal => low -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 04:17:08 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 04:17:08 -0000 Subject: [GHC] #9825: ghc "panic! (the 'impossible' happened)" building vimus on NixOS In-Reply-To: <047.e4f44909e905adacb4005302519ba187@haskell.org> References: <047.e4f44909e905adacb4005302519ba187@haskell.org> Message-ID: <062.8440c99e62db64059ad794fd54d85849@haskell.org> #9825: ghc "panic! (the 'impossible' happened)" building vimus on NixOS -------------------------------------+------------------------------------- Reporter: jzellner | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.3 (Linker) | Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Compile-time | Test Case: crash | Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by JohnWiegley): As the OP mentioned, I can build this fine on any 64-bit compiler/OS flavor I try, but I don't have a 32-bit system at the moment to test this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 04:32:12 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 04:32:12 -0000 Subject: [GHC] #10826: [Security] Safe Haskell can be bypassed via annotations In-Reply-To: <045.6042fe6f9f535df81b6d3e710bdd3ea9@haskell.org> References: <045.6042fe6f9f535df81b6d3e710bdd3ea9@haskell.org> Message-ID: <060.14ff70080fba67b2804a156bd506cdc2@haskell.org> #10826: [Security] Safe Haskell can be bypassed via annotations -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by kanetw): Is there a reason why `checkSafeImports` etc. are in `Hsc` and not `TcM`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 04:46:37 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 04:46:37 -0000 Subject: [GHC] #8614: Duplicate symbol error when loading text twice In-Reply-To: <042.f86f42b094fe0faf9d18aa4da57dfc8a@haskell.org> References: <042.f86f42b094fe0faf9d18aa4da57dfc8a@haskell.org> Message-ID: <057.35c2581988e0afce23265762c923c28a@haskell.org> #8614: Duplicate symbol error when loading text twice -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #7030 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): OK, so I tried to reproduce with a very minimal example, using the following steps: 1. I took honi, and edited it so it had no dependence on the actual libraries. I installed it, and then manually edited package config so that it had a dependency on a non-existent dynamic library. 2. Then I opened GHCi, and induced GHCi to attempt to load the packages twice (failing because this last package couldn't load the non-existent package.) However, text reloaded fine for me. Granted, it was `text-1.2.1.3` but I don't think there is any substantive difference here. So yes, we are going to need more information to reproduce and solve this bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 05:00:45 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 05:00:45 -0000 Subject: [GHC] #9825: ghc "panic! (the 'impossible' happened)" building vimus on NixOS In-Reply-To: <047.e4f44909e905adacb4005302519ba187@haskell.org> References: <047.e4f44909e905adacb4005302519ba187@haskell.org> Message-ID: <062.2d62e8e3f0083d935cb2da0423a57ebd@haskell.org> #9825: ghc "panic! (the 'impossible' happened)" building vimus on NixOS -------------------------------------+------------------------------------- Reporter: jzellner | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.3 (Linker) | Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Compile-time | Test Case: crash | Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by JohnWiegley): I was able to reproduce this in a 32-bit VM. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 05:28:33 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 05:28:33 -0000 Subject: [GHC] #9825: ghc "panic! (the 'impossible' happened)" building vimus on NixOS In-Reply-To: <047.e4f44909e905adacb4005302519ba187@haskell.org> References: <047.e4f44909e905adacb4005302519ba187@haskell.org> Message-ID: <062.b3531a9b57f3516b28bd3d45cea399e2@haskell.org> #9825: ghc "panic! (the 'impossible' happened)" building vimus on NixOS -------------------------------------+------------------------------------- Reporter: jzellner | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.3 (Linker) | Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Compile-time | Test Case: crash | Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): So, I have a theory. However, it doesn't explain why the shindig works on 64-bit Linux. `nm_getyx` is defined in a cbits of the package being compiled. However, Cabal builds cbits AFTER the compilation of the actual package. This means that there isn't actually any object file which defines the symbol being looked for, so of course it fails. See https://github.com/haskell/cabal/issues/1738 for an existing report. Less clear, is why it manages to compile with 64-bit Linux. (On Mac OS X, there's lazy symbol resolution, so as long as you didn't actually use the symbol it will link up.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 05:31:37 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 05:31:37 -0000 Subject: [GHC] #10046: Linker script patch in rts/Linker.c doesn't work for (non-C or non-en..) locales In-Reply-To: <046.8d9180bf5eb50fbc94b5b6fcc0a45647@haskell.org> References: <046.8d9180bf5eb50fbc94b5b6fcc0a45647@haskell.org> Message-ID: <061.efa0f7c514f896178e2af482e5d8d71a@haskell.org> #10046: Linker script patch in rts/Linker.c doesn't work for (non-C or non-en..) locales -------------------------------------+------------------------------------- Reporter: hgolden | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Runtime System | Version: 7.8.4 (Linker) | Keywords: linker Resolution: | script Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: 2615, 9237 | Differential Revisions: -------------------------------------+------------------------------------- Description changed by ezyang: Old description: > Please see ticket:2615#comment:40 and replies. > > This error only occurs on systems where linker scripts are used. The > linker script patch (as it has evolved) assumes that the error messages > it will receive are in English. This would be true if the locale > (LC_MESSAGES) is C or en (or one of the en variants). However, in other > locales, the message will be in a different language. Unfortunately, the > semantics of POSIX dlerror() specify that the error is returned as a > pointer to a human-readable text string, rather than an error code. The > string returned depends on the locale. > > The code could be made more robust by momentarily changing the locale > (LC_MESSAGES) to C before calling dlerror() and reverting it to its > previous value immediately after. This has been tested on a zh_CN.utf-8 > (see ticket:2615#comment:42) and works. The only concern I have is in the > case of multithreaded code that _might_ be affected if it is running > while the locale is changed. I don't know enough to know if this is a > real issue or not, nor do I know how to deal with it if necessary. > > Also see ticket:9237 for another corner case in the linker script code > that should be dealt with at the same time. New description: Please see ticket:2615#comment:40 and replies. A bug is illustrated by this Haskell program: {{{ import ObjLink import Foreign import Foreign.C.Types import Foreign.C.String foreign import ccall "setlocale" c_setlocale :: CInt -> CString -> IO CString main = do withCString "zh_CN.UTF-8" $ \lc -> c_setlocale 5 lc r <- loadDLL "/usr/lib/libc.so" putStrLn (show r) }}} which outputs: {{{ Just "/usr/lib/libc.so: \26080\25928\30340 ELF \22836" }}} The "\26080\25928\30340 ELF \22836" part is "???ELF?" in Chinese. This error only occurs on systems where linker scripts are used. The linker script patch (as it has evolved) assumes that the error messages it will receive are in English. This would be true if the locale (LC_MESSAGES) is C or en (or one of the en variants). However, in other locales, the message will be in a different language. Unfortunately, the semantics of POSIX dlerror() specify that the error is returned as a pointer to a human-readable text string, rather than an error code. The string returned depends on the locale. The code could be made more robust by momentarily changing the locale (LC_MESSAGES) to C before calling dlerror() and reverting it to its previous value immediately after. This has been tested on a zh_CN.utf-8 (see ticket:2615#comment:42) and works. The only concern I have is in the case of multithreaded code that _might_ be affected if it is running while the locale is changed. I don't know enough to know if this is a real issue or not, nor do I know how to deal with it if necessary. Also see ticket:9237 for another corner case in the linker script code that should be dealt with at the same time. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 06:30:39 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 06:30:39 -0000 Subject: [GHC] #10046: Linker script patch in rts/Linker.c doesn't work for (non-C or non-en..) locales In-Reply-To: <046.8d9180bf5eb50fbc94b5b6fcc0a45647@haskell.org> References: <046.8d9180bf5eb50fbc94b5b6fcc0a45647@haskell.org> Message-ID: <061.be97984a0e6815ce0a4ac691a6765f29@haskell.org> #10046: Linker script patch in rts/Linker.c doesn't work for (non-C or non-en..) locales -------------------------------------+------------------------------------- Reporter: hgolden | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Runtime System | Version: 7.8.4 (Linker) | Keywords: linker Resolution: | script Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: 2615, 9237 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): hgolden, I actually am having difficulty running your script and reproducing the same output. There are two problems. First, the path that is in your example doesn't exist on my system. There are a few possible candidates: `/usr/lib/x86_64-linux-gnu/libc.so` is a linker script that has contents {{{ /* GNU ld script Use the shared library, but some functions are only in the static library, so try that secondarily. */ OUTPUT_FORMAT(elf64-x86-64) GROUP ( /lib/x86_64-linux-gnu/libc.so.6 /usr/lib/x86_64-linux- gnu/libc_nonshared.a AS_NEEDED ( /lib/x86_64-linux-gnu/ld- linux-x86-64.so.2 ) ) }}} Then, when I run the script compiled by GHC 7.6.3, I get `Nothing`. So I can't seem to coax out the Chinese output. BTW, in GHC 7.10 you need to initialize the object linker, otherwise it will segfault. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 08:17:44 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 08:17:44 -0000 Subject: [GHC] #10843: Allow do blocks without dollar signs as arguments Message-ID: <049.979a39a09d7a881598f53a6a6ce9bbe3@haskell.org> #10843: Allow do blocks without dollar signs as arguments -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: agibiansky Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- I would like the following to be valid Haskell code: {{{#!hs main = when True do putStrLn "Hello!" }}} Instead of requiring a dollar sign before the "do". This would parse as {{{#!hs main = when True (do putStrLn "Hello!") }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 08:30:13 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 08:30:13 -0000 Subject: [GHC] #10843: Allow do blocks without dollar signs as arguments In-Reply-To: <049.979a39a09d7a881598f53a6a6ce9bbe3@haskell.org> References: <049.979a39a09d7a881598f53a6a6ce9bbe3@haskell.org> Message-ID: <064.7e3f069c9661dfce4107c71fbaa910e3@haskell.org> #10843: Allow do blocks without dollar signs as arguments -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: agibiansky Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by agibiansky): I have an experimental implementation: https://phabricator.haskell.org/D1219 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 13:49:17 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 13:49:17 -0000 Subject: [GHC] #8614: Duplicate symbol error when loading text twice In-Reply-To: <042.f86f42b094fe0faf9d18aa4da57dfc8a@haskell.org> References: <042.f86f42b094fe0faf9d18aa4da57dfc8a@haskell.org> Message-ID: <057.b7e4b870c801b31e4a6e9656d24e3fe8@haskell.org> #8614: Duplicate symbol error when loading text twice -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 (Linker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #7030 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by nh2): * status: infoneeded => closed * resolution: => fixed Comment: OK, so first on how to get the deps: * freenect: `apt-get install libfreenect-dev` on Ubuntu 14.04 * OpenNI2: `git clone https://github.com/occipital/OpenNI2.git`, `cd OpenNI2`, `git checkout origin/develop` Then I compile with `$HOME/.local/bin/cabal install --extra-include- dirs=$HOME/src/OpenNI2/Include/ --extra-lib- dirs=$HOME/src/OpenNI2/Bin/x64-Release/` However, I have tried this now with GHC 7.10.2, and cabal-install 1.22.6.0, and can no longer reproduce the issue. My output: {{{ ? ghci GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help Prelude> import Honi Prelude Honi> import Honi.Types Prelude Honi Honi.Types> initialize 2 StatusOK }}} Trying the same with GHC 7.8: {{{ ~/.stack/programs/x86_64-linux/ghc-7.8.4/bin/ghc --interactive GHCi, version 7.8.4: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> import Honi Prelude Honi> import Honi.Types Prelude Honi Honi.Types> initialize 2 Loading package array-0.5.0.0 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package bytestring-0.10.4.0 ... linking ... done. Loading package containers-0.5.5.1 ... linking ... done. Loading package binary-0.7.1.0 ... linking ... done. Loading package text-1.2.1.3 ... linking ... done. Loading package honi-0.1.0.0 ... linking ... done. StatusOK }}} So I believe this was probably fixed with the linker improvements in GHC 7.8 (I reported the bug against 7.6). Thanks for poking at this bug, I'm happy to find that it is fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 15:05:39 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 15:05:39 -0000 Subject: [GHC] #10843: Allow do blocks without dollar signs as arguments In-Reply-To: <049.979a39a09d7a881598f53a6a6ce9bbe3@haskell.org> References: <049.979a39a09d7a881598f53a6a6ce9bbe3@haskell.org> Message-ID: <064.4e16925871769ac7ec0a6dfcc0f9e632@haskell.org> #10843: Allow do blocks without dollar signs as arguments -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: agibiansky Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by agibiansky: Old description: > I would like the following to be valid Haskell code: > > {{{#!hs > main = when True do > putStrLn "Hello!" > }}} > > Instead of requiring a dollar sign before the "do". This would parse as > > {{{#!hs > main = when True (do > putStrLn "Hello!") > }}} New description: I would like the following to be valid Haskell code: {{{#!hs main = when True do putStrLn "Hello!" }}} Instead of requiring a dollar sign before the "do". This would parse as {{{#!hs main = when True (do putStrLn "Hello!") }}} Similarly, allow lambdas in the same way {{{#!hs main = forM values \value -> print value }}} parses as {{{#!hs main = forM values (\value -> print value) }}} One possible question: does this also do the same thing for LambdaCase? It's an option but I would say no. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 15:54:18 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 15:54:18 -0000 Subject: [GHC] #10843: Allow do blocks without dollar signs as arguments In-Reply-To: <049.979a39a09d7a881598f53a6a6ce9bbe3@haskell.org> References: <049.979a39a09d7a881598f53a6a6ce9bbe3@haskell.org> Message-ID: <064.9ba4f135a3b3d31edb14a22a6b4a5b5e@haskell.org> #10843: Allow do blocks without dollar signs as arguments -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: agibiansky Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): Nice idea. Of course I am also annoyed by the `$`, but I sheepishly always assumed that there is a good reason for this. Is there code that is valid with and without your extension, but with different semantics? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 16:21:39 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 16:21:39 -0000 Subject: [GHC] #10844: CallStack should not be inlined Message-ID: <046.c5d6c4205be9804afd3acc1b71ee4c7b@haskell.org> #10844: CallStack should not be inlined -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- The use of CallStack based error messages (since changeset:6740d70d95cb) has led to some code size increase, and I believe this needs to be improved. While investigating the #10788, I was looking at the core produced by that code, and I found this in the code: {{{ -- RHS size: {terms: 2, types: 0, coercions: 0} Main.main17 :: [Char] [GblId, Str=DmdType, Unf=Unf{Src=, TopLvl=True, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 100 0}] Main.main17 = unpackCString# "vecto_20t0fI93Jj9LUbaZg6e04I"# -- RHS size: {terms: 2, types: 0, coercions: 0} Main.main16 :: [Char] [GblId, Str=DmdType, Unf=Unf{Src=, TopLvl=True, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 110 0}] Main.main16 = unpackCString# "Data.Vector.Primitive.Mutable"# -- RHS size: {terms: 2, types: 0, coercions: 0} Main.main15 :: [Char] [GblId, Str=DmdType, Unf=Unf{Src=, TopLvl=True, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 120 0}] Main.main15 = unpackCString# "./Data/Vector/Primitive/Mutable.hs"# -- RHS size: {terms: 2, types: 0, coercions: 0} Main.main14 :: Int [GblId, Caf=NoCafRefs, Str=DmdType, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 20}] Main.main14 = I# 97# -- RHS size: {terms: 2, types: 0, coercions: 0} Main.main13 :: Int [GblId, Caf=NoCafRefs, Str=DmdType, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 20}] Main.main13 = I# 16# -- RHS size: {terms: 2, types: 0, coercions: 0} Main.main12 :: Int [GblId, Caf=NoCafRefs, Str=DmdType, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 20}] Main.main12 = I# 21# -- RHS size: {terms: 8, types: 0, coercions: 0} Main.main11 :: SrcLoc [GblId, Str=DmdType, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 80}] Main.main11 = SrcLoc Main.main17 Main.main16 Main.main15 Main.main14 Main.main13 Main.main14 Main.main12 }}} This is clearly a CallStack from a library, and there is no point in copying that into the (every?) use of wherever that came from, as it will only increase code size and slow down compilation. I don?t know how to fix it, though. Float out CallStacks more aggressively? Or is the problem that unfoldings are recorded before that can happen? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 16:22:15 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 16:22:15 -0000 Subject: [GHC] #10844: CallStack should not be inlined In-Reply-To: <046.c5d6c4205be9804afd3acc1b71ee4c7b@haskell.org> References: <046.c5d6c4205be9804afd3acc1b71ee4c7b@haskell.org> Message-ID: <061.fea00b130cc30ab9ded08bd5528842c0@haskell.org> #10844: CallStack should not be inlined -------------------------------------+------------------------------------- Reporter: nomeata | Owner: gridaphobe Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by nomeata): * owner: => gridaphobe -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 16:28:25 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 16:28:25 -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.934f5815d9e315a466c0d4f4db55fed2@haskell.org> #2721: Newtype deriving doesn't work with type families -------------------------------------+------------------------------------- Reporter: rl | Owner: Type: feature request | Status: new Priority: lowest | Milestone: 7.12.1 Component: Compiler (Type | Version: 6.10.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deriving/should_fail/T2721 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by jkarni): * cc: jkarni@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 16:28:31 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 16:28:31 -0000 Subject: [GHC] #10788: performance regression involving minimum In-Reply-To: <047.bfa4fa3fe86eacf6fba28b5097b23381@haskell.org> References: <047.bfa4fa3fe86eacf6fba28b5097b23381@haskell.org> Message-ID: <062.b19babffa4ca423be07306ad0e7520ca@haskell.org> #10788: performance regression involving minimum -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): > So one solution would be to mark strictMinimum as INLINE, so that its unfolding stays small and both strictMinimum and foldl will be inlined at the use site? Tried that. The unfolding will then mention `foldr` instead of the above code, but is still too large. I was expecting the unfolding to mention `foldl1'`, as I thought the unfolding of something marked `INLINE` is never changed? Weird. Maybe someone else can give this a shot? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 16:49:12 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 16:49:12 -0000 Subject: [GHC] #10788: performance regression involving minimum In-Reply-To: <047.bfa4fa3fe86eacf6fba28b5097b23381@haskell.org> References: <047.bfa4fa3fe86eacf6fba28b5097b23381@haskell.org> Message-ID: <062.61486c53840184982e9b97157e6a546a@haskell.org> #10788: performance regression involving minimum -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): With {{{ {-# SPECIALIZE minimum :: [Int] -> Int #-} }}} instead of the rule rewriting it to strictMinimum, and *not* adding an INLINE pragma to `minimum`, I get good code in `GHC.List`, and this is being used here without too much inlining (it inlines the wrapper that distinguishes `[]` from a non-empty list and unboxes the int, but then calls the wrapper in `GHC.List.$wgo1`. Removing `INLINE` is important, as otherwise we?d be having this worker in every use of minimum. Even without `INLINE` we have this in the interface {{{ minimum :: Ord a => [a] -> a {- Arity: 2, Strictness: , Unfolding: (\ @ a11 $dOrd :: Ord a11 ds :: [a11] -> case ds of wild { [] -> minimum3 @ a11 : ipv ipv1 -> let { k :: a11 -> a11 -> a11 = min @ a11 $dOrd } in letrec { go :: [a11] -> a11 -> a11 {- Arity: 2, Strictness: -} = \ ds1 :: [a11] eta :: a11 -> case ds1 of wild1 { [] -> eta : y ys -> go ys (k eta y) } } in go ipv1 ipv }) -} }}} so more specialization in some client module seems to be possible. Adding `INLINEABLE` for reliability does not hurt, though. This seems to be the right thing to be doing here, but maybe not in general ? how can I tell? This is all so brittle... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 16:59:02 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 16:59:02 -0000 Subject: [GHC] #10375: arm: ghci hits an illegal instruction In-Reply-To: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> References: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> Message-ID: <059.03604b6a2022f3f9743a60e5efeecf36@haskell.org> #10375: arm: ghci hits an illegal instruction -------------------------------------+--------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+--------------------------------- Comment (by erikd): If I configure the build with `--enable-unregistered`, built it and then re-ran my tests. The program still crashes with SIGILL, but I now get a sensible backtrace: {{{ GHCi, version 7.11.20150905: http://www.haskell.org/ghc/ :? for help Program received signal SIGILL, Illegal instruction. 0x03ff9dbc in stg_ap_v_fast () (gdb) bt #0 0x03ff9dbc in stg_ap_v_fast () #1 0x03fc6ce6 in StgRun (f=0x3ff9db4 , basereg=0x49d2090 ) at rts/StgCRun.c:81 #2 0x03fca52a in schedule (initialCapability=0x49d2080 , task=0x49e62c0) at rts/Schedule.c:524 #3 0x03fcc5e6 in scheduleWaitThread (tso=0xb6c07000, ret=0x0, pcap=0xbeffeb74) at rts/Schedule.c:2429 #4 0x03fbc7e4 in rts_evalLazyIO (cap=0xbeffeb74, p=0x402d470 , ret=0x0) at rts/RtsAPI.c:500 #5 0x03fce2be in hs_main (argc=3, argv=0xbeffed64, main_closure=0x402d470 , rts_config=...) at rts/RtsMain.c:64 #6 0x00141508 in main () }}} and if I disassemble at the SIGILL I get: {{{ (gdb) disassemble Dump of assembler code for function stg_ap_v_fast: 0x03ff9db4 <+0>: push {r7, lr} 0x03ff9db6 <+2>: sub sp, #32 0x03ff9db8 <+4>: add r7, sp, #0 0x03ff9dba <+6>: ldr r3, [pc, #508] ; (0x3ff9fb8 ) => 0x03ff9dbc <+8>: ldr r3, [r3, #0] 0x03ff9dbe <+10>: and.w r3, r3, #3 }}} Now to figure out why that load instruction is illegal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 17:38:15 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 17:38:15 -0000 Subject: [GHC] #10375: arm: ghci hits an illegal instruction In-Reply-To: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> References: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> Message-ID: <059.15c34d62af26a610a1b2553b6639c957@haskell.org> #10375: arm: ghci hits an illegal instruction -------------------------------------+--------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+--------------------------------- Comment (by erikd): From: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0489c/CIHGJHED.html The instruction matches: {{{ op{type}{cond} Rt, [Rn, #offset]! ; pre-indexed }}} but the under the section titled "Register restrictions" it says: {{{ Rn must be different from Rt in the pre-index and post-index forms. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 17:56:42 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 17:56:42 -0000 Subject: [GHC] #9237: GHC not recognizing INPUT(-llibrary) in linker scripts In-Reply-To: <051.f95f4904e896de4fcf955563f575c874@haskell.org> References: <051.f95f4904e896de4fcf955563f575c874@haskell.org> Message-ID: <066.7fd2e96afb052af0fa5d97396f434c72@haskell.org> #9237: GHC not recognizing INPUT(-llibrary) in linker scripts -------------------------------------+------------------------------------- Reporter: mmikolajczyk | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Runtime System | Version: 7.8.2 (Linker) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: 2615, 10046 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hgolden): * failure: Compile-time crash => GHCi crash * component: Compiler (Linking) => Runtime System (Linker) * os: Unknown/Multiple => Linux Comment: Replying to [comment:2 rwbarton]: > Oh, hmm, I actually looked at the code and we do already inspect the error string from `dlopen` and try to parse a linker script. The problem is that we don't support `INPUT(-llibrary)`. I guess we can transform the name to `liblibrary.so` in that case? I think that's what's needed. I don't run Arch Linux right now. Maybe I'll have some time to install it in a VM and try out this approach. When I fixed #2615, the hardest part was generating a test to prove it worked. I envision the same difficulty here. > I still would like to avoid incurring dependencies on `.so`s that are really linker scripts, if possible... I don't see any way to avoid this unless we find a way to call `ld` as a helper. Doing this would be way beyond my level of understanding. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 18:47:49 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 18:47:49 -0000 Subject: [GHC] #781: GHCi on x86_64, cannot link to static data in shared libs In-Reply-To: <044.a73c522b97030f99c5fa39d521657f06@haskell.org> References: <044.a73c522b97030f99c5fa39d521657f06@haskell.org> Message-ID: <059.7eea7c88eaba29a81b7b45d4093b02d9@haskell.org> #781: GHCi on x86_64, cannot link to static data in shared libs -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Runtime System | Version: 6.5 (Linker) | Keywords: Resolution: | getEnvironment Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: GHCi crash | Test Case: | getEnvironment01 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonmar): * component: Compiler => Runtime System (Linker) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 18:50:53 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 18:50:53 -0000 Subject: [GHC] #10352: Properly link Haskell shared libs on ELF systems In-Reply-To: <045.f54c0b53e462b1ea305eb5f3c38d7688@haskell.org> References: <045.f54c0b53e462b1ea305eb5f3c38d7688@haskell.org> Message-ID: <060.376c45faeffcda4d64eb2e2b1ad2314c@haskell.org> #10352: Properly link Haskell shared libs on ELF systems -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (Linking) | Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonmar): * cc: simonmar (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 19:07:45 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 19:07:45 -0000 Subject: [GHC] #10843: Allow do blocks without dollar signs as arguments In-Reply-To: <049.979a39a09d7a881598f53a6a6ce9bbe3@haskell.org> References: <049.979a39a09d7a881598f53a6a6ce9bbe3@haskell.org> Message-ID: <064.e5a593772992c51b379bd5325a41a868@haskell.org> #10843: Allow do blocks without dollar signs as arguments -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: agibiansky Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by agibiansky: Old description: > I would like the following to be valid Haskell code: > > {{{#!hs > main = when True do > putStrLn "Hello!" > }}} > > Instead of requiring a dollar sign before the "do". This would parse as > > {{{#!hs > main = when True (do > putStrLn "Hello!") > }}} > > Similarly, allow lambdas in the same way > {{{#!hs > main = forM values \value -> > print value > }}} > > parses as > > {{{#!hs > main = forM values (\value -> > print value) > }}} > > One possible question: does this also do the same thing for LambdaCase? > It's an option but I would say no. New description: I would like the following to be valid Haskell code: {{{#!hs main = when True do putStrLn "Hello!" }}} Instead of requiring a dollar sign before the "do". This would parse as {{{#!hs main = when True (do putStrLn "Hello!") }}} Similarly, allow lambdas in the same way {{{#!hs main = forM values \value -> print value }}} parses as {{{#!hs main = forM values (\value -> print value) }}} One possible question: does this also do the same thing for LambdaCase? I think that since people expect lambda case to just be a simple desugaring it should also work, so then {{{#!hs main = forM values \case Just x -> print x Nothing -> print y }}} parses as {{{#!hs main = forM values (\case Just x -> print x Nothing -> print y) }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 19:21:51 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 19:21:51 -0000 Subject: [GHC] #10375: arm: ghci hits an illegal instruction In-Reply-To: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> References: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> Message-ID: <059.25c31c39e1597861a633427f527141b6@haskell.org> #10375: arm: ghci hits an illegal instruction -------------------------------------+--------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+--------------------------------- Comment (by erikd): Things to note: * Register `R0` is the argument/result/scratch register. * `stg_ap_v_fast` is generated CMM code generated by `utils/genapply`. * Since this is on Arm, the CMM code is passed throught the LLVM backend. Confirming that we are actually generating invalid Arm assembly: {{{ utils/genapply/dist/build/tmp/genapply > suspect.cmm inplace/bin/ghc-stage2 -Irts -c suspect.cmm -o suspect.o }}} and then `objdump -D suspect.o` and searching for `stg-ap_v_fast` results in: {{{ 0000853c : 853c: b480 push {r7} 853e: b087 sub sp, #28 8540: af00 add r7, sp, #0 8542: 4b76 ldr r3, [pc, #472] ; (871c ) 8544: 681b ldr r3, [r3, #0] }}} which is exactly what we found in GDB. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 19:39:04 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 19:39:04 -0000 Subject: [GHC] #10375: arm: ghci hits an illegal instruction In-Reply-To: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> References: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> Message-ID: <059.1b4d1b213e60b6325b444f2b760f8a5c@haskell.org> #10375: arm: ghci hits an illegal instruction -------------------------------------+--------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+--------------------------------- Comment (by erikd): Compiling as above with `-keep-s-file -keep-llvm-file`: {{{ stg_ap_v_fast$def: @ @"stg_ap_v_fast$def" .fnstart .Leh_func_begin69: @ BB#0: @ %cmL movw r0, :lower16:MainCapability movt r0, :upper16:MainCapability ldr r1, [r0, #16] and r2, r1, #3 cmp r2, #1 bne .LBB69_2 @ BB#1: @ %cmn ldr r0, [r1, #-1] ldr r0, [r0] }}} and the LLVM code: {{{ @stg_ap_v_fast = alias i8* bitcast (void ()* @stg_ap_v_fast$def to i8*) define ccc void @stg_ap_v_fast$def() align 4 nounwind { cmL: %lcmm = alloca i32, i32 1 %lcmA = alloca i32, i32 1 %lcmC = alloca i32, i32 1 %ln3zE = ptrtoint i8* @MainCapability to i32 %ln3zF = add i32 %ln3zE, 16 %ln3zG = inttoptr i32 %ln3zF to i32* %ln3zH = load i32* %ln3zG, !tbaa !5 %ln3zI = and i32 %ln3zH, 3 %ln3zJ = icmp eq i32 %ln3zI, 1 br i1 %ln3zJ, label %cmn, label %cmp cmp: %ln3zK = ptrtoint i8* @MainCapability to i32 %ln3zL = add i32 %ln3zK, 808 %ln3zM = inttoptr i32 %ln3zL to i32* %ln3zN = load i32* %ln3zM, !tbaa !5 %ln3zO = add i32 %ln3zN, -4 }}} which suggests this is an LLVM Arm code gen bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 20:44:41 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 20:44:41 -0000 Subject: [GHC] #10843: Allow do blocks without dollar signs as arguments In-Reply-To: <049.979a39a09d7a881598f53a6a6ce9bbe3@haskell.org> References: <049.979a39a09d7a881598f53a6a6ce9bbe3@haskell.org> Message-ID: <064.98b89bc2f9aa17b962e871c236e0686f@haskell.org> #10843: Allow do blocks without dollar signs as arguments -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: agibiansky Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by mpickering): How about case, if and let expressions? I personally found it a bit inconsistent that `id Record {..}` parsed correctly so this does bring the other expression types in line with that behaviour. On the other hand, I think the `$` is useful for the reader to indicate that what follows is the final single argument. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 20:46:48 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 20:46:48 -0000 Subject: [GHC] #10843: Allow do blocks without dollar signs as arguments In-Reply-To: <049.979a39a09d7a881598f53a6a6ce9bbe3@haskell.org> References: <049.979a39a09d7a881598f53a6a6ce9bbe3@haskell.org> Message-ID: <064.5cc077bff1740926fee3122b98a6d1bc@haskell.org> #10843: Allow do blocks without dollar signs as arguments -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: agibiansky Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by agibiansky): I don't see a common usecase for `case`, `if`, and `let`, and think we should not include them. The motivation for this change is that `do` and lambdas are very commonly used in custom control structures (`when`, `unless`, `for`, `forM`, `with*`, and so on). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 5 23:26:49 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Sep 2015 23:26:49 -0000 Subject: [GHC] #10845: Incorrect behavior when let binding implicit CallStack object Message-ID: <053.cff44270042de7bde1a56c8d798b5b0a@haskell.org> #10845: Incorrect behavior when let binding implicit CallStack object -------------------------------------+------------------------------------- Reporter: | Owner: nitromaster101 | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- I'm trying out ghc HEAD at 062feee4e7408ad5b9d882e5fed2c700e337db72. {{{#!hs {-# LANGUAGE ImplicitParams #-} import GHC.Types f :: (?loc :: CallStack) => Int f = let y = length $ getCallStack ?loc in if y < 2 then 3 else 4 f2 :: (?loc :: CallStack) => Int f2 = if (length $ getCallStack ?loc) < 2 then 3 else 4 f3 :: (?loc :: [Int]) => Int f3 = let y = length ?loc in if y < 2 then 3 else 4 }}} produces: {{{ [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:5:6: warning: Redundant constraint: ?loc::CallStack In the type signature for: f :: (?loc::CallStack) => Int }}} f3 doesn't produce an error which makes me think it's related to CallStack handling. The warning seems accurate: the returned callstack only contains the entry at f. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 6 00:03:05 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Sep 2015 00:03:05 -0000 Subject: [GHC] #10845: Incorrect behavior when let binding implicit CallStack object In-Reply-To: <053.cff44270042de7bde1a56c8d798b5b0a@haskell.org> References: <053.cff44270042de7bde1a56c8d798b5b0a@haskell.org> Message-ID: <068.51a1381ed7403b3644ac81517da3a978@haskell.org> #10845: Incorrect behavior when let binding implicit CallStack object -------------------------------------+------------------------------------- Reporter: nitromaster101 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * cc: gridaphobe (added) Comment: > f3 doesn't produce an error which makes me think it's related to CallStack handling. //What// is related to CallStack handling? What is the incorrect behavior? I'm sure it's obvious to you, but please mention it explicitly in the description. Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 6 00:34:19 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Sep 2015 00:34:19 -0000 Subject: [GHC] #10845: Incorrect behavior when let binding implicit CallStack object In-Reply-To: <053.cff44270042de7bde1a56c8d798b5b0a@haskell.org> References: <053.cff44270042de7bde1a56c8d798b5b0a@haskell.org> Message-ID: <068.82ea78a4b5022d975f326e36bb2bd2e7@haskell.org> #10845: Incorrect behavior when let binding implicit CallStack object -------------------------------------+------------------------------------- Reporter: nitromaster101 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nitromaster101): There are two issues: since f3 doesn't produce any warnings, neither should f since the only difference is the type of ?loc. If I add some callers to f and f2: {{{ {-# LANGUAGE ImplicitParams #-} import GHC.Types f :: (?loc :: CallStack) => String f = let y = show $ map (srcLocStartLine . snd) $ getCallStack ?loc in y f2 :: (?loc :: CallStack) => String f2 = show $ map (srcLocStartLine . snd) $ getCallStack ?loc f_caller = f f2_caller = f2 }}} We get the warning: {{{ [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:5:6: warning: Redundant constraint: ?loc::CallStack In the type signature for: f :: (?loc::CallStack) => String }}} And when we run them the call stack returned by f is wrong, it should have two entries (the line number for f_caller and f): {{{ *> f_caller "[6]" *> f2_caller "[10,13]" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 6 04:49:21 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Sep 2015 04:49:21 -0000 Subject: [GHC] #10845: Incorrect behavior when let binding implicit CallStack object In-Reply-To: <053.cff44270042de7bde1a56c8d798b5b0a@haskell.org> References: <053.cff44270042de7bde1a56c8d798b5b0a@haskell.org> Message-ID: <068.792b473723aa70b2d9fadc67dd4c6540@haskell.org> #10845: Incorrect behavior when let binding implicit CallStack object -------------------------------------+------------------------------------- Reporter: nitromaster101 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by gridaphobe): Hmm, it looks like the `?loc` constraint in `f` is being solved in an environment that doesn't include the given `?loc` from the function's context. Very strange, and certainly incorrect. Thanks for the report! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 6 05:04:01 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Sep 2015 05:04:01 -0000 Subject: [GHC] #10844: CallStack should not be inlined In-Reply-To: <046.c5d6c4205be9804afd3acc1b71ee4c7b@haskell.org> References: <046.c5d6c4205be9804afd3acc1b71ee4c7b@haskell.org> Message-ID: <061.74121b8d3d954bb460a18ba37a1f2253@haskell.org> #10844: CallStack should not be inlined -------------------------------------+------------------------------------- Reporter: nomeata | Owner: gridaphobe Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by gridaphobe): Just copying some notes from our discussion on phabricator for easy reference: gridaphobe: > - The increase in binary sizes (at least for the atom benchmark) is coming from a handful of modules in ghc-prim and base > - GHC/Types.o has increased by about 5K. It's now the home of the SrcLoc and CallStack types, which together define 7-8 record selectors, so I think this may not be too surprising. > - Control/Applicative.o, Data/Either.o, Data/Foldable.o, and a few others in base have increased in by 2-5K each. Every one of these modules contains at least one CallStack in the Core. > - The other modules I've looked at that have not increased in size do not have a CallStack, so it seems pretty clear that the increase *is* due to the CallStack. > - Finally, I think you're correct that the CallStacks are being inlined sometimes, because I found a CallStack referencing GHC.Base in Data.Foldable. nomeata: > I?m not quite sure what the best way is to prevent the sharing. Maybe the type checker, which produces the CallStack values, can be told to add the (core equivalent) of a NOINLINE pragma to them? --- I agree that CallStacks should not be inlined. Is there a core equivalent of a NOINLINE pragma? If so, it ought the be straightforward to have the desugarer attach it. Also, is there any extra cost to lifting all of the int and string components of a `SrcLoc` to top-level binders (which seems similarly pointless)? Or does it just clutter the Core output? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 6 05:09:40 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Sep 2015 05:09:40 -0000 Subject: [GHC] #10843: Allow do blocks without dollar signs as arguments In-Reply-To: <049.979a39a09d7a881598f53a6a6ce9bbe3@haskell.org> References: <049.979a39a09d7a881598f53a6a6ce9bbe3@haskell.org> Message-ID: <064.00f02c675bf509fa68c1be082db0a9bf@haskell.org> #10843: Allow do blocks without dollar signs as arguments -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: agibiansky Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Rufflewind): > I don't see a common usecase for case, if, and let I've certainly written code like this: {{{#!hs foo x = pure $ case x of Just _ -> True Nothing -> False }}} Personally I never understood why `$` was required to begin with. There's no sensible way to interpret `runST do ?` except as `runST (do ?)`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 6 07:32:29 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Sep 2015 07:32:29 -0000 Subject: [GHC] #1851: "make install-strip" should work In-Reply-To: <044.55b2dd35d7abad74f0ebfed90c4f828d@haskell.org> References: <044.55b2dd35d7abad74f0ebfed90c4f828d@haskell.org> Message-ID: <059.44f4d91a75b3e269009c12d8fd39d41a@haskell.org> #1851: "make install-strip" should work -------------------------------------+------------------------------------- Reporter: igloo | Owner: thomie Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.10.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by gidyn): The patch only seems to strip executables. This is appreciated, but stripping installed libraries with `--strip-unneeded` is also needed (and saves much more space than just stripping executables). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 6 08:30:39 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Sep 2015 08:30:39 -0000 Subject: [GHC] #1851: "make install-strip" should work In-Reply-To: <044.55b2dd35d7abad74f0ebfed90c4f828d@haskell.org> References: <044.55b2dd35d7abad74f0ebfed90c4f828d@haskell.org> Message-ID: <059.6e52ca1d7c4327217500238c3fd68419@haskell.org> #1851: "make install-strip" should work -------------------------------------+------------------------------------- Reporter: igloo | Owner: thomie Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.10.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): Haskell libraries are always stripped currently, using `--strip-unneeded` by Cabal. You don't need `make install-strip` for that. There was a bug in Cabal where .a files didn't get stripped for us, for a few releases, but that should be fixed now. https://github.com/haskell/cabal/pull/2782 The only libraries that aren't stripped are the those for the runtime system. I'm not sure they aren't. I might look into this later. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 6 16:48:58 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Sep 2015 16:48:58 -0000 Subject: [GHC] #10829: Simplification in the RHS of rules In-Reply-To: <046.7ca7c028ab82ec2d7ad263cb88680067@haskell.org> References: <046.7ca7c028ab82ec2d7ad263cb88680067@haskell.org> Message-ID: <061.0775e9b2adb23c24b3ffc6043f193035@haskell.org> #10829: Simplification in the RHS of rules -------------------------------------+------------------------------------- Reporter: afarmer | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 10528 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by conal): * cc: conal (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 6 17:02:49 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Sep 2015 17:02:49 -0000 Subject: [GHC] #10777: Overlong linker arguments on Windows leads to broken builds with confusing error messages In-Reply-To: <047.046a9f83230d0273c9346cd501403845@haskell.org> References: <047.046a9f83230d0273c9346cd501403845@haskell.org> Message-ID: <062.2ac9960d51c24151d0e26c2392cdff8f@haskell.org> #10777: Overlong linker arguments on Windows leads to broken builds with confusing error messages -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: snoyberg Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Linking) | Resolution: fixed | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #8596 #9685 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 6 17:03:01 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Sep 2015 17:03:01 -0000 Subject: [GHC] #8596: Add support for "reponse files" to workaround Windows command line length limitations In-Reply-To: <047.4af16120e3d32bd0dd2986d2dd5dd2de@haskell.org> References: <047.4af16120e3d32bd0dd2986d2dd5dd2de@haskell.org> Message-ID: <062.2a8528cef85614079fe2566ff3dcb448@haskell.org> #8596: Add support for "reponse files" to workaround Windows command line length limitations -------------------------------------+------------------------------------- Reporter: joeyhess | Owner: snoyberg Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10777 #9685 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 6 17:50:18 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Sep 2015 17:50:18 -0000 Subject: [GHC] #10846: PartialTypeSignatures change implicit CallStack behavior Message-ID: <053.4274e891f1314fe985c1165bde8fc4e5@haskell.org> #10846: PartialTypeSignatures change implicit CallStack behavior -------------------------------------+------------------------------------- Reporter: | Owner: nitromaster101 | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- I have two functions, f and f2 which are identical expect for the use of PartialTypeSignatures in f2. GHC produces a warning and says that f2's wildcard is filled in by String, which is correct. {{{#!hs {-# LANGUAGE ImplicitParams, PartialTypeSignatures #-} import GHC.Types f :: (?loc :: CallStack) => String f = show $ map (srcLocStartLine . snd) $ getCallStack ?loc f2 :: (?loc :: CallStack) => _ f2 = show $ map (srcLocStartLine . snd) $ getCallStack ?loc f_caller = f f2_caller = f2 }}} {{{ [1 of 1] Compiling Main ( Bug2.hs, interpreted ) Bug2.hs:8:30: warning: Found type wildcard ?_? standing for ?String? In the type signature for: f2 :: (?loc :: CallStack) => _ Ok, modules loaded: Main. *Main> f_caller "[6,11]" *Main> f2_caller "[9]" }}} f2_caller should have two entries (f2_caller's line and f2's line), just like f_caller. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 6 17:51:24 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Sep 2015 17:51:24 -0000 Subject: [GHC] #10846: PartialTypeSignatures change implicit CallStack behavior In-Reply-To: <053.4274e891f1314fe985c1165bde8fc4e5@haskell.org> References: <053.4274e891f1314fe985c1165bde8fc4e5@haskell.org> Message-ID: <068.4097c1d5b5d93e716a28bfa72e99ece1@haskell.org> #10846: PartialTypeSignatures change implicit CallStack behavior -------------------------------------+------------------------------------- Reporter: nitromaster101 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by nitromaster101): * cc: gridaphobe (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 6 17:54:22 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Sep 2015 17:54:22 -0000 Subject: [GHC] #10846: PartialTypeSignatures change implicit CallStack behavior In-Reply-To: <053.4274e891f1314fe985c1165bde8fc4e5@haskell.org> References: <053.4274e891f1314fe985c1165bde8fc4e5@haskell.org> Message-ID: <068.9419ecc037c485b9d0d181fd61aba893@haskell.org> #10846: PartialTypeSignatures change implicit CallStack behavior -------------------------------------+------------------------------------- Reporter: nitromaster101 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nitromaster101): Another version of f2 produces the same incorrect behavior: {{{#!hs f2 :: (?loc :: CallStack, _) => String f2 = show $ map (srcLocStartLine . snd) $ getCallStack ?loc }}} It's the same idea, but now the wildcard is in the constraints, even when it unifies with (). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 6 17:55:32 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Sep 2015 17:55:32 -0000 Subject: [GHC] #10846: PartialTypeSignatures change implicit CallStack behavior In-Reply-To: <053.4274e891f1314fe985c1165bde8fc4e5@haskell.org> References: <053.4274e891f1314fe985c1165bde8fc4e5@haskell.org> Message-ID: <068.3278ec53d7c2b0627f118a4da993b8d0@haskell.org> #10846: PartialTypeSignatures change implicit CallStack behavior -------------------------------------+------------------------------------- Reporter: nitromaster101 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by nitromaster101: Old description: > I have two functions, f and f2 which are identical expect for the use of > PartialTypeSignatures in f2. GHC produces a warning and says that f2's > wildcard is filled in by String, which is correct. > > {{{#!hs > {-# LANGUAGE ImplicitParams, PartialTypeSignatures #-} > > import GHC.Types > > f :: (?loc :: CallStack) => String > f = show $ map (srcLocStartLine . snd) $ getCallStack ?loc > > f2 :: (?loc :: CallStack) => _ > f2 = show $ map (srcLocStartLine . snd) $ getCallStack ?loc > > f_caller = f > f2_caller = f2 > }}} > {{{ > [1 of 1] Compiling Main ( Bug2.hs, interpreted ) > > Bug2.hs:8:30: warning: > Found type wildcard ?_? standing for ?String? > In the type signature for: > f2 :: (?loc :: CallStack) => _ > Ok, modules loaded: Main. > *Main> f_caller > "[6,11]" > *Main> f2_caller > "[9]" > }}} > > f2_caller should have two entries (f2_caller's line and f2's line), just > like f_caller. New description: I'm using GHC head at 062feee4e7408ad5b9d882e5fed2c700e337db72 I have two functions, f and f2 which are identical expect for the use of PartialTypeSignatures in f2. GHC produces a warning and says that f2's wildcard is filled in by String, which is correct. {{{#!hs {-# LANGUAGE ImplicitParams, PartialTypeSignatures #-} import GHC.Types f :: (?loc :: CallStack) => String f = show $ map (srcLocStartLine . snd) $ getCallStack ?loc f2 :: (?loc :: CallStack) => _ f2 = show $ map (srcLocStartLine . snd) $ getCallStack ?loc f_caller = f f2_caller = f2 }}} {{{ [1 of 1] Compiling Main ( Bug2.hs, interpreted ) Bug2.hs:8:30: warning: Found type wildcard ?_? standing for ?String? In the type signature for: f2 :: (?loc :: CallStack) => _ Ok, modules loaded: Main. *Main> f_caller "[6,11]" *Main> f2_caller "[9]" }}} f2_caller should have two entries (f2_caller's line and f2's line), just like f_caller. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 6 19:52:33 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Sep 2015 19:52:33 -0000 Subject: [GHC] #10847: :info should print minimal definition Message-ID: <043.c6e083f7f51bc9197fc9d4b0280ca574@haskell.org> #10847: :info should print minimal definition -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: feature | Status: new request | Priority: lowest | Milestone: Component: GHCi | Version: 7.11 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- It'd be great if `:info` would print minimal definitions too. This way we can implement a typeclass that we learn about using `:info` without having to look at the haddocks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 6 19:54:37 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Sep 2015 19:54:37 -0000 Subject: [GHC] #10848: GHC/GHCi should optionally print errors in reversed order Message-ID: <043.346863bae2dced560ac8325c22b2fccb@haskell.org> #10848: GHC/GHCi should optionally print errors in reversed order -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: feature | Status: new request | Priority: lowest | Milestone: Component: GHCi | Version: 7.11 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- This would be super useful especially when refactoring. The way I usually do refactoring is that I break things with a change, and then reload GHCi, fixing a couple of errors at a time. I almost always start with first error, which means I have to scroll every time I reaload GHCi. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 6 20:23:03 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Sep 2015 20:23:03 -0000 Subject: [GHC] #8809: Prettier error messages? In-Reply-To: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> References: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> Message-ID: <062.fad4a3e6585fa7129fa76e9c0b423759@haskell.org> #8809: Prettier error messages? -------------------------------------+------------------------------------- Reporter: joelteon | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): David Christiansen's talk at HIW 2015 is also relevant here, - [https://www.youtube.com/watch?v=m7BBCcIDXSg&list =PLnqUlCo055hVfNkQHP7z43r10yNo-mc7B&index=10 A pretty printer that says what it means (2015 edition)] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 6 20:41:11 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Sep 2015 20:41:11 -0000 Subject: [GHC] #10826: [Security] Safe Haskell can be bypassed via annotations In-Reply-To: <045.6042fe6f9f535df81b6d3e710bdd3ea9@haskell.org> References: <045.6042fe6f9f535df81b6d3e710bdd3ea9@haskell.org> Message-ID: <060.04e7eb824b29a83df6ebdc99f99f8359@haskell.org> #10826: [Security] Safe Haskell can be bypassed via annotations -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Sounds to me like we should just disable annotations entirely in Safe Haskell. I'm sure someone can be clever enough to sort out the monads, but no one is requesting this feature, to my knowledge. And it would be peculiar (but certainly conceivable) to use Safe Haskell and then inspect .hi files manually (or through `--show-iface`). So, unless there are objections: disable annotations in Safe Haskell. Do please add a note in the release notes about this. Given that it's a safety issue, I think it's reasonable to mark this "merge" so that the fix goes into 7.10.3. But others may differ here, as the change could kill existing non-malicious code. Also, in the error message that happens when a user tries an annotation in Safe Haskell, I think it would be best to include a link to this ticket, so that users who ''do'' want the feature have a nice place to make themselves known. Many thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 6 21:42:39 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Sep 2015 21:42:39 -0000 Subject: [GHC] #8405: experiment with using function-sections for linking (for smaller libs and executables) In-Reply-To: <045.ff128453c9ddce6d07b91486f573635a@haskell.org> References: <045.ff128453c9ddce6d07b91486f573635a@haskell.org> Message-ID: <060.61c77847773eff43427cb51836a31010@haskell.org> #8405: experiment with using function-sections for linking (for smaller libs and executables) -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by olsner): Another benefit of this would be getting rid of the satanic splitter, build system support for split objects, and any other splitting-related hacks there might be laying around. FWIW, I've been hacking at a patch to do this in the native code generator (https://github.com/olsner/ghc/commits/function-sections). It passes almost all of the test suite now, and generated binaries for a simple "hello world" did get smaller. But that's compared to a build without split objs - for some reason function sections doesn't seem to help nearly as much as split-objs... So that's something I'll want to fix first. I have also only tested this on Linux so far. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 6 22:01:04 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Sep 2015 22:01:04 -0000 Subject: [GHC] #10826: [Security] Safe Haskell can be bypassed via annotations In-Reply-To: <045.6042fe6f9f535df81b6d3e710bdd3ea9@haskell.org> References: <045.6042fe6f9f535df81b6d3e710bdd3ea9@haskell.org> Message-ID: <060.79b030553eeee12879bac1790af3ef7a@haskell.org> #10826: [Security] Safe Haskell can be bypassed via annotations -------------------------------------+------------------------------------- Reporter: spinda | Owner: kanetw Type: bug | Status: new Priority: highest | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by kanetw): * owner: => kanetw Comment: I'll submit my patch in a bit then. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 6 22:18:59 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Sep 2015 22:18:59 -0000 Subject: [GHC] #8405: experiment with using function-sections for linking (for smaller libs and executables) In-Reply-To: <045.ff128453c9ddce6d07b91486f573635a@haskell.org> References: <045.ff128453c9ddce6d07b91486f573635a@haskell.org> Message-ID: <060.191924209a9c9e94e98073cf05b5a61d@haskell.org> #8405: experiment with using function-sections for linking (for smaller libs and executables) -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): Yay, happy to hear someone is looking at this! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 6 22:57:17 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Sep 2015 22:57:17 -0000 Subject: [GHC] #10826: [Security] Safe Haskell can be bypassed via annotations In-Reply-To: <045.6042fe6f9f535df81b6d3e710bdd3ea9@haskell.org> References: <045.6042fe6f9f535df81b6d3e710bdd3ea9@haskell.org> Message-ID: <060.3425a48ce71f8a934f07d46798ed13ce@haskell.org> #10826: [Security] Safe Haskell can be bypassed via annotations -------------------------------------+------------------------------------- Reporter: spinda | Owner: kanetw Type: bug | Status: patch Priority: highest | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: phab:D1226 -------------------------------------+------------------------------------- Changes (by kanetw): * status: new => patch * differential: => phab:D1226 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 7 00:00:07 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Sep 2015 00:00:07 -0000 Subject: [GHC] #9907: "Unknown PEi386 section name `.text$printf'" error in GHCi on Windows In-Reply-To: <051.9bd9875fb01e6198fe81abe3cec3e53a@haskell.org> References: <051.9bd9875fb01e6198fe81abe3cec3e53a@haskell.org> Message-ID: <066.949e4722adaa32ff04f4a7e5249a64ba@haskell.org> #9907: "Unknown PEi386 section name `.text$printf'" error in GHCi on Windows -------------------------------------+------------------------------------- Reporter: mmikolajczyk | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: GHCi | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #7103, #10051, | Differential Revisions: Phab:D671 #7056, #8546 | -------------------------------------+------------------------------------- Changes (by Phyx-): * owner: => Phyx- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 7 00:04:33 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Sep 2015 00:04:33 -0000 Subject: [GHC] #10672: GHCi linker does not understand C++ exception tables on Windows In-Reply-To: <045.04cee7c60b130b0ccc29791ed61c4f5f@haskell.org> References: <045.04cee7c60b130b0ccc29791ed61c4f5f@haskell.org> Message-ID: <060.a39c32f1cc9d1337d903f597d2c01240@haskell.org> #10672: GHCi linker does not understand C++ exception tables on Windows -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Phyx- Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: Runtime System | Version: 7.10.1 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #9297 #10563 | Differential Revisions: #8237 #9907 | -------------------------------------+------------------------------------- Changes (by Phyx-): * owner: => Phyx- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 7 02:11:12 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Sep 2015 02:11:12 -0000 Subject: [GHC] #10843: Allow do blocks without dollar signs as arguments In-Reply-To: <049.979a39a09d7a881598f53a6a6ce9bbe3@haskell.org> References: <049.979a39a09d7a881598f53a6a6ce9bbe3@haskell.org> Message-ID: <064.3295d95553e254fbf5c0ac4538ca9656@haskell.org> #10843: Allow do blocks without dollar signs as arguments -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: agibiansky Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:3 nomeata]: > Is there code that is valid with and without your extension, but with different semantics? To me, this is the key question. I can't think of any. But let's dig deeper. I'm looking at the [https://www.haskell.org/onlinereport/haskell2010/haskellch3.html#x8-220003 Haskell 2010 Report] for parsing these sorts of things. Here's the relevant bit: {{{ exp ? infixexp :: [context =>] type (expression type signature) | infixexp infixexp? lexp qop infixexp (infix operator application) | - infixexp (prefix negation) | lexp lexp ? \ apat1 ? apatn -> exp (lambda abstraction, n ? 1) | let decls in exp (let expression) | if exp [;] then exp [;] else exp (conditional) | case exp of { alts } (case expression) | do { stmts } (do expression) | fexp fexp ? [fexp] aexp (function application) aexp ? qvar (variable) | gcon (general constructor) | literal | ( exp ) (parenthesized expression) | ( exp1 , ? , expk ) (tuple, k ? 2) | [ exp1 , ? , expk ] (list, k ? 1) | [ exp1 [, exp2] .. [exp3] ] (arithmetic sequence) | [ exp | qual1 , ? , qualn ] (list comprehension, n ? 1) | ( infixexp qop ) (left section) | ( qop?-? infixexp ) (right section) | qcon { fbind1 , ? , fbindn } (labeled construction, n ? 0) | aexp?qcon? { fbind1 , ? , fbindn } (labeled update, n ? 1) }}} From this grammar, I was inspired to try the following silliness: {{{ {-# LANGUAGE Haskell2010 #-} instance Num (IO ()) where negate = id main = - do putStrLn "hi" }}} (Note the `-` after the `main =`.) This fails with a parse error. I'd love for someone else to check this against the grammar and see if I should report a separate bug. How does this work in the patch supplied? In any case, even looking at the grammar, it looks like you've found a spot free in the grammar. How many shift/reduce conflicts does the grammar have? At last check, GHC's parser had 47. This isn't great, but we don't want to increase this number! Thanks for submitting a patch! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 7 02:26:36 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Sep 2015 02:26:36 -0000 Subject: [GHC] #9364: GHCi (or haskeline?) confused by non-single-width characters In-Reply-To: <046.188450f148764a8992314b4689d05445@haskell.org> References: <046.188450f148764a8992314b4689d05445@haskell.org> Message-ID: <061.a8f836d08ff1977e7ba604fe5536810f@haskell.org> #9364: GHCi (or haskeline?) confused by non-single-width characters -------------------------------------+------------------------------------- Reporter: cheater | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Resolution: | Keywords: linux, | terminal, colour, color, prompt Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #5850 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by joeljk13): Here's a more minimalistic way to see the first bug: To ~/.ghc/ghci.conf, add {{{ :set prompt "^[[0m^O" }}} which can be done with {{{ $ echo ":set prompt \"$(tput sgr 0)\"" >>~/.ghc/ghci.conf }}} Note that this prompt consists only of the terminal control sequence to reset any color, so effectively there should be no prompt at all. Then run ghci, type enough that it wraps to the next line, and press HOME. The cursor will move not to the very beginning of the line, as it should, but to column 4. I think the issue is simply that GHCi doesn't recognize terminal control sequences, and the fix would be to make it treat all terminal control sequences as width 0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 7 02:38:48 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Sep 2015 02:38:48 -0000 Subject: [GHC] #10847: :info should print minimal definition In-Reply-To: <043.c6e083f7f51bc9197fc9d4b0280ca574@haskell.org> References: <043.c6e083f7f51bc9197fc9d4b0280ca574@haskell.org> Message-ID: <058.b391c2546599cdd989c415fb0a76ab32@haskell.org> #10847: :info should print minimal definition -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: GHCi | Version: 7.11 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * cc: eir@? (added) Comment: Yes, please. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 7 03:07:29 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Sep 2015 03:07:29 -0000 Subject: [GHC] #10843: Allow do blocks without dollar signs as arguments In-Reply-To: <049.979a39a09d7a881598f53a6a6ce9bbe3@haskell.org> References: <049.979a39a09d7a881598f53a6a6ce9bbe3@haskell.org> Message-ID: <064.637707205b3143298c20bd254afe47a8@haskell.org> #10843: Allow do blocks without dollar signs as arguments -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: agibiansky Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by agibiansky): @goldfire: The GHC parser (when I cloned master) had 48 shift/reduce conflicts, and this change introduces no new ones (there are still 48). (Actually I just went back to master and recompiled and checked, because I didn't check back when I cloned.) Anyway, this patch introduces no new shift/reduce conflicts. The code {{{ main = - do putStrLn "Hello" }}} causes a parse error with my patch as before, with or without -XArgumentDo enabled. {{{ parse error on input do }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 7 08:00:50 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Sep 2015 08:00:50 -0000 Subject: [GHC] #10843: Allow do blocks without dollar signs as arguments In-Reply-To: <049.979a39a09d7a881598f53a6a6ce9bbe3@haskell.org> References: <049.979a39a09d7a881598f53a6a6ce9bbe3@haskell.org> Message-ID: <064.92b023dedb3c2fbda689d98192f9461a@haskell.org> #10843: Allow do blocks without dollar signs as arguments -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: agibiansky Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1219 -------------------------------------+------------------------------------- Changes (by simonpj): * differential: => Phab:D1219 Comment: I'm not against this, but not wildly in favour either. It might be convenient, but it's another small wrinkle. Some thoughts * Haskell allows {{{ f MkT { x = 3 } y z }}} meaning {{{ f (MkT {x = 3}) y z }}} which I have always thought of as a bit of a mistake. The former looks (to my eye) too much like a function call with four argument. However, you could argue that the `do` version is less harmful, because the initial `do` signals the start of a `do` block, whereas the initial `MkT` could be a bare constructor argument. * What do you intend for {{{ f x do { blarg } y z }}} Is that equivalent to this? {{{ f x (do { blarg }) y z }}} If so, better to say so. * Also give an example with layout. So perhaps {{{ f x do p <- ps return (p+1) z z }}} is equivalent to {{{ f x (do { p <- ps; return (p+1) }) y z }}} I think lambda-case is similar. * Lambda is different because it does not start implicit layout. So perhaps an un-parenthesised lambda can only appear as the last argument. Better say so. * If you allow lambda, why not `if`? And I suppose `case`? {{{ f x if this then that else the_other }}} means {{{ f x (if this then that else the_other }}} I suspect that this is a bridge too far, but I think it poses no more parsing difficulty than Lambda. Right? * What about infix functions? I.e. is this ok? {{{ f >>> do blarg }}} Presumably the `do` binds more tightly than any operator? I suggest that you make a wiki page on the GHC Trac to describe the extension, along with examples to cover these corner cases, and advertise it on the ghc-users list. That might elicit some info about whether people would find this useful or not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 7 08:17:02 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Sep 2015 08:17:02 -0000 Subject: [GHC] #10844: CallStack should not be inlined In-Reply-To: <046.c5d6c4205be9804afd3acc1b71ee4c7b@haskell.org> References: <046.c5d6c4205be9804afd3acc1b71ee4c7b@haskell.org> Message-ID: <061.2ce2ecd487dc4a9d7e7007bc58aa4d7d@haskell.org> #10844: CallStack should not be inlined -------------------------------------+------------------------------------- Reporter: nomeata | Owner: gridaphobe Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Can anyone give a concrete small example in which too much inlining is happening? (I agree there is absolutely no point in inlining literal strings.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 7 08:22:50 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Sep 2015 08:22:50 -0000 Subject: [GHC] #10788: performance regression involving minimum In-Reply-To: <047.bfa4fa3fe86eacf6fba28b5097b23381@haskell.org> References: <047.bfa4fa3fe86eacf6fba28b5097b23381@haskell.org> Message-ID: <062.12ad6906c71167ba3054168db63efacf@haskell.org> #10788: performance regression involving minimum -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): > This is all so brittle... I agree that brittle-ness is bad. Can you stand back and give a description of the brittle-ness? * Of course, if a function is inlined, it can be specialised for the call site, and without pragmas that decision is indeed dependent on how big the function is. I see no way to avoid that. * But pragmas should not be brittle. Can you show an example in which they seem to be. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 7 08:53:08 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Sep 2015 08:53:08 -0000 Subject: [GHC] #10844: CallStack should not be inlined In-Reply-To: <046.c5d6c4205be9804afd3acc1b71ee4c7b@haskell.org> References: <046.c5d6c4205be9804afd3acc1b71ee4c7b@haskell.org> Message-ID: <061.f3efe4ab873ddc9164a99340d2efd014@haskell.org> #10844: CallStack should not be inlined -------------------------------------+------------------------------------- Reporter: nomeata | Owner: gridaphobe Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): The source causing the above inlining of a CallStack looks like this: {{{#!hs instance Prim a => G.MVector MVector a where {-# INLINE basicUnsafeNew #-} basicUnsafeNew n | n < 0 = error $ "Primitive.basicUnsafeNew: negative length: " ++ show n | n > mx = error $ "Primitive.basicUnsafeNew: length to large: " ++ show n | otherwise = MVector 0 n `liftM` newByteArray (n * size) where size = sizeOf (undefined :: a) mx = maxBound `div` size :: Int }}} It is not surprising to me that an `error` in an INLINE function causes the CallStack to be inlined (although still rather pointless). You can reproduce this, if you have vector installed, by compiling the example program given in #10788. I tried to reproduce this with two smaller modules, i.e. {{{#!hs ==> T10844a.hs <== module T10844a where foo :: Int -> Int foo 0 = error "foo" foo n = n {-# INLINE foo #-} ==> T10844.hs <== module T10844 where import T10844a n :: Int n = 0 {-# NOINLINE n #-} main = print (foo n) }}} but it did *not* show this behavior. But when I change the first module to {{{#!hs module T10844a where class Foo a where foo :: a -> a instance Foo Int where foo 0 = error "foo" foo n = n {-# INLINE foo #-} }}} then `T10844` will contain a `CallStack` referencing a source location in `T10844a` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 7 09:07:43 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Sep 2015 09:07:43 -0000 Subject: [GHC] #10788: performance regression involving minimum In-Reply-To: <047.bfa4fa3fe86eacf6fba28b5097b23381@haskell.org> References: <047.bfa4fa3fe86eacf6fba28b5097b23381@haskell.org> Message-ID: <062.3075184222495c829146fcee494bee2f@haskell.org> #10788: performance regression involving minimum -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): > Can you stand back and give a description of the brittle-ness? I actually planned to write something to the list about this... and I [https://mail.haskell.org/pipermail/libraries/2015-September/026099.html now have]. In this particular case, I am quite happy with the `INLINEABLE`/`SPECIALIZE` solution, and will submit a DR soon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 7 09:29:43 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Sep 2015 09:29:43 -0000 Subject: [GHC] #10788: performance regression involving minimum In-Reply-To: <047.bfa4fa3fe86eacf6fba28b5097b23381@haskell.org> References: <047.bfa4fa3fe86eacf6fba28b5097b23381@haskell.org> Message-ID: <062.f71b832b8702e3e078f0c87ce4ae190f@haskell.org> #10788: performance regression involving minimum -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): > In this particular case, I am quite happy with the INLINEABLE/SPECIALIZE solution, and will submit a DR soon. Spoke too soon. Looking at the core of `List`, the `maximum` for `Int` is great (worker with a strict unboxed `Int`), but for `Integer`, the strictness analyzer is failing me, and I get this loop: {{{#!hs Rec { -- RHS size: {terms: 12, types: 8, coercions: 0} maximum_go [Occ=LoopBreaker] :: [Integer] -> Integer -> Integer [GblId, Arity=2, Caf=NoCafRefs, Str=DmdType ] maximum_go = \ (ds_a2d4 :: [Integer]) (eta_B1 :: Integer) -> case ds_a2d4 of _ [Occ=Dead] { [] -> eta_B1; : y_a2d9 ys_a2da -> maximum_go ys_a2da (integer-gmp-1.0.0.0:GHC.Integer.Type.$fOrdInteger_$cmax eta_B1 y_a2d9) } end Rec } }}} So it sees that `go` is strict in its second argument. Why is it then not strictly evaluated before the recursive call, avoiding this obvious space leak? Note that `max` is not inlined (as it is for Int), but the strictness data is there, so that should not make a difference. Anyways, I guess this discussion is derailing for this particular ticket. I?ll look into a combination of rewriting with `RULES` to `strictMinimum` to avoid relying on the strictness analyzer to produce good code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 7 09:59:16 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Sep 2015 09:59:16 -0000 Subject: [GHC] #10223: Cleanup `mk/build.mk.sample` In-Reply-To: <045.7ed59dbe44609faf808ed2eef55dcc31@haskell.org> References: <045.7ed59dbe44609faf808ed2eef55dcc31@haskell.org> Message-ID: <060.88f98fb695d6e81a1ee845773c4e3c23@haskell.org> #10223: Cleanup `mk/build.mk.sample` -------------------------------------+------------------------------------- Reporter: thomie | Owner: thomie Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"2c24fd707f8650205bb574ffac5f376239af3723/ghc" 2c24fd70/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2c24fd707f8650205bb574ffac5f376239af3723" Build system: put each BuildFlavour in a separate file (#10223) This allows easier diffing of different BuildFlavours, including `mk/flavours/validate.mk`. Reviewed By: bgamari, austin Differential Revision: https://phabricator.haskell.org/D1050 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 7 09:59:16 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Sep 2015 09:59:16 -0000 Subject: [GHC] #10223: Cleanup `mk/build.mk.sample` In-Reply-To: <045.7ed59dbe44609faf808ed2eef55dcc31@haskell.org> References: <045.7ed59dbe44609faf808ed2eef55dcc31@haskell.org> Message-ID: <060.6eb6262102a00c51227ce2ecc87ec21f@haskell.org> #10223: Cleanup `mk/build.mk.sample` -------------------------------------+------------------------------------- Reporter: thomie | Owner: thomie Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"b40e55954ecdab650d35349cbb93e53df952310e/ghc" b40e559/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b40e55954ecdab650d35349cbb93e53df952310e" Build system: simplify *-llvm BuildFlavours (#10223) Note that SRC_HC_OPTS are added to every Haskell compilation. So there isn't any need to also add `-fllvm` to GhcStage1HcOpts, GhcStage2HcOpts and GhcLibHcOpts. Small bug fix: make sure we test for -fllvm in SRC_HC_OPTS, to check whether the bootstrap compiler is affected by bug #9439. Reviewed by: austin Differential Revision: https://phabricator.haskell.org/D1188 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 7 09:59:16 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Sep 2015 09:59:16 -0000 Subject: [GHC] #9439: LlvmCodegen: Overzealous mangler incorrectly transforms user code In-Reply-To: <046.9a4e1bc549a42d7dea911589e68836d0@haskell.org> References: <046.9a4e1bc549a42d7dea911589e68836d0@haskell.org> Message-ID: <061.601c5375ec2fcbb47bec900e603199ab@haskell.org> #9439: LlvmCodegen: Overzealous mangler incorrectly transforms user code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.8.4 Component: Compiler (LLVM) | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 9268 Related Tickets: | Differential Revisions: Phab:D150 -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"b40e55954ecdab650d35349cbb93e53df952310e/ghc" b40e559/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b40e55954ecdab650d35349cbb93e53df952310e" Build system: simplify *-llvm BuildFlavours (#10223) Note that SRC_HC_OPTS are added to every Haskell compilation. So there isn't any need to also add `-fllvm` to GhcStage1HcOpts, GhcStage2HcOpts and GhcLibHcOpts. Small bug fix: make sure we test for -fllvm in SRC_HC_OPTS, to check whether the bootstrap compiler is affected by bug #9439. Reviewed by: austin Differential Revision: https://phabricator.haskell.org/D1188 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 7 11:20:46 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Sep 2015 11:20:46 -0000 Subject: [GHC] #10788: performance regression involving minimum In-Reply-To: <047.bfa4fa3fe86eacf6fba28b5097b23381@haskell.org> References: <047.bfa4fa3fe86eacf6fba28b5097b23381@haskell.org> Message-ID: <062.26a0a67437ddc00aa69c689ad675e82f@haskell.org> #10788: performance regression involving minimum -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"dc671a1c06736b192e4a53f580e17356ffa7224e/ghc" dc671a1c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="dc671a1c06736b192e4a53f580e17356ffa7224e" SPECIALIZE strictMinimum for Int and Integer This fixes a regression reported in #10788, where due to less inlining compared to earlier versions, we?d get worse code. With the SPECIALIZE, we get the good code, and moreover, the good code is in List.hs and _not_ inlined to the use site, so smaller code size and less compilation time. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 7 11:22:05 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Sep 2015 11:22:05 -0000 Subject: [GHC] #10788: performance regression involving minimum In-Reply-To: <047.bfa4fa3fe86eacf6fba28b5097b23381@haskell.org> References: <047.bfa4fa3fe86eacf6fba28b5097b23381@haskell.org> Message-ID: <062.ac1b3fbfa6912b489b8a9d29656e711b@haskell.org> #10788: performance regression involving minimum -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: ekmett Type: bug | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => closed * resolution: => fixed Comment: I applied a small (and probably uncontroversial) change that improves upon this particular issue. There is no good story for `minimum` applied to any other data type with a strict `min`, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 7 11:42:01 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Sep 2015 11:42:01 -0000 Subject: [GHC] #10847: :info should print minimal definition In-Reply-To: <043.c6e083f7f51bc9197fc9d4b0280ca574@haskell.org> References: <043.c6e083f7f51bc9197fc9d4b0280ca574@haskell.org> Message-ID: <058.e15858f6683c883130d5a565944ca898@haskell.org> #10847: :info should print minimal definition -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: GHCi | Version: 7.11 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): I think that would be good. Can anyone offer a patch? Just a minor modification to the code that prints the definition in response to `:info`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 7 11:42:54 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Sep 2015 11:42:54 -0000 Subject: [GHC] #10848: GHC/GHCi should optionally print errors in reversed order In-Reply-To: <043.346863bae2dced560ac8325c22b2fccb@haskell.org> References: <043.346863bae2dced560ac8325c22b2fccb@haskell.org> Message-ID: <058.14f7213ddb706ae1b306e3aa4493320f@haskell.org> #10848: GHC/GHCi should optionally print errors in reversed order -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: GHCi | Version: 7.11 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Not hard; there's one spot where errors are sorted by source location. You'd just need another flag, and user documentation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 7 11:53:19 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Sep 2015 11:53:19 -0000 Subject: [GHC] #10788: performance regression involving minimum In-Reply-To: <047.bfa4fa3fe86eacf6fba28b5097b23381@haskell.org> References: <047.bfa4fa3fe86eacf6fba28b5097b23381@haskell.org> Message-ID: <062.0b281d51a29567ff34a29e11bc42dfa5@haskell.org> #10788: performance regression involving minimum -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: ekmett Type: bug | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): And a slightly larger patch, which avoids the use of `strictMinimum`, for this is currently tested via Phabricator at Phab:1229. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 7 12:22:41 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Sep 2015 12:22:41 -0000 Subject: [GHC] #10849: Injective type families broke debug build Message-ID: <046.e8b4c4e36c78bdca2257be09559c6daa@haskell.org> #10849: Injective type families broke debug build -------------------------------------+------------------------------------- Reporter: nomeata | Owner: jstolarek Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Hi, since changeset:3744578 Travis observes these failures when built with DEBUG on: {{{ Compile failed (status 256) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.11.20150903 for x86_64-unknown-linux): ASSERT failed! file compiler/typecheck/TcInteract.hs, line 1381 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for T5490(normal) Actual stderr output differs from expected: --- ./indexed-types/should_fail/T5439.stderr.normalised 2015-09-03 04:54:51.184120403 +0000 +++ ./indexed-types/should_fail/T5439.comp.stderr.normalised 2015-09-03 04:54:51.184120403 +0000 @@ -1,25 +1,5 @@ +ghc: panic! (the 'impossible' happened) + (GHC version 7.11.20150903 for x86_64-unknown-linux): + ASSERT failed! file compiler/typecheck/TcInteract.hs, line 1381 -T5439.hs:82:28: - Couldn't match type ???Attempt (HElemOf rs)??? - with ???Attempt (HHead (HDrop n0 l0)) -> Attempt (HElemOf l0)??? - Expected type: f (Attempt (HNth n0 l0) -> Attempt (HElemOf l0)) - Actual type: f (Attempt (WaitOpResult (WaitOps rs))) - Relevant bindings include - register :: Bool -> Peano n -> WaitOps (HDrop n rs) -> IO Bool - (bound at T5439.hs:64:9) - ev :: f (Attempt (WaitOpResult (WaitOps rs))) - (bound at T5439.hs:61:22) - ops :: WaitOps rs (bound at T5439.hs:61:18) - registerWaitOp :: WaitOps rs - -> f (Attempt (WaitOpResult (WaitOps rs))) -> IO Bool - (bound at T5439.hs:61:3) - In the first argument of ???complete???, namely ???ev??? - In the expression: complete ev - -T5439.hs:82:39: - Couldn't match expected type ???Peano n0??? - with actual type ???Attempt ??0??? - In the second argument of ???($)???, namely - ???Failure (e :: SomeException)??? - In the second argument of ???($)???, namely - ???inj $ Failure (e :: SomeException)??? \ No newline at end of file +Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug \ No newline at end of file *** unexpected failure for T5439(normal) }}} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 7 12:25:12 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Sep 2015 12:25:12 -0000 Subject: [GHC] #10726: Upgrade MingW-w64 distributions for windows In-Reply-To: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> References: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> Message-ID: <059.05a422a19f91c2093c425d25eaa6f62f@haskell.org> #10726: Upgrade MingW-w64 distributions for windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: task | Status: merge Priority: normal | Milestone: 7.10.3 Component: Build System | Version: 7.11 Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9218 #9014 | Differential Revisions: Phab:D1123 #10435 | -------------------------------------+------------------------------------- Comment (by joozek78): @thomie Is there any estimate for this will be completed? When should I start to worry about this issue not being looked at? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 7 12:30:06 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Sep 2015 12:30:06 -0000 Subject: [GHC] #9500: Allow GHC defaults to be modified with an environment variable In-Reply-To: <045.8c4a73dd9f84bbbd2d69560ad3e1890f@haskell.org> References: <045.8c4a73dd9f84bbbd2d69560ad3e1890f@haskell.org> Message-ID: <060.307f6e9cc22979b863de81c833192887@haskell.org> #9500: Allow GHC defaults to be modified with an environment variable -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: closed Priority: lowest | Milestone: Component: Build System | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed Comment: Replying to [comment:4 thomie]: > Someone who understands the build system might be able to tell you. That would be me now. The [https://ghc.haskell.org/trac/ghc/wiki/Building/RunningNoFib documentation] says to use `EXTRA_HC_OPTS`. I checked, and that should indeed work. Please reopen if it doesn't. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 7 12:45:21 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Sep 2015 12:45:21 -0000 Subject: [GHC] #10849: Injective type families broke debug build In-Reply-To: <046.e8b4c4e36c78bdca2257be09559c6daa@haskell.org> References: <046.e8b4c4e36c78bdca2257be09559c6daa@haskell.org> Message-ID: <061.3ffa693bfb428134fc47343b6d1ecee4@haskell.org> #10849: Injective type families broke debug build -------------------------------------+------------------------------------- Reporter: nomeata | Owner: jstolarek Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by jstolarek): * cc: simonpj (added) Comment: Yes, I am aware of this breakage. Sadly, the cause lies in the solver code written by Simon and I am unable to fix it. I spoke to Simon about this at ICFP and he promised to take a look. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 7 12:47:47 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Sep 2015 12:47:47 -0000 Subject: [GHC] #10726: Upgrade MingW-w64 distributions for windows In-Reply-To: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> References: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> Message-ID: <059.e2977b6a5a89e42b5dfc12b3b6e9feaa@haskell.org> #10726: Upgrade MingW-w64 distributions for windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: task | Status: merge Priority: normal | Milestone: 7.10.3 Component: Build System | Version: 7.11 Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9218 #9014 | Differential Revisions: Phab:D1123 #10435 | -------------------------------------+------------------------------------- Comment (by thomie): It's not up to me to decide, but rather the 7.10 release manager's: bgamari or thoughtpolice. It's a rather big change though, and hasn't been tested much at all (!). Such large changes usually don't belong in a point release. But since it should make the GHC Windows experience much better, maybe we should make an exception. I just have no idea if there are any serious programs being compiled with GHC on Windows that might break because of this patch, and neither do bgamari or thoughtpolice I think, so maybe that would explain their hesitance to include it (correct me if I'm wrong). Maybe you or snoyberg could send out an email to the various mailinglists, asking if any Windows user is against including this patch. Note: last I heard, it's not even clear there will be a 7.10.3 (I'm not sure why not). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 7 12:52:39 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Sep 2015 12:52:39 -0000 Subject: [GHC] #9087: Executables in the Linux binaries are not stripped In-Reply-To: <045.32e06e6ec3c181db27d068784d01610c@haskell.org> References: <045.32e06e6ec3c181db27d068784d01610c@haskell.org> Message-ID: <060.440eba7ff58f083ba1e2079a6bb1b7b8@haskell.org> #9087: Executables in the Linux binaries are not stripped -------------------------------------+------------------------------------- Reporter: refold | Owner: thomie Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #1851 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 7 12:56:23 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Sep 2015 12:56:23 -0000 Subject: [GHC] #10726: Upgrade MingW-w64 distributions for windows In-Reply-To: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> References: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> Message-ID: <059.41afaf81c2f3339370fd4ce914ff055c@haskell.org> #10726: Upgrade MingW-w64 distributions for windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: task | Status: merge Priority: normal | Milestone: 7.10.3 Component: Build System | Version: 7.11 Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9218 #9014 | Differential Revisions: Phab:D1123 #10435 | -------------------------------------+------------------------------------- Comment (by simonpj): It is not that we have decided ''not'' to produce 7.10.3. It's just that we'll only produce it if it's actually needed! More specifically, we will produce 7.10.3 if (but only if) * there is a significant body of users * for whom 7.10.2 simply doesn't work * and there is no decent workaround they can use * and for which we can be reasonably sure that the fix isn't going to break anything else (necessitating 7.10.4 to mitigate). I don't know whether or not this ticket is in this category. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 7 12:59:52 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Sep 2015 12:59:52 -0000 Subject: [GHC] #10601: GHC should be distributed with debug symbols In-Reply-To: <046.ddcd45dcc3f972fc17c42b77b9184272@haskell.org> References: <046.ddcd45dcc3f972fc17c42b77b9184272@haskell.org> Message-ID: <061.d219285e73308eaaebfab13aac3e6f74@haskell.org> #10601: GHC should be distributed with debug symbols -------------------------------------+------------------------------------- Reporter: bitonic | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Build System | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): This requires a little more work than just adding `GhcRtsHcOpts += -g` and `GhcLibHcOpts += -g` to `mk/config.mk.in`. What is also needed is to no strip debug symbols from the libraries when running 'make install', but to only do that when running 'make install- strip'. Currently, ghc-cabal tells Cabal to strip the libraries on installation (with `--strip-unneeded`), unless `STRIP_CMD = :`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 7 13:27:10 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Sep 2015 13:27:10 -0000 Subject: [GHC] #10823: Don't mark functions with annotations as dead In-Reply-To: <045.57db4451919a86b3fcad053f0c16d552@haskell.org> References: <045.57db4451919a86b3fcad053f0c16d552@haskell.org> Message-ID: <060.13d87c13df479496a7ee75fabdf7ebb5@haskell.org> #10823: Don't mark functions with annotations as dead -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Well in this case the reason @spinda wants to keep the thing alive is because he is adding annotations to it. So using a distinguished annotation seems reasonable. But your general point is valid; a new pragma might also be fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 7 13:49:37 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Sep 2015 13:49:37 -0000 Subject: [GHC] #10476: Wrong ar during cross-compilation In-Reply-To: <046.928a748c0b21fd917210dee4be8c618c@haskell.org> References: <046.928a748c0b21fd917210dee4be8c618c@haskell.org> Message-ID: <061.56e8ff12927e2c2f5e2d9fb0d979c137@haskell.org> #10476: Wrong ar during cross-compilation -------------------------------------+------------------------------------- Reporter: jakzale | Owner: jakzale Type: bug | Status: new Priority: low | Milestone: Component: Build System | Version: 7.11 Resolution: | Keywords: cross- | compiling Operating System: MacOS X | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): jakzale: can you submit a patch to Phabricator? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 7 14:15:20 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Sep 2015 14:15:20 -0000 Subject: [GHC] #10476: Wrong ar during cross-compilation In-Reply-To: <046.928a748c0b21fd917210dee4be8c618c@haskell.org> References: <046.928a748c0b21fd917210dee4be8c618c@haskell.org> Message-ID: <061.3724e75a3d00e45a80f665484cbf9e35@haskell.org> #10476: Wrong ar during cross-compilation -------------------------------------+------------------------------------- Reporter: jakzale | Owner: thomie Type: bug | Status: new Priority: low | Milestone: Component: Build System | Version: 7.11 Resolution: | Keywords: cross- | compiling Operating System: MacOS X | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: Phab:D1231 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * owner: jakzale => thomie * related: => Phab:D1231 Comment: Nevermind, I just put a patch up myself. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 7 14:17:20 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Sep 2015 14:17:20 -0000 Subject: [GHC] #10726: Upgrade MingW-w64 distributions for windows In-Reply-To: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> References: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> Message-ID: <059.9792ef7b4c14b1ec1f607fe13ed810a1@haskell.org> #10726: Upgrade MingW-w64 distributions for windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: task | Status: merge Priority: normal | Milestone: 7.10.3 Component: Build System | Version: 7.11 Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9218 #9014 | Differential Revisions: Phab:D1123 #10435 | -------------------------------------+------------------------------------- Comment (by snoyberg): I can report that at least three separate users have reported to me the complete inability to build their projects on Windows with 7.10.2 or 7.8.4 without this patch (and the related response file fix). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 7 14:40:34 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Sep 2015 14:40:34 -0000 Subject: [GHC] #10850: Welche Slots kann man bei Stargames zocken Message-ID: <055.71183e7aa6bd604da4f262f1ea1f7dad@haskell.org> #10850: Welche Slots kann man bei Stargames zocken -------------------------------------+------------------------------------- Reporter: | Owner: thorben.dinse.rm | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Stargames ist eines der beliebtesten Online-Casinos der westlichen Hemisp?hre. Die riesige Auswahl an Novoline Spielen macht Stargames . Gerade die alten Spielhallen-Games, wie [https://stargames-de.com Sizzling Hot] sind besonders h?ufig gespielt. Diese sind nicht wie sie meistens Online zu finden ranzige Abklatsche, sondern professionell in Lizenz von Novoline erstellt und gen?gen h?chsten grafischen Anspr?chen. Sie sind ?bersichtlich designt, nicht zu ?berladen und erm?glichen einen schnellen Einstieg ins jeweilige Spiel. Daneben gibt es au?erdem eine gute Auswahl an verschiendenen Spielen die aus den Spielh?lle bekannt sind, wie zum Beispiel Bingo und Tuniere um f?r die notwendige Abwechslung und den Kontakt mit anderen Menschen zu sorgen. Als Tunier-Spiele werden fast t?glich jegliche Games bei denen mindestens zwei Menschen gegen- oder miteinandern spielen m?ssen von dem Anbieter angeboten. Es gibt eine extra Tunier-?bersicht in der alle wichtigen Informationen verlautet werden. Man kann sich seine Lieblingsspiele markieren und sich f?r sie einschreiben, sodass man keines verpasst. Da [https://stargames-de.com Stargames] ein Online-Unternehmen ist kann es die durch die sogut wie nicht vorhandenen Miet- und Personalkosten die Gewinne direkt an den Kunden weitergeben. Was freilich nicht nur den Kunden sehr erfreut sondern Stargames gerade gegen?ber klassischen Casinos einen besonderen Vorteil erm?glicht von dem Kunde und Anbieter profitieren. Die Aussch?ttungsquote ist siebenundneunzig% anstatt der branchen?blichen sechzig%. Das hei?t von 100 im auf der Seite eingezahlten ? werden siebenundneunzig Euro wieder an die Spieler von der Seite abgegeben - und das alles ohne den Schreibtisch zu verlassen oder vorab eine Software downloaden und installiern zu m?ssen, denn der Umgang ist bequem und erfordert nur die Anmeldung bei Stargames. Die Seite ist mit jeder Menge Unterpunkten sehr einfach gestaltet und f?r jeden Menschen selbst erschlie?end aufgebaut. Da viele, vor allem ?ltere, Kunden Ber?hrungs?ngste vor Online-Casionos haben kann man au?erdem alle Spiele frei von Kosten vorher anspielen, sodass man sich zun?chst eingew?hnen und sich selbst von der Virtuellen- Vatiante der klassischen Casino-Spiele ?berzeugen kann. Danach kann man immer noch, wenn es einem gef?llt, fix Geld einzahlen und um richtiges Geld spielen, was das richtige Gef?hl eines Casinos zu erleben. Als Virtuelles-Casino hat Stargames des Weiteren den Vorteil, dass man auf keinen anderen warten muss und direkt beginnen kann seinen Wunsch vom schnellen Aufbessern des eigenen Kontostandes umzusetzten. Es ist alles einfach und ohne Restriktionen verf?gbar, das nervt?tende Warten auf einen freien Platz oder ?hnliches ist damit vorbei. Und das alles mit einer einfachen Einschreibung. Was ist der Stargames Bonus Viele Leute haben schon mit Stargames Erfahrungen im Bonusprogramm gemacht. Um eure Zufriedenheit gleich zu Beginn zu st?rken und die Menschen zum Spielen zu anzuregen gibt es bei Stargames instant einen Bonus auf die erste Einzahlung im Spiel. Man bekommt 100Prozent und bis zu hundert ? auf seine erste Einzahlung als Bonus verbucht - Einzig wichtig um sich den Schotter auszahlen zu lassen ist dabei, dass Das Bonus- Guthaben zwanzig mal Umgesetzt wurde, was gemessen an anderen Anbietern sehr anst?ndig gestaltet und schnell zu erreichen ist. Selbstverst?ndlich gibt es weitere Bonus Programme f?r treue Zocker und Mitglieder, die Freunde werben. So sammelt das Mitglied beim Spielen mit richtigem Geld Punkte mit denen aufsteigende Level freigeschaltet werden. Je h?her das Level desto h?her wird der Bonus, den der Zocker ausgezahlt bekommt und desto ?fter kann man sich sein Schotter auszahlen lassen. Noch dazu gibt es f?r jeden geworbenen Freund zehn ? Guthaben gutgeschrieben. Zum Ende ist anzumerken, dass das Bonusprogramm zwar eher klein, aber die erw?nschten Ziele auf jeden Fall leicht f?r den Zocker zu erreichen sind. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 7 14:43:47 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Sep 2015 14:43:47 -0000 Subject: [GHC] #10851: Welche Automaten-Spiele kann man bei Stargames spielen Message-ID: <055.5c57bc7509ed4fb4f886ba9295b79e2a@haskell.org> #10851: Welche Automaten-Spiele kann man bei Stargames spielen -------------------------------------+------------------------------------- Reporter: | Owner: thorben.dinse.rm | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Stargames ist eines der beliebtesten Online-Casinos der Welt. Die enorme Auswahl an Novoline Spielen macht Stargames . Gerade die alten Spielhallen-Games, wie Sizzling-Hot sind besonders oft gezockt. Diese sind nicht wie sie meistens Online zu finden einfache Abklatsche, sondern professionell in Lizenz von Novoline programmiert und gen?gen h?chsten Anspr?chen. Sie sind ?bersichtlich designt, nicht zu kompliziert und erm?glichen einen leichten Einstieg ins jeweilige Spiel. Daneben gibt es unter anderem eine gro?e Auswahl an unterschiedlichen Spielen die aus den Spielh?lle bekannt sind, wie zum Beispiel Brettspiele und Tuniere um f?r die wichtige Vielfalt und den Austausch mit anderen Spielern zu sorgen. Als Tunier-Games werden beinahe t?glich jegliche Games bei denen mindestens zwei Leute gegen- oder miteinandern zocken m?ssen von Stargames angeboten. Es gibt eine extra Tunier-Kategorie in der alle wichtigen Infos verk?ndet gegeben werden. Man kann sich seine Lieblingsgames festhalten und sich f?r sie einschreiben, sodass man nichts verpasst. Da Stargames ein Online Casino ist kann es die durch die sogut wie nicht vorhandenen Kosten f?r Filialen und Personal die Gewinne direkt an dich weitergeben. Was freilich nicht nur jeden positiv stimmt sondern Stargames gerade gegen?ber anderen Spiel-Anbietern einen besonderen Vorteil bringt von dem beide Seiten profitieren. Die Aussch?ttungsquote liegt bei siebenundneunzig% anstatt der branchen?blichen sechzig%. Das hei?t von 100 im im Game eingezahlten ? werden siebenundneunzig ? wieder an die Gamer von dem Betreiber ausbezahlt - und das alles ohne sein Heim zu verlassen oder erstmal etwas herunterladen und installiern zu m?ssen, denn die Handhabung ist wirklich leicht und erfordert nur die Eintragung bei [https ://stargames-de.com Stargames]. Die Seite ist mit diversen Kategorien gerade zu einfach erstellt und f?r jeden Menschen selbst erschlie?end aufgebaut. Da viele, vor allem ?ltere, Menschen Ber?hrungs?ngste vor Online-Anbietern haben kann man au?erdem alle Spiele kostenfrei vorher testen, sodass man sich erstmal eingew?hnen und sich selbst von der Virtuellen Variante der alten Casino-Spiele ?berzeugen kann. Danach kann man immer noch, wenn es einem gef?llt, easy Geld einzahlen und um richtiges Geld spielen, was das richtige Gef?hl eines Casinos aufkommen l?sst. Als Online Anbieter hat Stargames weiter den Vorteil, dass man auf niemanden warten muss und promt anfangen kann seinen Traum vom schnellen Aufbessern des eigenen Kontostandes umzusetzten. Es ist alles direkt und ohne H?rden verf?gbar, das unangenehme Warten auf einen freien Tisch oder ?hnliches hat damit sein Ende. Und das alles mit einer easy Einschreibung. Was f?r Erfahrungen wurden mit dem [https://stargames-de.com Stargames Bonus] gemacht Viele Kunden haben schon mit Stargames Erfahrungen im Bonusprogramm zusammengetragen. Um eure Zufriedenheit gleich vom Anfang an zu erh?hen und den Zocker zum Spielen zu begeistern gibt es bei Stargames direkt einen Bonus auf die erste Einzahlung im Game. Du bekommst 100Prozent und bis zu 100 ? auf seine erste Einzahlung als Bonus gutgeschrieben - einzige Bedingung um sich Das Guthaben auszahlen zu lassen ist dabei, dass das Geld zwanzig mal Umgesetzt wurde, was gemessen an anderen Casinos sehr gut gestaltet und schnell auszuf?hren ist. Selbstverst?ndlich gibt es diverse Bonus Programme f?r treue Kunden und Mitglieder, die Freunde werben. So sammelt der Zocker beim Daddeln mit richtigem Geld Punkte mit denen aufsteigende Ebenen freigeschaltet werden. Je h?her die Ebene desto h?her wird der Bonus, den der Kunde ausgezahlt bekommt und desto ?fter kann man sich sein Geld auszahlen lassen. Noch dazu gibt es f?r jeden geworbenen Freund zehn Euro Guthaben angerechnet. Zum Schlu? ist zu bemerken, dass das Bonusprogramm zwar eher klein, aber die erw?nschten Ziele auf jeden Fall leicht f?r den Spieler zu erreichen sind. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 7 15:27:25 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Sep 2015 15:27:25 -0000 Subject: [GHC] #1830: Automatic derivation of Lift In-Reply-To: <044.3eb409743bc4021eb94e63cb46f573bc@haskell.org> References: <044.3eb409743bc4021eb94e63cb46f573bc@haskell.org> Message-ID: <059.6051107513eee8ff7d5ef340a052f971@haskell.org> #1830: Automatic derivation of Lift -------------------------------------+------------------------------------- Reporter: guest | Owner: | RyanGlScott Type: feature request | Status: new Priority: normal | Milestone: ? Component: Template Haskell | Version: 6.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1168 -------------------------------------+------------------------------------- Comment (by RyanGlScott): I've started a ghc-devs mailing list thread for discussion: https://mail.haskell.org/pipermail/ghc-devs/2015-September/009838.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 7 17:37:22 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Sep 2015 17:37:22 -0000 Subject: [GHC] #10852: ghc 7.8.4 on arm - panic: Simplifier ticks exhausted Message-ID: <051.6de3bb6380bb073196bb38e7623ede92@haskell.org> #10852: ghc 7.8.4 on arm - panic: Simplifier ticks exhausted -------------------------------------+------------------------------------- Reporter: | Owner: andrewufrank | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Linux Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- i tried to compile (cabal install) chatter-0.5.2.0 on a armbian (debian jessie, with ghc 7.10.2-1 from testing, running on a cubietruck ARMHF Cortex A20) and get in file NLP.Corpora.Conll a panic: [ 9 of 23] Compiling NLP.Corpora.Conll ( src/NLP/Corpora/Conll.hs, dist/build/NLP/Corpora/Conll.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for arm-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone $fGSerialize:*:_$s<$> 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: 2748218 i do not notice anything particular in the code, except a very long data type with enumerated values. I tried with a higher value for tick-factor (1000) with no improvement. i will now try to run 7.10.2-2 from experimental. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 7 18:09:16 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Sep 2015 18:09:16 -0000 Subject: [GHC] #10852: ghc 7.8.4 on arm - panic: Simplifier ticks exhausted In-Reply-To: <051.6de3bb6380bb073196bb38e7623ede92@haskell.org> References: <051.6de3bb6380bb073196bb38e7623ede92@haskell.org> Message-ID: <066.4bac62c99790ba6410055c1e74f13fa6@haskell.org> #10852: ghc 7.8.4 on arm - panic: Simplifier ticks exhausted -------------------------------------+------------------------------------- Reporter: andrewufrank | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by andrewufrank): with 7.10.2-2 from debian experimental i have the same result. the code works on 7.10.1 on amd64, thus it appears to be a problem with the armhf compiler. thank you for advancing the arm ghc compiler. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 7 19:33:09 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Sep 2015 19:33:09 -0000 Subject: [GHC] #10788: performance regression involving minimum In-Reply-To: <047.bfa4fa3fe86eacf6fba28b5097b23381@haskell.org> References: <047.bfa4fa3fe86eacf6fba28b5097b23381@haskell.org> Message-ID: <062.53060859dbbbde4e8dff2b3b80cd11ad@haskell.org> #10788: performance regression involving minimum -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: ekmett Type: bug | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"c6b82e99f41e03d4b101b3a32312defad711f56a/ghc" c6b82e99/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c6b82e99f41e03d4b101b3a32312defad711f56a" Further simplify the story around minimum/maximum After I have found out that I should look at -ddump-prep and not -ddump-core, I noticed that these days, GHC is perfectly capeable of turning (the equivalent) of foldl to (the equivalent) of foldl' if the operation in question is strict. So instead of using rewrite rules to rewrite maximum to a strictMaximum for certain types, we simply use SPECIALIZE. This also marks maximum/minimum as INLINEABLE, so that client code can get similar specializations, hopefully even automatically. And inded, minimum applied to [Double] produces good code (although due to inlineing, not due to specialization, it seems). I checked (by looking at the core) that this still fixes #10788. Differential revision: https://phabricator.haskell.org/D1229 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 7 22:02:56 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Sep 2015 22:02:56 -0000 Subject: [GHC] #10788: performance regression involving minimum In-Reply-To: <047.bfa4fa3fe86eacf6fba28b5097b23381@haskell.org> References: <047.bfa4fa3fe86eacf6fba28b5097b23381@haskell.org> Message-ID: <062.92835af6957937a347df5a0aca5c61ff@haskell.org> #10788: performance regression involving minimum -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: ekmett Type: bug | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): > Update: I looked into this, and it seems that even if -ddump-simpl looks like this, with a space-leaky way of accumulating the argument, that in the CorePrep stage the evaluation of cmax is pulled before the call to go and alls is well. I did not know that there are still such things going on in that stage. Suppose we have a function call `f (g x)` and `f` is strict. Then GHC keeps it looking like that so that rewrite rules apply easily. In `CorePrep` GHC just makes the order of evaluation explicit, by moving to {{{ case (g x) of y -> f y }}} There is no new analysis; the call always was call-by-value; but after `CorePrep` that fact is 100% explicit. I believe that the conclusion here is that GHC is behaving perfectly predictably; but library authors need to take a little care with pragmas and rules if they want to get predictable fusion. That's what your email in comment:9 is about, if I read it right. That is, you are not seeking any change to GHC. Correct? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 8 00:03:46 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Sep 2015 00:03:46 -0000 Subject: [GHC] #10852: ghc 7.8.4 on arm - panic: Simplifier ticks exhausted In-Reply-To: <051.6de3bb6380bb073196bb38e7623ede92@haskell.org> References: <051.6de3bb6380bb073196bb38e7623ede92@haskell.org> Message-ID: <066.f1f2dd788ad5b79f5f1915a8829e4736@haskell.org> #10852: ghc 7.8.4 on arm - panic: Simplifier ticks exhausted -------------------------------------+------------------------------------- Reporter: andrewufrank | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * Attachment "InstanceSerialize.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 8 00:42:25 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Sep 2015 00:42:25 -0000 Subject: [GHC] #10852: ghc 7.8.4 on arm - panic: Simplifier ticks exhausted In-Reply-To: <051.6de3bb6380bb073196bb38e7623ede92@haskell.org> References: <051.6de3bb6380bb073196bb38e7623ede92@haskell.org> Message-ID: <066.a2be7e44d509fc400874d72f696916bd@haskell.org> #10852: ghc 7.8.4 on arm - panic: Simplifier ticks exhausted -------------------------------------+------------------------------------- Reporter: andrewufrank | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * Attachment "InstanceSerialize.log" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 8 00:44:13 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Sep 2015 00:44:13 -0000 Subject: [GHC] #10852: ghc 7.8.4 on arm - panic: Simplifier ticks exhausted In-Reply-To: <051.6de3bb6380bb073196bb38e7623ede92@haskell.org> References: <051.6de3bb6380bb073196bb38e7623ede92@haskell.org> Message-ID: <066.7f53423cfdf3434bc061f25ae0f76e5d@haskell.org> #10852: ghc 7.8.4 on arm - panic: Simplifier ticks exhausted -------------------------------------+------------------------------------- Reporter: andrewufrank | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #5642, #9675 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * related: => #5642, #9675 Comment: I can't reproduce that panic on x86-64 Linux with ghc-7.10.2, but do notice GHC needs an awful lot of memory to compile `chatter`. My laptop starts swapping. I extracted an example. Run `cabal install cereal-0.4.1.0` first (`cereal` doesn't have dependencies itself, and doesn't take long to build). {{{ $ ghc-7.10.2 -fforce-recomp InstanceSerialize.hs -dshow-passes -O +RTS -s 105,749,837,048 bytes allocated in the heap 34,168,091,184 bytes copied during GC 1,094,766,416 bytes maximum residency (31 sample(s)) 13,390,536 bytes maximum slop 2797 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 2770 colls, 0 par 109.295s 117.115s 0.0423s 2.0924s Gen 1 31 colls, 0 par 124.908s 198.248s 6.3951s 25.1279s TASKS: 4 (1 bound, 3 peak workers (3 total), using -N1) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.001s ( 0.001s elapsed) MUT time 284.506s (326.497s elapsed) GC time 234.203s (315.363s elapsed) EXIT time 0.001s ( 0.001s elapsed) Total time 518.747s (641.862s elapsed) Alloc rate 371,696,208 bytes per MUT second Productivity 54.9% of total user, 44.3% of total elapsed gc_alloc_block_sync: 0 whitehole_spin: 0 gen[0].sync: 0 gen[1].sync: 0 }}} The full log is attached. I notice the number of terms increases by a factor of 8 after the first simplifier pass. I don't know if that is normal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 8 05:36:38 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Sep 2015 05:36:38 -0000 Subject: [GHC] #10375: arm: ghci hits an illegal instruction In-Reply-To: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> References: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> Message-ID: <059.3660470a027f2bfb4e98621edde6d2d1@haskell.org> #10375: arm: ghci hits an illegal instruction -------------------------------------+--------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+--------------------------------- Comment (by erikd): Got some help from the llvm-dev mailing list. People there pointed out that this: {{{ (gdb) disassemble Dump of assembler code for function stg_ap_v_fast: 0x03ff9db4 <+0>: push {r7, lr} 0x03ff9db6 <+2>: sub sp, #32 0x03ff9db8 <+4>: add r7, sp, #0 0x03ff9dba <+6>: ldr r3, [pc, #508] ; (0x3ff9fb8 ) => 0x03ff9dbc <+8>: ldr r3, [r3, #0] 0x03ff9dbe <+10>: and.w r3, r3, # }}} show the CPU executing Thumb instructions. Thumb instructions are encoded in two btyes (and hence instructions with addresses that are even) while Arm instructions are encoded in 4 bytes (so instructions should be aligned at 4 bytes offsets). This could be that GDB getting the CPU mode incorrect. Not sure how to figure out if that is the case or even if and how that could happen. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 8 06:54:50 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Sep 2015 06:54:50 -0000 Subject: [GHC] #10806: Type error and type level (<=) together cause GHC to hang In-Reply-To: <048.9b3d349db1bfdcff1a2e281d43595c9a@haskell.org> References: <048.9b3d349db1bfdcff1a2e281d43595c9a@haskell.org> Message-ID: <063.75e85fd2c2d48a3d638f0754c09cce51@haskell.org> #10806: Type error and type level (<=) together cause GHC to hang -------------------------------------+------------------------------------- Reporter: htebalaka | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by kanetw): Seems to work fine in GHC HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 8 07:18:31 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Sep 2015 07:18:31 -0000 Subject: [GHC] #10806: Type error and type level (<=) together cause GHC to hang In-Reply-To: <048.9b3d349db1bfdcff1a2e281d43595c9a@haskell.org> References: <048.9b3d349db1bfdcff1a2e281d43595c9a@haskell.org> Message-ID: <063.db9f2be5b3a3549edd20ebdc62704c5e@haskell.org> #10806: Type error and type level (<=) together cause GHC to hang -------------------------------------+------------------------------------- Reporter: htebalaka | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): htebalaka: your test case doesn't typecheck with ghc-7.10.2. Are you sure you were using 7.10.2? Can you please fix the description. Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 8 07:39:13 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Sep 2015 07:39:13 -0000 Subject: [GHC] #10788: performance regression involving minimum In-Reply-To: <047.bfa4fa3fe86eacf6fba28b5097b23381@haskell.org> References: <047.bfa4fa3fe86eacf6fba28b5097b23381@haskell.org> Message-ID: <062.7399106669e584441b424506f696bf1f@haskell.org> #10788: performance regression involving minimum -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: ekmett Type: bug | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): > That is, you are not seeking any change to GHC. Correct? Correct! I was a bit confused along the way, due to mis-reading the Core, but there is purely a library issue at hand. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 8 07:48:05 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Sep 2015 07:48:05 -0000 Subject: [GHC] #10831: DeriveFunctor not capable of deriving when wrapping Either In-Reply-To: <048.8298ed09a98386a50539acd12ba36fa5@haskell.org> References: <048.8298ed09a98386a50539acd12ba36fa5@haskell.org> Message-ID: <063.3f071a1f89e0c0399332a26ee59dbfc2@haskell.org> #10831: DeriveFunctor not capable of deriving when wrapping Either -------------------------------------+------------------------------------- Reporter: htebalaka | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * os: MacOS X => Unknown/Multiple * component: Compiler => Compiler (Type checker) Old description: > GHC can derive Functor for Okay, but rejects the equivalent Bad. > {{{#!hs > {-# LANGUAGE DeriveFunctor #-} > data Okay f g a b = Inl (f a b) | Inr (g a b) deriving (Functor) > newtype Bad f g a b = Bad (Either (f a b) (g a b)) deriving (Functor) > }}} New description: GHC can derive Functor for Okay, but rejects the equivalent Bad. {{{#!hs {-# LANGUAGE DeriveFunctor #-} data Okay f g a b = Inl (f a b) | Inr (g a b) deriving (Functor) newtype Bad f g a b = Bad (Either (f a b) (g a b)) deriving (Functor) }}} {{{ Can't make a derived instance of ?Functor (Bad f g a)?: Constructor ?Bad? must use the type variable only as the last argument of a data type In the data declaration for ?Bad? }}} -- Comment: This comment (option `c`) in `compiler/typecheck/TcDeriv.hs` says this is to be expected: {{{ cond_functorOK :: Bool -> Bool -> Condition -- OK for Functor/Foldable/Traversable class -- Currently: (a) at least one argument -- (b) don't use argument contravariantly -- (c) don't use argument in the wrong place, e.g. data T a = T (X a a) -- (d) optionally: don't use function types -- (e) no "stupid context" on data type }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 8 08:03:34 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Sep 2015 08:03:34 -0000 Subject: [GHC] #10476: Wrong ar during cross-compilation In-Reply-To: <046.928a748c0b21fd917210dee4be8c618c@haskell.org> References: <046.928a748c0b21fd917210dee4be8c618c@haskell.org> Message-ID: <061.67a55b8c7311da153d7b62a4f2a0b141@haskell.org> #10476: Wrong ar during cross-compilation -------------------------------------+------------------------------------- Reporter: jakzale | Owner: thomie Type: bug | Status: new Priority: low | Milestone: Component: Build System | Version: 7.11 Resolution: | Keywords: cross- | compiling Operating System: MacOS X | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: Phab:D1231 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"864a9c4f83156caacae5777b3ad6b93b4da9c242/ghc" 864a9c4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="864a9c4f83156caacae5777b3ad6b93b4da9c242" Build system: remove hack for Mac OSX in configure.ac (#10476) Cross-compilation on Mac OSX currently doesn't work. While building stage 1, the build system uses the `ar` for the target architecture instead of the `ar` for build/host architecture. The cause is a hack added in 24746fe78024a1edab843bc710c79c55998ab134 (2010), to supporting bootstrap compilers built with older versions of Xcode. Xcode 4.3 started installing command line tools in a different location. Assuming this all behind us now, and the paths didn't change again (you never now), we can delete the hack. Deleting the hack fixes the cross compilation issue. Tested by Trac user jakzale. Reviewed by: austin Differential Revision: https://phabricator.haskell.org/D1231 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 8 08:03:34 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Sep 2015 08:03:34 -0000 Subject: [GHC] #10223: Cleanup `mk/build.mk.sample` In-Reply-To: <045.7ed59dbe44609faf808ed2eef55dcc31@haskell.org> References: <045.7ed59dbe44609faf808ed2eef55dcc31@haskell.org> Message-ID: <060.b651a569cbef86e15018222942f492a9@haskell.org> #10223: Cleanup `mk/build.mk.sample` -------------------------------------+------------------------------------- Reporter: thomie | Owner: thomie Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"330fbbdacc71a7bb465195e24e268a947fe97412/ghc" 330fbbda/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="330fbbdacc71a7bb465195e24e268a947fe97412" Build system: make *-cross BuildFlavours consistent (#10223) This is a follow up to 841924c9587c10488a18e307b573720977bf4f13, where `-fllvm` was explicitly removed from GhcStage1HcOpts for perf-cross. After removing -fllvm from GhcStage1HcOpts, it should be removed from SRC_HC_OPTS as well, because SRC_HC_OPTS are added to every Haskell compilation. That's what this patch does. BuildFlavour bench-cross (added in ddf79ebf69fe4a6e69d69d451a6040a53b1ea12c), is probably never used. But for consistency, also use -fllvm here, for building stage2 and the libraries. Reviewed by: austin Differential Revision: https://phabricator.haskell.org/D1228 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 8 08:04:58 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Sep 2015 08:04:58 -0000 Subject: [GHC] #10476: Wrong ar during cross-compilation In-Reply-To: <046.928a748c0b21fd917210dee4be8c618c@haskell.org> References: <046.928a748c0b21fd917210dee4be8c618c@haskell.org> Message-ID: <061.ace5884732592575856e91aeb22e39e1@haskell.org> #10476: Wrong ar during cross-compilation -------------------------------------+------------------------------------- Reporter: jakzale | Owner: thomie Type: bug | Status: merge Priority: low | Milestone: 7.10.3 Component: Build System | Version: 7.11 Resolution: | Keywords: cross- | compiling Operating System: MacOS X | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: Phab:D1231 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => merge * milestone: => 7.10.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 8 08:12:27 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Sep 2015 08:12:27 -0000 Subject: [GHC] #10223: Cleanup `mk/build.mk.sample` In-Reply-To: <045.7ed59dbe44609faf808ed2eef55dcc31@haskell.org> References: <045.7ed59dbe44609faf808ed2eef55dcc31@haskell.org> Message-ID: <060.69648fd26d330c0cc2ebc23421b4a6a7@haskell.org> #10223: Cleanup `mk/build.mk.sample` -------------------------------------+------------------------------------- Reporter: thomie | Owner: thomie Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): Todo: * figure out the `-H64m` story. See https://mail.haskell.org/pipermail /glasgow-haskell-users/2015-May/025917.html. I found this bit of wisdom by Simon Marlow, https://mail.haskell.org/pipermail/ghc-devs/2014-March/004344.html: > > Just wondering: that '-H64m' is from some old times (pre 2007?). > > GHC seems to eat way more RAM nowadays. Is this bit relevant at all? > > It still speeds up compilation a bit, but a larger -H value might be more appropriate > for today's machines. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 8 08:32:52 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Sep 2015 08:32:52 -0000 Subject: [GHC] #10818: GHC 7.10.2 takes much longer to compile some packages In-Reply-To: <052.bbf8ed2f6a4e18f5bbbbe47aede56c86@haskell.org> References: <052.bbf8ed2f6a4e18f5bbbbe47aede56c86@haskell.org> Message-ID: <067.9a32b03ad95b957e930a65c624887e8a@haskell.org> #10818: GHC 7.10.2 takes much longer to compile some packages -------------------------------------+------------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by gidyn): I tried this with the haskell docker images for 7.10.2 and 7.8.4 and the build times are similar. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 8 11:33:40 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Sep 2015 11:33:40 -0000 Subject: [GHC] #3242: ghci: can't load .so/.DLL for: m (addDLL: could not load DLL) In-Reply-To: <045.426dc6319f98492c5b511466045bc0b5@haskell.org> References: <045.426dc6319f98492c5b511466045bc0b5@haskell.org> Message-ID: <060.0f5aa02c03678eb74e8a0d0697d89164@haskell.org> #3242: ghci: can't load .so/.DLL for: m (addDLL: could not load DLL) ---------------------------------+--------------------------------- Reporter: jeffz1 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: GHCi | Version: 7.4.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: 3658 | Blocking: Related Tickets: #7097 | Differential Revisions: ---------------------------------+--------------------------------- Changes (by vagarenko): * cc: vagarenko (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 8 12:23:39 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Sep 2015 12:23:39 -0000 Subject: [GHC] #10486: Allow addTopDecls to create annotations In-Reply-To: <045.12d45e4d0a4bb9ca79be29175909ed59@haskell.org> References: <045.12d45e4d0a4bb9ca79be29175909ed59@haskell.org> Message-ID: <060.cc72e22d85f7d2c2e9ff29708c5e01b1@haskell.org> #10486: Allow addTopDecls to create annotations -------------------------------------+------------------------------------- Reporter: spinda | Owner: spinda Type: feature request | Status: closed Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | testsuite/tests/annotations/should_compile/th/ Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1201 -------------------------------------+------------------------------------- Comment (by simonpj): Michael (@spinda), where in the user manual or TH library Haddock documentation is this change documented? Maybe the documentation of `addTopDecls` is lacking... if so, might you add some? Thanks! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 8 12:31:49 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Sep 2015 12:31:49 -0000 Subject: [GHC] #10829: Simplification in the RHS of rules In-Reply-To: <046.7ca7c028ab82ec2d7ad263cb88680067@haskell.org> References: <046.7ca7c028ab82ec2d7ad263cb88680067@haskell.org> Message-ID: <061.5be03476cb67eb007d577a1a6eba99d5@haskell.org> #10829: Simplification in the RHS of rules -------------------------------------+------------------------------------- Reporter: afarmer | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 10528 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): I think that Option 1 would be fine. Could someone try it? * In `Simplify.simplRule`, define `rhs_env = lhs_env`. * Probably rename `updModeForRuleLHS` to `updModeForRule` * Add a `Note` with `updModeForRule` to explain why we also do no inlining on rule RHSs, citing the ticket. * Check that there is no `nofib` impact. Andrew: maybe you can do this? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 8 12:35:22 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Sep 2015 12:35:22 -0000 Subject: [GHC] #10828: TH could do a better job of representing GADTs In-Reply-To: <045.8ead8c05c9800a5f7ba9e24f2356aece@haskell.org> References: <045.8ead8c05c9800a5f7ba9e24f2356aece@haskell.org> Message-ID: <060.03a734b8dbd05325d58f5cee6d0e9142@haskell.org> #10828: TH could do a better job of representing GADTs -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): > The one tiny caveat is the new feature for deriving Foldable for GADTs, which distinguishes among the two forms above. (I can't find a reference to this change. Can you? It was described at Haskell Implementors' Workshop a few days ago. You, the reader, if you know the reference, please add it!) See [wiki:Commentary/Compiler/DeriveFunctor] and #10447. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 8 12:53:59 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Sep 2015 12:53:59 -0000 Subject: [GHC] #10841: Run handler on STM retry In-Reply-To: <045.10ea2aa941550aac6248eb677ce6a5a6@haskell.org> References: <045.10ea2aa941550aac6248eb677ce6a5a6@haskell.org> Message-ID: <060.6d9f0d3ba5b630543525d91e186b709e@haskell.org> #10841: Run handler on STM retry -------------------------------------+------------------------------------- Reporter: shlevy | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries | Version: 7.10.2 (other) | Resolution: | Keywords: stm Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * cc: ryates@? (added) Comment: I agree; something like this is sorely needed, so that users can take control of what to do if the transaction starves. Curiously I was talking to [http://www.cs.rochester.edu/u/ryates/ Ryan Yates] about this very thing at ICFP last week. He's been doing work on GHC's STM implementation, and perhaps this retry-handler thing could form part of it? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 8 12:58:55 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Sep 2015 12:58:55 -0000 Subject: [GHC] #10841: Run handler on STM retry In-Reply-To: <045.10ea2aa941550aac6248eb677ce6a5a6@haskell.org> References: <045.10ea2aa941550aac6248eb677ce6a5a6@haskell.org> Message-ID: <060.4b71419f4df6c465f3442384119c6b4d@haskell.org> #10841: Run handler on STM retry -------------------------------------+------------------------------------- Reporter: shlevy | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries | Version: 7.10.2 (other) | Resolution: | Keywords: stm Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by shlevy): A few more thoughts looking back on this a few days later: a) It might be nice to have some structured information from the runtime explaining why a transaction needed to retry, and b) perhaps the only primitive needed is just a "try once" that can be looped as-desired by the user. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 8 13:26:38 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Sep 2015 13:26:38 -0000 Subject: [GHC] #10803: New SignatureSections extension (was: New TypeSignatureSections extension) In-Reply-To: <042.499b2af8de1376e7739ef3516bd5a45e@haskell.org> References: <042.499b2af8de1376e7739ef3516bd5a45e@haskell.org> Message-ID: <057.a0839b7e1299d859578ec9a78e1f8d39@haskell.org> #10803: New SignatureSections extension -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: feature request | Status: patch Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1185 -------------------------------------+------------------------------------- Description changed by hvr: Old description: > Originally [http://augustss.blogspot.co.at/2014/04/a-small-haskell- > extension.html proposed by Lennart Augustsson] > > Incomplete work-in-progress can be found in > [https://git.haskell.org/ghc.git/log/refs/heads/wip/T10803 wip/T10803] > branch > > = Preliminary specification > > Have > > - `(::` ''type'' `)` > > be syntax sugar for > > - `(\x -> x ::` ''type'' `)` > > This new syntax extension is enabled via a new `SignatureSections` or > maybe `TypeSignatureSections` language pragma, e.g. > > {{{#!hs > {-# LANGUAGE TypeSignatureSections #-} > }}} > > Typing judgement: > > {{{ > _________________________ > G ? (:: ty) :: ty -> ty > }}} > > TODO: formalise this a bit more New description: Originally [http://augustss.blogspot.co.at/2014/04/a-small-haskell- extension.html proposed by Lennart Augustsson] See also SignatureSections = Preliminary specification Have - `(::` ''type'' `)` be syntax sugar for - `(\x -> x ::` ''type'' `)` This new syntax extension is enabled via a new `SignatureSections` (or maybe `TypeSignatureSections`) language pragma, e.g. {{{#!hs {-# LANGUAGE SignatureSections #-} }}} Typing judgement: {{{ _________________________ G ? (:: ty) :: ty -> ty }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 8 13:31:33 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Sep 2015 13:31:33 -0000 Subject: [GHC] #10361: DeriveAnyClass does not fill in associated type defaults In-Reply-To: <047.18f32bb2aaf0fd43551e26193c9cadf9@haskell.org> References: <047.18f32bb2aaf0fd43551e26193c9cadf9@haskell.org> Message-ID: <062.54000c3f7dccdd67d3d5347793fc1d34@haskell.org> #10361: DeriveAnyClass does not fill in associated type defaults -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: dreixel Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by vagarenko): My case of this bug: {{{ {-# LANGUAGE DefaultSignatures, TypeFamilies, TypeOperators, FlexibleContexts, DeriveGeneric, DeriveAnyClass #-} module Bug where import GHC.Generics --------------------------------------------------------------------- class Convert a where type Result a type instance Result a = GResult (Rep a) convert :: a -> Result a default convert :: (Generic a, GConvert (Rep a)) => a -> GResult (Rep a) convert x = gconvert (from x) instance Convert Float where type Result Float = Float convert = id instance Convert Int where type Result Int = Int convert = id --------------------------------------------------------------------- class GConvert f where type GResult f gconvert :: f p -> GResult f instance (Convert c) => GConvert (K1 i c) where type GResult (K1 i c) = Result c gconvert (K1 x) = convert x instance (GConvert f) => GConvert (M1 i t f) where type GResult (M1 i t f) = GResult f gconvert (M1 x) = gconvert x instance (GConvert f, GConvert g) => GConvert (f :*: g) where type GResult (f :*: g) = (GResult f, GResult g) gconvert (x :*: y) = (gconvert x, gconvert y) --------------------------------------------------------------------- -- This works: data Data1 = Data1 Int Float deriving (Generic) instance Convert Data1 val :: (Int, Float) val = convert $ Data1 0 0.0 -- This doesn't: data Data2 = Data2 Int Float deriving (Generic, Convert) -- Couldn't match type `Result Data' with `(Int, Float)' -- Expected type: Data -> Result Data -- Actual type: Data -> GResult (Rep Data) -- In the expression: Bug.$gdmconvert -- In an equation for `convert': convert = Bug.$gdmconvert -- When typechecking the code for `convert' -- in a derived instance for `Convert Data': -- To see the code I am typechecking, use -ddump-deriv }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 8 13:35:08 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Sep 2015 13:35:08 -0000 Subject: [GHC] #10361: DeriveAnyClass does not fill in associated type defaults In-Reply-To: <047.18f32bb2aaf0fd43551e26193c9cadf9@haskell.org> References: <047.18f32bb2aaf0fd43551e26193c9cadf9@haskell.org> Message-ID: <062.ba18455a37ad8876a74abeecef0668e1@haskell.org> #10361: DeriveAnyClass does not fill in associated type defaults -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: dreixel Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by vagarenko): * cc: vagarenko (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 8 13:42:43 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Sep 2015 13:42:43 -0000 Subject: [GHC] #10444: Text.Read.Lex.lex broken In-Reply-To: <048.7d303af6bd6af366785c1d3e315fce90@haskell.org> References: <048.7d303af6bd6af366785c1d3e315fce90@haskell.org> Message-ID: <063.ae60931559b017e9b34615000cbf8339@haskell.org> #10444: Text.Read.Lex.lex broken -------------------------------------+------------------------------------- Reporter: strake888 | Owner: ekmett Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: | Phab:D1122. -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"e4a73f4fa1cc9681aee3ce13ee15073deed54635/ghc" e4a73f4f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e4a73f4fa1cc9681aee3ce13ee15073deed54635" Move GeneralCategory et al to GHC.Unicode This allows these to be used from Text.Read.Lex import cycles. Reviewed By: thomie, austin Differential Revision: https://phabricator.haskell.org/D1121 GHC Trac Issues: #10444 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 8 14:10:57 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Sep 2015 14:10:57 -0000 Subject: [GHC] #10413: Incorrect offsets for array size indexing In-Reply-To: <048.fb282c815f959019fb8541a09f28e9ea@haskell.org> References: <048.fb282c815f959019fb8541a09f28e9ea@haskell.org> Message-ID: <063.a09e910c39a8ec0488df740f11106b13@haskell.org> #10413: Incorrect offsets for array size indexing -------------------------------------+------------------------------------- Reporter: fryguybob | Owner: fryguybob Type: task | Status: merge Priority: low | Milestone: 7.10.3 Component: Compiler | Version: 7.10.1 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1194 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: => 7.10.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 8 14:12:04 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Sep 2015 14:12:04 -0000 Subject: [GHC] #10853: Refine addTopDecls Message-ID: <047.c86dd8a253022fe77935e07f26b94dc1@haskell.org> #10853: Refine addTopDecls -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Template | Version: 7.10.2 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- This suggested refactoring/documentation task is spurred on by #10486. Readers do not have to read that ticket to understand this task. Currently, `addTopDecls` is restricted in what it can add. In an email exchange with Geoff Mainland (the original implementor of `addTopDecls`), it was unclear exactly why this restriction is in place. So, I propose lifting the restriction. We do have to be careful about ordering. As it is currently implemented, here is what happens: {{{ -- region A, including everything up to but not including a top-level splice $( {- region B, the contents of a top-level splice -} ) -- region C, everything after the splice }}} In addition to those regions, we also have {{{ -- region D, consisting of all declarations added with `addTopDecls`. }}} By reading the code (`TcRnDriver.tc_rn_src_decls`), it seems that the expected behavior should be this: 1. Rename region A. Anything defined in other regions is not in scope. 2. Rename region D, with declarations from region A in scope. 3. Type-check regions A and D together. 4. When running TH code in region B, all declarations from A and D are in scope and can be accessed via `reify` and friends. 5. Combine regions B and C together, and recur to step 1 (where the combined B and C is now a new region A). This all means that A and D are mutually recursive w.r.t. the type-checker but not the renamer. This is a bit peculiar, but not terrible. For example, this means that there could be a function whose definition is in A and type signature in D. Proper mutual recursion would be hard (impossible?) without better renaming support. In any case, I don't see a reason to restrict what's allowed in `addTopDecls`. So, at a minimum, I propose: * Remove restrictions in `addTopDecls` * Document `addTopDecls` generally * Document the above behavior, detailing the interaction between these regions Perhaps better, we could do: * Remove restrictions in `addTopDecls` * Rejigger the implementation of `addTopDecls` to lump region D in with B and C. This looks quite straightforward, and it makes for a simpler story about mutual recursion. This is a potentially-breaking change, if existing code has, say, a function defined in A with its type signature in D. * Document the new, simpler behavior Regardless of which proposal we go with, some testing is in order, to make sure that this is all correct. I've done no testing in formulating this ticket, just reading code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 8 14:12:46 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Sep 2015 14:12:46 -0000 Subject: [GHC] #10486: Allow addTopDecls to create annotations In-Reply-To: <045.12d45e4d0a4bb9ca79be29175909ed59@haskell.org> References: <045.12d45e4d0a4bb9ca79be29175909ed59@haskell.org> Message-ID: <060.670f7f16b8236d80a18dbf55b4e626ed@haskell.org> #10486: Allow addTopDecls to create annotations -------------------------------------+------------------------------------- Reporter: spinda | Owner: spinda Type: feature request | Status: closed Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | testsuite/tests/annotations/should_compile/th/ Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1201 -------------------------------------+------------------------------------- Comment (by goldfire): See #10853, a new ticket meant to track general improvements to `addTopDecls`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 8 14:39:53 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Sep 2015 14:39:53 -0000 Subject: [GHC] #10803: New SignatureSections extension In-Reply-To: <042.499b2af8de1376e7739ef3516bd5a45e@haskell.org> References: <042.499b2af8de1376e7739ef3516bd5a45e@haskell.org> Message-ID: <057.fccedd97bdcd9f0106e560662c2453ea@haskell.org> #10803: New SignatureSections extension -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: feature request | Status: patch Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1185 -------------------------------------+------------------------------------- Comment (by goldfire): Adding a portion of a comment from Phab:D1185, as Trac is better for design discussions: Once we have the visible type application feature (#5296), is this one needed any more? Do we have real-ish examples of when we want signature sections? The examples for http://augustss.blogspot.co.at/2014/04/a-small- haskell-extension.html are all quite easy to write with visible type application. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 8 15:17:03 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Sep 2015 15:17:03 -0000 Subject: [GHC] #10803: New SignatureSections extension In-Reply-To: <042.499b2af8de1376e7739ef3516bd5a45e@haskell.org> References: <042.499b2af8de1376e7739ef3516bd5a45e@haskell.org> Message-ID: <057.1e098d975134f068e24b90d4eed87429@haskell.org> #10803: New SignatureSections extension -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: feature request | Status: patch Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1185 -------------------------------------+------------------------------------- Comment (by simonpj): Well, a type signature is a lot simpler to most people than figuring out the right type argument. It means there is more than one way to do something, but Haskell has a lot of those! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 8 15:26:26 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Sep 2015 15:26:26 -0000 Subject: [GHC] #10803: New SignatureSections extension In-Reply-To: <042.499b2af8de1376e7739ef3516bd5a45e@haskell.org> References: <042.499b2af8de1376e7739ef3516bd5a45e@haskell.org> Message-ID: <057.2582c1d62b9e8dcfd4347263f23c5028@haskell.org> #10803: New SignatureSections extension -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: feature request | Status: patch Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1185 -------------------------------------+------------------------------------- Comment (by goldfire): Fair enough. But I'm still worried about runtime implications of signature sections, as described in the Phab:D1185 comments. Visible type application doesn't have that problem. If I'm right in supposing that signature sections potentially have runtime implications, I personally would never use/recommend the feature. Agreed that sometimes a signature section is more convenient for the programmer than figuring out the right visible type application. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 8 15:43:57 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Sep 2015 15:43:57 -0000 Subject: [GHC] #10854: Remove recursive uses of `pprParendHsExpr` from `HsExpr.ppr_expr` Message-ID: <047.e2e165b0a37a7097edcf4a218b419974@haskell.org> #10854: Remove recursive uses of `pprParendHsExpr` from `HsExpr.ppr_expr` -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- An `HsExpr` should look exactly as a user wrote some Haskell code. Its pretty printer should therefore be quite dumb. Just print out the code! But a few places in GHC create `HsExpr`s and aren't scrupulous with regard to adding `HsPar` nodes where source syntax would need them. Thus, well- meaning souls have added `pprParendExpr` calls to the `HsExpr` pretty- printer to try to cover these cases. Simon and I [https://phabricator.haskell.org/D1219#34199 think] that we should remove all recursive uses of `pprParendExpr` from the `HsExpr` pretty-printer and instead add the `HsPar`s where necessary. It was recently reported that the following test cases break when simply removing `pprParendExpr`: {{{ Unexpected failures: deriving/should_fail T4846 [stderr mismatch] (normal) generics GenDerivOutput [stderr mismatch] (normal) generics GenDerivOutput1_0 [stderr mismatch] (normal) generics GenDerivOutput1_1 [stderr mismatch] (normal) ghci/scripts T10248 [bad stderr] (ghci) indexed-types/should_compile PushedInAsGivens [stderr mismatch] (normal) safeHaskell/safeLanguage SafeLang10 [stderr mismatch] (normal) safeHaskell/safeLanguage SafeLang17 [stderr mismatch] (normal) typecheck/should_fail T8603 [stderr mismatch] (normal) typecheck/should_fail tcfail177 [stderr mismatch] (normal) }}} See also considerable commentary on Phab:D1114. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 8 15:44:15 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Sep 2015 15:44:15 -0000 Subject: [GHC] #10157: HSCOLOUR_SRCS=YES fails mysteriously when no HsColour executable available In-Reply-To: <045.a880c5ea8f0c0cc37611c17ef6bd7339@haskell.org> References: <045.a880c5ea8f0c0cc37611c17ef6bd7339@haskell.org> Message-ID: <060.dc1497829da54e0538dc47c37db4d885@haskell.org> #10157: HSCOLOUR_SRCS=YES fails mysteriously when no HsColour executable available -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: patch Priority: low | Milestone: 7.12.1 Component: Build System | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1232 -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch * differential: => Phab:D1232 * milestone: => 7.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 8 16:10:13 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Sep 2015 16:10:13 -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.cd04070c61de735016108fafc2177d03@haskell.org> #9832: Get rid of PERL dependency of `ghc-split` -------------------------------------+------------------------------------- Reporter: hvr | Owner: Phyx- 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: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8405 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * related: => #8405 Comment: See also #8405, where @olsner is trying to get rid of the splitter altogether. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 8 16:13:51 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Sep 2015 16:13:51 -0000 Subject: [GHC] #10842: "Reactive" Template Haskell In-Reply-To: <050.6f7bb562017372f9e5bba0241a40c1a7@haskell.org> References: <050.6f7bb562017372f9e5bba0241a40c1a7@haskell.org> Message-ID: <065.c185357b2346aed292941ee6cb9c2094@haskell.org> #10842: "Reactive" Template Haskell -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 9699 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Interesting. I am worried about "spooky action at a distance" here, but perhaps this would be useful. To get more traction on this proposal, might you advertise it and see what response you get? It would be more compelling if there will be more than 1 user! Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 8 16:14:01 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Sep 2015 16:14:01 -0000 Subject: [GHC] #10842: "Reactive" Template Haskell In-Reply-To: <050.6f7bb562017372f9e5bba0241a40c1a7@haskell.org> References: <050.6f7bb562017372f9e5bba0241a40c1a7@haskell.org> Message-ID: <065.bfda3d939de2741ba71257e2946cae5f@haskell.org> #10842: "Reactive" Template Haskell -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 9699 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * component: Compiler => Template Haskell -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 8 16:18:03 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Sep 2015 16:18:03 -0000 Subject: [GHC] #8405: experiment with using function-sections for linking (for smaller libs and executables) In-Reply-To: <045.ff128453c9ddce6d07b91486f573635a@haskell.org> References: <045.ff128453c9ddce6d07b91486f573635a@haskell.org> Message-ID: <060.f53ffc16d9cf534c8a8b6c786653d8e5@haskell.org> #8405: experiment with using function-sections for linking (for smaller libs and executables) -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): Awesome. How about the size of the .a files? With `-split-objs`, `.a` files tend to get a factor of 2 to 2.5x larger. This is one of the reasons why a ghc installation is as large as it is (~900Mb for me). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 8 16:23:15 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Sep 2015 16:23:15 -0000 Subject: [GHC] #10157: HSCOLOUR_SRCS=YES fails mysteriously when no HsColour executable available In-Reply-To: <045.a880c5ea8f0c0cc37611c17ef6bd7339@haskell.org> References: <045.a880c5ea8f0c0cc37611c17ef6bd7339@haskell.org> Message-ID: <060.5812d734b5293450a2ce9c22548a6233@haskell.org> #10157: HSCOLOUR_SRCS=YES fails mysteriously when no HsColour executable available -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: patch Priority: low | Milestone: 7.12.1 Component: Build System | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1232 -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"1b8eca18fc2bb9ccb4fd3246ac48318975574722/ghc" 1b8eca18/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1b8eca18fc2bb9ccb4fd3246ac48318975574722" Build system: check for inconsistent settings (#10157) `configure` currently detects when the docbook and hscolour tools aren't available, and instead of failing outright (as it does for missing alex and happy), sets some variables in mk/config.mk to tell `make` not to build the documentation. Sometimes, however, you want to really make sure all documentation gets built, fully colourized. For example when making a release. To do so, you can override the mentioned variables from mk/config.mk in mk/build.mk (e.g. set HSCOLOUR_SRCS=YES). This patch adds some error checking to make sure that doing so will not result in weird build failures when those tools are still missing. Test Plan: ran `make` a couple of times, with different mk/config.mk settings. Reviewed by: austin Differential Revision: https://phabricator.haskell.org/D1232 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 8 16:23:51 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Sep 2015 16:23:51 -0000 Subject: [GHC] #10157: HSCOLOUR_SRCS=YES fails mysteriously when no HsColour executable available In-Reply-To: <045.a880c5ea8f0c0cc37611c17ef6bd7339@haskell.org> References: <045.a880c5ea8f0c0cc37611c17ef6bd7339@haskell.org> Message-ID: <060.c34cf599b0a71026e161030a737f0dc7@haskell.org> #10157: HSCOLOUR_SRCS=YES fails mysteriously when no HsColour executable available -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: closed Priority: low | Milestone: 7.12.1 Component: Build System | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1232 -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 8 16:30:02 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Sep 2015 16:30:02 -0000 Subject: [GHC] #10855: GHC rejects code that Haskell 2010 report accepts Message-ID: <047.18e6e77fdcbdaa2d5abe96a152166a71@haskell.org> #10855: GHC rejects code that Haskell 2010 report accepts -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- According to [https://www.haskell.org/onlinereport/haskell2010/haskellch3.html#x8-220003 The Haskell 2010 Report], the following two modules should compile. But they don't, failing with parse errors: {{{ {-# LANGUAGE Haskell2010 #-} module Bug where bool = - case b of False -> 0; True -> (-1) }}} {{{ {-# LANGUAGE Haskell2010 #-} instance Num (IO a) where negate = id main = - do putStrLn "hi!" }}} Note the unary `-` signs. I'm not sure whether we should complicate the parser to fix these, but we should document the compliance-failure in the manual. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 8 16:34:28 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Sep 2015 16:34:28 -0000 Subject: [GHC] #10826: [Security] Safe Haskell can be bypassed via annotations In-Reply-To: <045.6042fe6f9f535df81b6d3e710bdd3ea9@haskell.org> References: <045.6042fe6f9f535df81b6d3e710bdd3ea9@haskell.org> Message-ID: <060.9c230b7084673f11e43be47b5c25d981@haskell.org> #10826: [Security] Safe Haskell can be bypassed via annotations -------------------------------------+------------------------------------- Reporter: spinda | Owner: kanetw Type: bug | Status: patch Priority: highest | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: phab:D1226 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"4356dacb4a2ae29dfbd7126b25b72d89bb9db1b0/ghc" 4356dac/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4356dacb4a2ae29dfbd7126b25b72d89bb9db1b0" Forbid annotations when Safe Haskell safe mode is enabled. For now, this fails compliation immediately with an error. If desired, this can be a warning that annotations in Safe Haskell are ignored. Signed-off-by: David Kraeutmann Reviewed By: goldfire, austin Differential Revision: https://phabricator.haskell.org/D1226 GHC Trac Issues: #10826 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 8 16:38:33 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Sep 2015 16:38:33 -0000 Subject: [GHC] #10855: GHC rejects code that Haskell 2010 report accepts In-Reply-To: <047.18e6e77fdcbdaa2d5abe96a152166a71@haskell.org> References: <047.18e6e77fdcbdaa2d5abe96a152166a71@haskell.org> Message-ID: <062.4662d0de59dead9cdb5b1f17a6724152@haskell.org> #10855: GHC rejects code that Haskell 2010 report accepts -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | 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 thomie): * failure: None/Unknown => Documentation bug * component: Compiler => Compiler (Parser) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 8 16:56:05 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Sep 2015 16:56:05 -0000 Subject: [GHC] #10829: Simplification in the RHS of rules In-Reply-To: <046.7ca7c028ab82ec2d7ad263cb88680067@haskell.org> References: <046.7ca7c028ab82ec2d7ad263cb88680067@haskell.org> Message-ID: <061.0977066e97b658d6b1e4ffad476da9ff@haskell.org> #10829: Simplification in the RHS of rules -------------------------------------+------------------------------------- Reporter: afarmer | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 10528 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by afarmer): Yes I have a patch at home that does this. I'll nofib bench it tonight and report back, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 8 17:01:48 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Sep 2015 17:01:48 -0000 Subject: [GHC] #10856: Record update doesn't emit new constraints Message-ID: <047.de834d55250d835a617b774942ee7049@haskell.org> #10856: Record update doesn't emit new constraints -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- I believe this should compile: {{{ {-# LANGUAGE ExistentialQuantification #-} data Rec a b = Show a => Mk { a :: a, b :: b } update :: Show c => c -> Rec a b -> Rec c b update c r = r { a = c } }}} But it fails with {{{ /Users/rae/temp/Bug.hs:6:14: Couldn't match type ?a? with ?c? ?a? is a rigid type variable bound by the type signature for update :: Show c => c -> Rec a b -> Rec c b at /Users/rae/temp/Bug.hs:5:11 ?c? is a rigid type variable bound by the type signature for update :: Show c => c -> Rec a b -> Rec c b at /Users/rae/temp/Bug.hs:5:11 Expected type: Rec c b Actual type: Rec a b Relevant bindings include r :: Rec a b (bound at /Users/rae/temp/Bug.hs:6:10) c :: c (bound at /Users/rae/temp/Bug.hs:6:8) update :: c -> Rec a b -> Rec c b (bound at /Users/rae/temp/Bug.hs:6:1) In the expression: r In the expression: r {a = c} }}} I believe the problem has to do with the `fixed_tvs`, the tyvars that are most certainly shared between the initial and result types. The `getFixedTyVars` function always includes tyvars mentioned in constraints. But this is unnecessary. Once the `fixed_tvs` are cleaned up, then we'll also have to make sure to instantiate the constraints necessary to prove that the new constraints are satisfied. We should be careful '''not''' to emit any unchanged constraints, because these are provided by the GADT pattern-match that the desugarer produces. There will probably have to be an update to the `RecordUpd` constructor of `HsExpr` to have a place to put the new dictionaries. NB: This is very related to implementation trouble in Phab:D1152, and I imagine that patch will evolve to fix this infelicity. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 8 17:23:13 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Sep 2015 17:23:13 -0000 Subject: [GHC] #10856: Record update doesn't emit new constraints In-Reply-To: <047.de834d55250d835a617b774942ee7049@haskell.org> References: <047.de834d55250d835a617b774942ee7049@haskell.org> Message-ID: <062.7e0affd447d08c98da3479223477f63a@haskell.org> #10856: Record update doesn't emit new constraints -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by mpickering): * cc: mpickering (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 8 17:42:06 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Sep 2015 17:42:06 -0000 Subject: [GHC] #10856: Record update doesn't emit new constraints In-Reply-To: <047.de834d55250d835a617b774942ee7049@haskell.org> References: <047.de834d55250d835a617b774942ee7049@haskell.org> Message-ID: <062.acffe72f567b2c25bf75d6cc7cbda9ce@haskell.org> #10856: Record update doesn't emit new constraints -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): There was a related StackOverflow question about this just yesterday (http://stackoverflow.com/questions/32439605/using-record-update-syntax- with-constrained-gadt-records), coincidence? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 8 17:47:06 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Sep 2015 17:47:06 -0000 Subject: [GHC] #10831: Document conditions on deriving Functor (was: DeriveFunctor not capable of deriving when wrapping Either) In-Reply-To: <048.8298ed09a98386a50539acd12ba36fa5@haskell.org> References: <048.8298ed09a98386a50539acd12ba36fa5@haskell.org> Message-ID: <063.2b7697b879338b034130d9f1401c3caf@haskell.org> #10831: Document conditions on deriving Functor -------------------------------------+------------------------------------- Reporter: htebalaka | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | 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 rwbarton): * failure: GHC rejects valid program => Documentation bug Comment: Right, this is expected behavior. The compiler doesn't "look inside" the definitions of other data types when deriving Functor, it relies on Functor instances for those types. But that is not enough to handle the occurrence of `b` inside the first argument to `Either`. One would need another class {{{ class Functor1 f where fmap1 :: (a -> b) -> f a x -> f b x instance Functor1 Either }}} I note that there is no documentation in the User's Guide about when deriving Functor will succeed. That at least should be fixed, so I'm repurposing this ticket. Feel free to also submit a feature request if you like. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 8 17:59:06 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Sep 2015 17:59:06 -0000 Subject: [GHC] #10857: "ghci -XMonomorphismRestriction" doesn't turn on the monomorphism restriction Message-ID: <047.0bca38b39289a4db2d373be62522bc3d@haskell.org> #10857: "ghci -XMonomorphismRestriction" doesn't turn on the monomorphism restriction -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Compare {{{ rwbarton at morphism:/tmp$ ghci-7.10.1 -XMonomorphismRestriction GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help Prelude> let a = (+) Prelude> :t a a :: Num a => a -> a -> a }}} with {{{ rwbarton at morphism:/tmp$ ghci-7.10.1 GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help Prelude> :set -XMonomorphismRestriction Prelude> let a = (+) Prelude> :t a a :: Integer -> Integer -> Integer }}} Confusing! This also occurred in 7.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 8 18:32:30 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Sep 2015 18:32:30 -0000 Subject: [GHC] #2595: Implement record update for existential and GADT data types In-Reply-To: <046.4aca36ddfd3abd8f80e6714ed9319183@haskell.org> References: <046.4aca36ddfd3abd8f80e6714ed9319183@haskell.org> Message-ID: <061.37d2a876e053943bae7dc72bb211f3be@haskell.org> #2595: Implement record update for existential and GADT data types -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: tc244 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): See also #10856, which may be the last missing piece of the puzzle. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 8 18:33:46 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Sep 2015 18:33:46 -0000 Subject: [GHC] #10856: Record update doesn't emit new constraints In-Reply-To: <047.de834d55250d835a617b774942ee7049@haskell.org> References: <047.de834d55250d835a617b774942ee7049@haskell.org> Message-ID: <062.e9e13287adfc7c4d527c0e6a6d337fa3@haskell.org> #10856: Record update doesn't emit new constraints -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * cc: mpickering (removed) Comment: Is this a more specific description than what's left of #2595? If you (whoever reads this next) agree, then one ticket should be closed as a dup of the other. I'll let you decide which is the dup, because I'm ambivalent. :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 8 19:45:42 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Sep 2015 19:45:42 -0000 Subject: [GHC] #10858: Smaller generated instances Message-ID: <046.699ef2ff00fb815c84fa41ceb8d156c0@haskell.org> #10858: Smaller generated instances -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- With very large modules with lots of deriving code, GHC spends quite some time compiling. I believe that we can improve things by reducing the size of the generated code. (More in the comments) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 8 19:52:36 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Sep 2015 19:52:36 -0000 Subject: [GHC] #10858: Smaller generated instances In-Reply-To: <046.699ef2ff00fb815c84fa41ceb8d156c0@haskell.org> References: <046.699ef2ff00fb815c84fa41ceb8d156c0@haskell.org> Message-ID: <061.351f038402da187cc657c0b89b8b4e6b@haskell.org> #10858: Smaller generated instances -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by nomeata): * keywords: => newcomer Comment: Consider this code generated for `Ord` for a product type: {{{ instance Ord l_acv3 => Ord (ImportDecl l_acv3) where compare a_acXz b_acXA = case a_acXz of { ImportDecl a1_acXB a2_acXC a3_acXD a4_acXE a5_acXF a6_acXG a7_acXH a8_acXI -> case b_acXA of { ImportDecl b1_acXJ b2_acXK b3_acXL b4_acXM b5_acXN b6_acXO b7_acXP b8_acXQ -> case (compare a1_acXB b1_acXJ) of { LT -> LT EQ -> case (compare a2_acXC b2_acXK) of { LT -> LT EQ -> case (compare a3_acXD b3_acXL) of { LT -> LT EQ -> case (compare a4_acXE b4_acXM) of { LT -> LT EQ -> case (compare a5_acXF b5_acXN) of { LT -> LT EQ -> case (compare a6_acXG b6_acXO) of { LT -> LT EQ -> case (compare a7_acXH b7_acXP) of { LT -> LT EQ -> (a8_acXI `compare` b8_acXQ) GT -> GT } GT -> GT } GT -> GT } GT -> GT } GT -> GT } GT -> GT } GT -> GT } } } (<) a_acXR b_acXS = case a_acXR of { ImportDecl a1_acXT a2_acXU a3_acXV a4_acXW a5_acXX a6_acXY a7_acXZ a8_acY0 -> case b_acXS of { ImportDecl b1_acY1 b2_acY2 b3_acY3 b4_acY4 b5_acY5 b6_acY6 b7_acY7 b8_acY8 -> case (compare a1_acXT b1_acY1) of { LT -> True EQ -> case (compare a2_acXU b2_acY2) of { LT -> True EQ -> case (compare a3_acXV b3_acY3) of { LT -> True EQ -> case (compare a4_acXW b4_acY4) of { LT -> True EQ -> case (compare a5_acXX b5_acY5) of { LT -> True EQ -> case (compare a6_acXY b6_acY6) of { LT -> True EQ -> case (compare a7_acXZ b7_acY7) of { LT -> True EQ -> (a8_acY0 < b8_acY8) GT -> False } GT -> False } GT -> False } GT -> False } GT -> False } GT -> False } GT -> False } } } (<=) a_acY9 b_acYa = case a_acY9 of { ImportDecl a1_acYb a2_acYc a3_acYd a4_acYe a5_acYf a6_acYg a7_acYh a8_acYi -> case b_acYa of { ImportDecl b1_acYj b2_acYk b3_acYl b4_acYm b5_acYn b6_acYo b7_acYp b8_acYq -> case (compare a1_acYb b1_acYj) of { LT -> True EQ -> case (compare a2_acYc b2_acYk) of { LT -> True EQ -> case (compare a3_acYd b3_acYl) of { LT -> True EQ -> case (compare a4_acYe b4_acYm) of { LT -> True EQ -> case (compare a5_acYf b5_acYn) of { LT -> True EQ -> case (compare a6_acYg b6_acYo) of { LT -> True EQ -> case (compare a7_acYh b7_acYp) of { LT -> True EQ -> (a8_acYi <= b8_acYq) GT -> False } GT -> False } GT -> False } GT -> False } GT -> False } GT -> False } GT -> False } } } (>=) a_acYr b_acYs = case a_acYr of { ImportDecl a1_acYt a2_acYu a3_acYv a4_acYw a5_acYx a6_acYy a7_acYz a8_acYA -> case b_acYs of { ImportDecl b1_acYB b2_acYC b3_acYD b4_acYE b5_acYF b6_acYG b7_acYH b8_acYI -> case (compare a1_acYt b1_acYB) of { LT -> False EQ -> case (compare a2_acYu b2_acYC) of { LT -> False EQ -> case (compare a3_acYv b3_acYD) of { LT -> False EQ -> case (compare a4_acYw b4_acYE) of { LT -> False EQ -> case (compare a5_acYx b5_acYF) of { LT -> False EQ -> case (compare a6_acYy b6_acYG) of { LT -> False EQ -> case (compare a7_acYz b7_acYH) of { LT -> False EQ -> (a8_acYA >= b8_acYI) GT -> True } GT -> True } GT -> True } GT -> True } GT -> True } GT -> True } GT -> True } } } (>) a_acYJ b_acYK = case a_acYJ of { ImportDecl a1_acYL a2_acYM a3_acYN a4_acYO a5_acYP a6_acYQ a7_acYR a8_acYS -> case b_acYK of { ImportDecl b1_acYT b2_acYU b3_acYV b4_acYW b5_acYX b6_acYY b7_acYZ b8_acZ0 -> case (compare a1_acYL b1_acYT) of { LT -> False EQ -> case (compare a2_acYM b2_acYU) of { LT -> False EQ -> case (compare a3_acYN b3_acYV) of { LT -> False EQ -> case (compare a4_acYO b4_acYW) of { LT -> False EQ -> case (compare a5_acYP b5_acYX) of { LT -> False EQ -> case (compare a6_acYQ b6_acYY) of { LT -> False EQ -> case (compare a7_acYR b7_acYZ) of { LT -> False EQ -> (a8_acYS > b8_acZ0) GT -> True } GT -> True } GT -> True } GT -> True } GT -> True } GT -> True } GT -> True } } } }}} This is huge! And so redundant. If the implementation of the operators `>` etc. build on the individual `compare` functions anyways, then it would surely be worth it to use the `compare` chain that was generated for the `compare` function ? i.e. simply use the default instance. Also, for the compare function, maybe we should add a function {{{ thenCmp :: Ordering -> Ordering -> Ordering thenCmp EQ o2 = o2 thenCmp o1 _ = o1 }}} to `Data.Ord` and use that to simply this to {{{ instance Ord l_acv3 => Ord (ImportDecl l_acv3) where compare a_acXz b_acXA = case a_acXz of { ImportDecl a1_acXB a2_acXC a3_acXD a4_acXE a5_acXF a6_acXG a7_acXH a8_acXI -> case b_acXA of { ImportDecl b1_acXJ b2_acXK b3_acXL b4_acXM b5_acXN b6_acXO b7_acXP b8_acXQ -> compare a1_acXB b1_acXJ `thenComp` compare a2_acXC b2_acXK `thenComp` compare a3_acXD b3_acXL `thenComp` compare a4_acXE b4_acXM `thenComp` compare a5_acXF b5_acXN `thenComp` compare a6_acXG b6_acXO `thenComp` compare a7_acXH b7_acXP `thenComp` compare a8_acXI b8_acXQ }}} Maybe this is a nice newcomer ticket: Relatively local, rewarding, and easy to get right. This is `mkCompareFields` in `TcGenDeriv` Also look at the other deriving instances for refactoring possibilities! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 8 19:56:13 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Sep 2015 19:56:13 -0000 Subject: [GHC] #10858: Smaller generated instances In-Reply-To: <046.699ef2ff00fb815c84fa41ceb8d156c0@haskell.org> References: <046.699ef2ff00fb815c84fa41ceb8d156c0@haskell.org> Message-ID: <061.70fae8f8fe995aeff26907fbfc22d0b3@haskell.org> #10858: Smaller generated instances -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * keywords: newcomer => Comment: How does this relate to #9557? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 8 19:56:45 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Sep 2015 19:56:45 -0000 Subject: [GHC] #10858: Smaller generated instances In-Reply-To: <046.699ef2ff00fb815c84fa41ceb8d156c0@haskell.org> References: <046.699ef2ff00fb815c84fa41ceb8d156c0@haskell.org> Message-ID: <061.950e88fd04322239fcbdb8f3f78df4ec@haskell.org> #10858: Smaller generated instances -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 8 20:02:10 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Sep 2015 20:02:10 -0000 Subject: [GHC] #10858: Smaller generated Ord instances (was: Smaller generated instances) In-Reply-To: <046.699ef2ff00fb815c84fa41ceb8d156c0@haskell.org> References: <046.699ef2ff00fb815c84fa41ceb8d156c0@haskell.org> Message-ID: <061.d15cae91c351bee7d0ce75cc6ff3b6fb@haskell.org> #10858: Smaller generated Ord instances -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9557 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by nomeata): * keywords: newcomer => * related: => #9557 Comment: Ah, so I had that feeling before. I guess it is a duplicate.. or maybe this ticket is now more specific to talk about Ord. Re note `Note [Do not rely on compare]`: Note that we actually do rely on `compare` for all but the last field. So either the note can be ignored (at least in the case of product types), or a similar chain, not using `compare` can be built for the other operators: {{{ (<) a_acXz b_acXA = case a_acXz of { ImportDecl a1_acXB a2_acXC a3_acXD a4_acXE a5_acXF a6_acXG a7_acXH a8_acXI -> case b_acXA of { ImportDecl b1_acXJ b2_acXK b3_acXL b4_acXM b5_acXN b6_acXO b7_acXP b8_acXQ -> (<) a1_acXB b1_acXJ || (<) a2_acXC b2_acXK || (<) a3_acXD b3_acXL || (<) a4_acXE b4_acXM || (<) a5_acXF b5_acXN || (<) a6_acXG b6_acXO || (<) a7_acXH b7_acXP || (<) a8_acXI b8_acXQ }}} This follows the same pattern above, just using the right connective: It should be `||` for `(<)` and `(>)`, `&&` for `(<=)` and `(>=)` and `thenComp` for `compare`. And one should check that this is right- associative, to get the right lazy behavior. Still a nice ticket for new contributors. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 8 20:02:41 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Sep 2015 20:02:41 -0000 Subject: [GHC] #9557: Deriving instances is slow In-Reply-To: <048.4125fec548f18fcd48da9989fc1ebc4e@haskell.org> References: <048.4125fec548f18fcd48da9989fc1ebc4e@haskell.org> Message-ID: <063.1fca4288bcfe0d5dee85cf3e36b54113@haskell.org> #9557: Deriving instances is slow -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8731 #10858 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by nomeata): * related: #8731 => #8731 #10858 Comment: See #10858 for some ideas around the specific case of the `Ord` instance. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 8 20:21:24 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Sep 2015 20:21:24 -0000 Subject: [GHC] #10494: Representational equalities over AppTys are not hard failures In-Reply-To: <047.6c55cf81fc9e307934dd2710cdafc698@haskell.org> References: <047.6c55cf81fc9e307934dd2710cdafc698@haskell.org> Message-ID: <062.1199a1e89e77edc987f90c828509352a@haskell.org> #10494: Representational equalities over AppTys are not hard failures -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T10494 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by crockeea): Replying to [comment:2 goldfire]: > Merge if convenient. Another real bug, but I doubt it's ruining anyone's day. This is ruining my day, see #10428. Replying to [comment:5 goldfire]: > Quite possible. I guess I didn't test in 7.10. And, in any case, you've simply decided that it's not convenient to merge the change. :) So what's the status of this fix? It appears that the example in this ticket may be moot, but apparently the fix affects #10428, which *is* present in 7.10.1. Did the patch make 7.10.2? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 8 20:24:51 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Sep 2015 20:24:51 -0000 Subject: [GHC] #8552: Rename StgArrWords to StgArrBytes In-Reply-To: <047.162074162cf551ca6b1ad3c66a412848@haskell.org> References: <047.162074162cf551ca6b1ad3c66a412848@haskell.org> Message-ID: <062.50eff9311fd2c9b6abc84be9102c60e6@haskell.org> #8552: Rename StgArrWords to StgArrBytes -------------------------------------+------------------------------------- Reporter: Tarrasch | Owner: | siddhanathan Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by siddhanathan): * owner: => siddhanathan -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 8 20:37:28 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Sep 2015 20:37:28 -0000 Subject: [GHC] #10858: Smaller generated Ord instances In-Reply-To: <046.699ef2ff00fb815c84fa41ceb8d156c0@haskell.org> References: <046.699ef2ff00fb815c84fa41ceb8d156c0@haskell.org> Message-ID: <061.f36f1ab892a211a1d60c38979b71863e@haskell.org> #10858: Smaller generated Ord instances -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9557 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): The annoying thing with `newcomer` tickets is that they are also usual fun and rewarding things to work on. So I gave it a shot at branch `wip/T10858`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 8 20:49:20 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Sep 2015 20:49:20 -0000 Subject: [GHC] #10859: Generated Eq instance associates && wrongly Message-ID: <046.4f10604a3fa32deb15c9056d38ba731c@haskell.org> #10859: Generated Eq instance associates && wrongly -------------------------------------+------------------------------------- Reporter: nomeata | Owner: simonpj Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #10858 Differential Revisions: | -------------------------------------+------------------------------------- Currently, we derive this code for `(==)`: {{{ (==) (ImportDecl a1_acXi a2_acXj a3_acXk a4_acXl a5_acXm a6_acXn a7_acXo a8_acXp) (ImportDecl b1_acXq b2_acXr b3_acXs b4_acXt b5_acXu b6_acXv b7_acXw b8_acXx) = (((((((((a1_acXi == b1_acXq)) && ((a2_acXj == b2_acXr))) && ((a3_acXk == b3_acXs))) && ((a4_acXl == b4_acXt))) && ((a5_acXm == b5_acXu))) && ((a6_acXn == b6_acXv))) && ((a7_acXo == b7_acXw))) && ((a8_acXp == b8_acXx))) }}} To me this looks wrongly associated: Since `&&` is strict in the left but lazy in the right argument, shouldn?t this be associated the other way around? The compiler might clean it up later, but why not produce it correctly right away? The culprit is this line: {{{ = foldl1 and_Expr (zipWith3Equal "nested_eq" nested_eq tys as bs) }}} and I was just about to change that ot `foldr1`, but then I did some git- archeology and found that Simon changed that deliberately from `foldr1` to `foldl1` in changeset:8de16184643ea3c2f9f30b5eaed18db6ef247760. Simon, do you still recall what you were thinking when you applied this commit ... 18?years ago? :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 8 21:10:25 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Sep 2015 21:10:25 -0000 Subject: [GHC] #10858: Smaller generated Ord instances In-Reply-To: <046.699ef2ff00fb815c84fa41ceb8d156c0@haskell.org> References: <046.699ef2ff00fb815c84fa41ceb8d156c0@haskell.org> Message-ID: <061.00c030d0b18c0d0b3eced8a5060b97d4@haskell.org> #10858: Smaller generated Ord instances -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9557 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): With some of the ideas in #10858 implemented, the number of terms reported in `-ddump-ds` for `Language.Haskell.Exts.Annotated.Syntax` goes down from 207,936 to 202,252. An improvement, but I was hoping for more. Using the overloaded `(<>)` on `Ordering` incurs a cost; lots of code just to call `<>` with the right instance. It might be worth monomorphizing that to `thenCmp`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 8 21:17:44 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Sep 2015 21:17:44 -0000 Subject: [GHC] #10835: Regression in standalone Data deriving for phantom types In-Reply-To: <048.e488f2f2d397e40d5fcfbc59cce5f092@haskell.org> References: <048.e488f2f2d397e40d5fcfbc59cce5f092@haskell.org> Message-ID: <063.09217cb006e4fb331245e76b40df1844@haskell.org> #10835: Regression in standalone Data deriving for phantom types -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * owner: => bgamari Comment: I'll make sure this is handled either in or after Phab:D757. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 8 21:36:13 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Sep 2015 21:36:13 -0000 Subject: [GHC] #10858: Smaller generated Ord instances In-Reply-To: <046.699ef2ff00fb815c84fa41ceb8d156c0@haskell.org> References: <046.699ef2ff00fb815c84fa41ceb8d156c0@haskell.org> Message-ID: <061.a28d2b7ec0da55216003b948f25d921d@haskell.org> #10858: Smaller generated Ord instances -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9557 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): Please ignore my last four comments. This idea is completely bogus for the other operators (it still works for `compare`). I blame it on the jet lag and better go to bed now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 8 22:08:00 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Sep 2015 22:08:00 -0000 Subject: [GHC] #10858: Smaller generated Ord instances In-Reply-To: <046.699ef2ff00fb815c84fa41ceb8d156c0@haskell.org> References: <046.699ef2ff00fb815c84fa41ceb8d156c0@haskell.org> Message-ID: <061.ce9c3926d3a15404e75d8c07785b8e8a@haskell.org> #10858: Smaller generated Ord instances -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9557 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * failure: None/Unknown => Compile-time performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 8 22:19:31 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Sep 2015 22:19:31 -0000 Subject: [GHC] #10846: PartialTypeSignatures change implicit CallStack behavior In-Reply-To: <053.4274e891f1314fe985c1165bde8fc4e5@haskell.org> References: <053.4274e891f1314fe985c1165bde8fc4e5@haskell.org> Message-ID: <068.0d0ca467627f5490ec91592251257683@haskell.org> #10846: PartialTypeSignatures change implicit CallStack behavior -------------------------------------+------------------------------------- Reporter: nitromaster101 | Owner: gridaphobe Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gridaphobe): * owner: => gridaphobe -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 8 22:19:47 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Sep 2015 22:19:47 -0000 Subject: [GHC] #10845: Incorrect behavior when let binding implicit CallStack object In-Reply-To: <053.cff44270042de7bde1a56c8d798b5b0a@haskell.org> References: <053.cff44270042de7bde1a56c8d798b5b0a@haskell.org> Message-ID: <068.650b7f445dd1479b907a404f948b62a7@haskell.org> #10845: Incorrect behavior when let binding implicit CallStack object -------------------------------------+------------------------------------- Reporter: nitromaster101 | Owner: gridaphobe Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gridaphobe): * owner: => gridaphobe -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 8 22:38:05 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Sep 2015 22:38:05 -0000 Subject: [GHC] #8405: experiment with using function-sections for linking (for smaller libs and executables) In-Reply-To: <045.ff128453c9ddce6d07b91486f573635a@haskell.org> References: <045.ff128453c9ddce6d07b91486f573635a@haskell.org> Message-ID: <060.714d1fd89889d2212a8b40d683e158aa@haskell.org> #8405: experiment with using function-sections for linking (for smaller libs and executables) -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by olsner): Comparing the size of libraries/*/dist-install/build/*.a from each tree, the sections build was 71MB and the split objects build was 99MB, compared to 41MB for a non-split build. Slightly less bloat than split-objs at least. Meanwhile, I found the reason for the missing savings compared to split- objs: I had missed that SRT table generation was generating split or monolithic SRT tables depending on the split-objs flag. For now, I made the split SRTs unconditional (since the section splitting is also always on), and that made my "hello world" 10% smaller with sections than with split-objs (20% diff after stripping). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 8 23:34:48 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Sep 2015 23:34:48 -0000 Subject: [GHC] #8552: Rename StgArrWords to StgArrBytes In-Reply-To: <047.162074162cf551ca6b1ad3c66a412848@haskell.org> References: <047.162074162cf551ca6b1ad3c66a412848@haskell.org> Message-ID: <062.f303bfdb81324acea220b66c01d2037b@haskell.org> #8552: Rename StgArrWords to StgArrBytes -------------------------------------+------------------------------------- Reporter: Tarrasch | Owner: | siddhanathan Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1233 -------------------------------------+------------------------------------- Changes (by siddhanathan): * differential: => Phab:D1233 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 8 23:53:53 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Sep 2015 23:53:53 -0000 Subject: [GHC] #10841: Run handler on STM retry In-Reply-To: <045.10ea2aa941550aac6248eb677ce6a5a6@haskell.org> References: <045.10ea2aa941550aac6248eb677ce6a5a6@haskell.org> Message-ID: <060.5195bee842a5c2f08200f29f19869856@haskell.org> #10841: Run handler on STM retry -------------------------------------+------------------------------------- Reporter: shlevy | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries | Version: 7.10.2 (other) | Resolution: | Keywords: stm Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by fryguybob): I don't think it is terribly difficult to implement something like this. The retry handler would be stuffed on the atomically frame and when `retry` reaches that frame it could easily be executed instead of blocking. I do wonder though if such a thing can be used effectively and what additional information would make it more effective. Can anyone shed some light on what particular deficiency in STM or STM applications leads to wanting this? I can imagine some other information that could make `retry` align better with intentions like a version of `retry` to invoke when the condition encountered is rare and expected to be resolved quickly making it harder to starve due to a round trip through the scheduler. Your application is also free to catch `retry` throw an exception instead with any internal details of your transaction you want. You don't get a wake up when a `TVar` changes with this option, but you can try again right away run a different transaction or delay by some other means. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 9 01:21:49 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Sep 2015 01:21:49 -0000 Subject: [GHC] #10494: Representational equalities over AppTys are not hard failures In-Reply-To: <047.6c55cf81fc9e307934dd2710cdafc698@haskell.org> References: <047.6c55cf81fc9e307934dd2710cdafc698@haskell.org> Message-ID: <062.9ed7c85add58f17c20d36725ea978228@haskell.org> #10494: Representational equalities over AppTys are not hard failures -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: merge Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T10494 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * status: closed => merge * milestone: => 7.10.3 Comment: Replying to [comment:6 crockeea]: > This is ruining my day, see #10428. Hm. I'm a little confused here, then. Could this fix be merged for 7.10.3 (if that happens)? The original case in #10428 compiles with HEAD but fails with 7.10.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 9 02:59:48 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Sep 2015 02:59:48 -0000 Subject: [GHC] #8405: experiment with using function-sections for linking (for smaller libs and executables) In-Reply-To: <045.ff128453c9ddce6d07b91486f573635a@haskell.org> References: <045.ff128453c9ddce6d07b91486f573635a@haskell.org> Message-ID: <060.6069fa3a230cb5c2303fe44f7dc6c704@haskell.org> #8405: experiment with using function-sections for linking (for smaller libs and executables) -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by refold): Replying to [comment:9 olsner]: > > [...] that made my "hello world" 10% smaller with sections than with split-objs (20% diff after stripping). Very cool, thanks for working on this! Link times with `--gc-sections` should be also much faster than with split-objs, especially for something like OpenGL. And it looks like `--gc-sections` [https://sourceware.org/git/gitweb.cgi?p =binutils-gdb.git;h=0f088b2a9417b1d4ed597849ffa671eba25f5051 is now finally supported on Windows] (though the patch still needs testing). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 9 03:47:51 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Sep 2015 03:47:51 -0000 Subject: [GHC] #10842: "Reactive" Template Haskell In-Reply-To: <050.6f7bb562017372f9e5bba0241a40c1a7@haskell.org> References: <050.6f7bb562017372f9e5bba0241a40c1a7@haskell.org> Message-ID: <065.a51e248803cad7ddf53b8b8b7a3c311f@haskell.org> #10842: "Reactive" Template Haskell -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 9699 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by luite): Should the callback be active for the current module or for something more? Beyond the current module would be hard to support in the presence of partial rebuilds. Should this be called for all declarations below the point adding the callback, or just for those added by TH? If this is to be called for everything, then this could end up being problematic for new language extensions that cannot yet be converted to a TH `Dec` . Also I'm a bit wary about having more higher order functions in the low- level `Q` API, since they're significantly harder to support in implementations where TH isn't run in the GHC address space (like GHCJS and the proposed out-of-process TH extension for stage1 (cross) compiler TH support). As far as I can tell, this particular extension would still be implementable though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 9 08:10:42 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Sep 2015 08:10:42 -0000 Subject: [GHC] #10672: GHCi linker does not understand C++ exception tables on Windows In-Reply-To: <045.04cee7c60b130b0ccc29791ed61c4f5f@haskell.org> References: <045.04cee7c60b130b0ccc29791ed61c4f5f@haskell.org> Message-ID: <060.9a5dee860834cc16448dd6a247ddbd1e@haskell.org> #10672: GHCi linker does not understand C++ exception tables on Windows -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Phyx- Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: Runtime System | Version: 7.10.1 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #9297 #10563 | Differential Revisions: #8237 #9907 | -------------------------------------+------------------------------------- Comment (by lukexi): Hi Phyx-/all ??let me know if there are any public repos with work-in- progress on this; I'd love to help out! Planning on giving it some time later this week. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 9 08:19:08 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Sep 2015 08:19:08 -0000 Subject: [GHC] #10831: Document conditions on deriving Functor In-Reply-To: <048.8298ed09a98386a50539acd12ba36fa5@haskell.org> References: <048.8298ed09a98386a50539acd12ba36fa5@haskell.org> Message-ID: <063.f10d947ad74f33d19df219a61efbcd41@haskell.org> #10831: Document conditions on deriving Functor -------------------------------------+------------------------------------- Reporter: htebalaka | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | 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 simonpj): * cc: RyanGlScott (added) Comment: Ryan Scott made an implementation-oriented stab at documenting Functor, Foldable, Traversable here: [wiki:Commentary/Compiler/DeriveFunctor]. But I think we still lack a user-oriented specification, and such a thing would be tremendously welcome. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 9 08:32:49 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Sep 2015 08:32:49 -0000 Subject: [GHC] #10858: Smaller generated Ord instances In-Reply-To: <046.699ef2ff00fb815c84fa41ceb8d156c0@haskell.org> References: <046.699ef2ff00fb815c84fa41ceb8d156c0@haskell.org> Message-ID: <061.ee70c06d7d37780669ae7dd70937c885@haskell.org> #10858: Smaller generated Ord instances -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9557 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): I'm not following the details here but: * I think it's an excellent idea to use `thenCmp` (will dramatically simplify the output of `-ddump-deriv`) * But I suspect it won't make a lot of difference in the end, because GHC will probably inline `thenCmp`! But what is stranger to me is this: why don't we just derive the code for `compare`, and use the default methods for `(>)`, `(==)` etc? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 9 08:34:20 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Sep 2015 08:34:20 -0000 Subject: [GHC] #10859: Generated Eq instance associates && wrongly In-Reply-To: <046.4f10604a3fa32deb15c9056d38ba731c@haskell.org> References: <046.4f10604a3fa32deb15c9056d38ba731c@haskell.org> Message-ID: <061.bf1b6cf2027eaf2b5c72b115e7c50217@haskell.org> #10859: Generated Eq instance associates && wrongly -------------------------------------+------------------------------------- Reporter: nomeata | Owner: simonpj Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10858 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by nomeata): * priority: low => lowest Comment: (I just verified that the resulting code after optimization is indeed the same. So this is purely cosmetic, and probably not worth the bother.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 9 08:37:32 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Sep 2015 08:37:32 -0000 Subject: [GHC] #10858: Smaller generated Ord instances In-Reply-To: <046.699ef2ff00fb815c84fa41ceb8d156c0@haskell.org> References: <046.699ef2ff00fb815c84fa41ceb8d156c0@haskell.org> Message-ID: <061.2c69afc44340982c3f3b534878f06760@haskell.org> #10858: Smaller generated Ord instances -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9557 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): > But what is stranger to me is this: why don't we just derive the code for compare, and use the default methods for (>), (==) etc? That?s what I thought at first myself, but then I stumbled over this: {{{ Note [Do not rely on compare] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ It's a bad idea to define only 'compare', and build the other binary comparisons on top of it; see Trac #2130, #4019. Reason: we don't want to laboriously make a three-way comparison, only to extract a binary result, something like this: (>) (I# x) (I# y) = case <# x y of True -> False False -> case ==# x y of True -> False False -> True So for sufficiently small types (few constructors, or all nullary) we generate all methods; for large ones we just use 'compare'. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 9 08:39:00 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Sep 2015 08:39:00 -0000 Subject: [GHC] #10494: Representational equalities over AppTys are not hard failures In-Reply-To: <047.6c55cf81fc9e307934dd2710cdafc698@haskell.org> References: <047.6c55cf81fc9e307934dd2710cdafc698@haskell.org> Message-ID: <062.b389dfedbfce158503a5e91c657af63f@haskell.org> #10494: Representational equalities over AppTys are not hard failures -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: merge Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T10494 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): So, @crockeea, are you asking for 7.10.3? i.e. is this a serious problem for you (and if so can you elaborate on why)? See [wiki:Status/GHC-7.10.3]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 9 08:46:02 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Sep 2015 08:46:02 -0000 Subject: [GHC] #10859: Generated Eq instance associates && wrongly In-Reply-To: <046.4f10604a3fa32deb15c9056d38ba731c@haskell.org> References: <046.4f10604a3fa32deb15c9056d38ba731c@haskell.org> Message-ID: <061.91d14de9e9cdd426d37dc6af4f9720bb@haskell.org> #10859: Generated Eq instance associates && wrongly -------------------------------------+------------------------------------- Reporter: nomeata | Owner: simonpj Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10858 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): I'm afraid I have no idea. Remember that we are also (#10854) trying to generate `HsExpr`s that have explicit `HsParens` when needed. So I'm all for this clean-up. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 9 09:00:31 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Sep 2015 09:00:31 -0000 Subject: [GHC] #10841: Run handler on STM retry In-Reply-To: <045.10ea2aa941550aac6248eb677ce6a5a6@haskell.org> References: <045.10ea2aa941550aac6248eb677ce6a5a6@haskell.org> Message-ID: <060.a8ef6140e7215bb1c0fcae1ef44f1f0c@haskell.org> #10841: Run handler on STM retry -------------------------------------+------------------------------------- Reporter: shlevy | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries | Version: 7.10.2 (other) | Resolution: | Keywords: stm Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): My use-case is this. Suppose a long-running transaction is repeatedly aborted because short-running transactions get in first. It might "starve". Then what? At the moment there is literally nothing the programmer can do because starvation is un-observable. Adding a retry handler makes it observable. Example: a librarian wants to re-organise the science fiction shelves of the library, but his long-running "reorganise" transaction is always aborted by someone doing a short-running "borrow-book" transaction. There is no automatic solution to this; it's an application-domain problem. For example, if the reorg became too long delayed, the librarian might temporarily close the SF section to borrowers. In the transactional setting, the retry handler might (in a separate, preliminary transaction) take a lock on the section, which borrowers must respect. None of this can happen unless the programmer can observe excessive retries and code a response. For example, she could count retries, and use an alternative strategy if the count got too high. (Actually, it might be convenient if the retry count was passed to the hander, so that the handler didn't need to create the state-and-increment stuff to manage the count.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 9 10:28:34 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Sep 2015 10:28:34 -0000 Subject: [GHC] #8809: Prettier error messages? In-Reply-To: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> References: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> Message-ID: <062.3fdd2a26f96341058d59364521fc6c88@haskell.org> #8809: Prettier error messages? -------------------------------------+------------------------------------- Reporter: joelteon | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by alanz): * cc: alanz (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 9 10:48:44 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Sep 2015 10:48:44 -0000 Subject: [GHC] #10858: Smaller generated Ord instances In-Reply-To: <046.699ef2ff00fb815c84fa41ceb8d156c0@haskell.org> References: <046.699ef2ff00fb815c84fa41ceb8d156c0@haskell.org> Message-ID: <061.9f92c61bef88d09d4afc6defc2790ef7@haskell.org> #10858: Smaller generated Ord instances -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9557 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): That `Note` looks plausible but ONLY if you recursively use `(<)` in the implementation of `(<)`. But in the code you give above for `Ord` on `ImportDecl` we seem to call `compare` recursively when implementing `(<)`. So we are taking the hit described in the `Note`, but blowing up the code much more than necessary! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 9 11:22:39 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Sep 2015 11:22:39 -0000 Subject: [GHC] #1830: Automatic derivation of Lift In-Reply-To: <044.3eb409743bc4021eb94e63cb46f573bc@haskell.org> References: <044.3eb409743bc4021eb94e63cb46f573bc@haskell.org> Message-ID: <059.5d63e3d76c02fbc27a9f97538821d56d@haskell.org> #1830: Automatic derivation of Lift -------------------------------------+------------------------------------- Reporter: guest | Owner: | RyanGlScott Type: feature request | Status: new Priority: normal | Milestone: ? Component: Template Haskell | Version: 6.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1168 -------------------------------------+------------------------------------- Comment (by simonpj): See also [wiki:ValidateMonoLiterals] for a use-case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 9 11:39:15 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Sep 2015 11:39:15 -0000 Subject: [GHC] #10858: Smaller generated Ord instances In-Reply-To: <046.699ef2ff00fb815c84fa41ceb8d156c0@haskell.org> References: <046.699ef2ff00fb815c84fa41ceb8d156c0@haskell.org> Message-ID: <061.6ef07b4ff9897fe2ca994704d01eab32@haskell.org> #10858: Smaller generated Ord instances -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9557 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): Note that we are calling `compare` in the implementation of `<` for all but the last argument. (You might have to scroll to the right to see it). In the not uncommon corner case of only one field, we are thus only calling `<`, as described in the Note. So it seems that for large product types, the default implementation is not much worse than the generated, while for data types with few or only one field, we should generate dedicated methods. But where is the bound? What with datatypes with multiple constructors? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 9 11:40:03 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Sep 2015 11:40:03 -0000 Subject: [GHC] #10376: arm/linux linking failure In-Reply-To: <044.29ac411aa184ff9b10d3766853c9a35d@haskell.org> References: <044.29ac411aa184ff9b10d3766853c9a35d@haskell.org> Message-ID: <059.56b6d9d463993b46fd25d372341f5928@haskell.org> #10376: arm/linux linking failure -------------------------------------+--------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #10464 | Differential Revisions: -------------------------------------+--------------------------------- Comment (by k-bx): Steps to reproduce in case you don't have an access to an ARM machine: 1. Get a $3.40/month [http://techcrunch.com/2015/09/02/scaleway-now- provides-crazy-cheap-virtual-private-servers-starting-at-3-40-per-month/ dedicated ARM server] (sorry if it sounds like an ad) 2. Install [https://packages.debian.org/experimental/armhf/ghc/download GHC from debian experimental] 3. {{{ # uname -a Linux arm 4.1.6-249 #1 SMP Mon Aug 31 12:34:47 UTC 2015 armv7l armv7l armv7l GNU/Linux # cabal install text # cat Main.hs {-# LANGUAGE OverloadedStrings #-} module Main where import qualified Data.Text.IO as T main :: IO () main = do T.putStrLn "hello world" # ghc -fforce-recomp Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... /usr/bin/ld.gold: warning: cannot scan executable section 1 of /root/.cabal/lib/arm-linux- ghc-7.10.2/text-1.2.1.3/libHStext-1.2.1.3-1l1AN4I48k37RaQ6fm6CEh.a(Text.o) for Cortex-A8 erratum because it has no mapping symbols. /usr/bin/ld.gold: warning: cannot scan executable section 1 of /root/.cabal/lib/arm-linux- ghc-7.10.2/text-1.2.1.3/libHStext-1.2.1.3-1l1AN4I48k37RaQ6fm6CEh.a(Array.o) for Cortex-A8 erratum because it has no mapping symbols. /usr/bin/ld.gold: warning: cannot scan executable section 1 of /root/.cabal/lib/arm-linux- ghc-7.10.2/text-1.2.1.3/libHStext-1.2.1.3-1l1AN4I48k37RaQ6fm6CEh.a(Encoding.o) for Cortex-A8 erratum because it has no mapping symbols. /usr/bin/ld.gold: warning: cannot scan executable section 1 of /root/.cabal/lib/arm-linux- ghc-7.10.2/text-1.2.1.3/libHStext-1.2.1.3-1l1AN4I48k37RaQ6fm6CEh.a(Error.o) for Cortex-A8 erratum because it has no mapping symbols. /usr/bin/ld.gold: warning: cannot scan executable section 1 of /root/.cabal/lib/arm-linux- ghc-7.10.2/text-1.2.1.3/libHStext-1.2.1.3-1l1AN4I48k37RaQ6fm6CEh.a(IO.o) for Cortex-A8 erratum because it has no mapping symbols. /usr/bin/ld.gold: warning: cannot scan executable section 1 of /root/.cabal/lib/arm-linux- ghc-7.10.2/text-1.2.1.3/libHStext-1.2.1.3-1l1AN4I48k37RaQ6fm6CEh.a(Internal.o) for Cortex-A8 erratum because it has no mapping symbols. /usr/bin/ld.gold: warning: cannot scan executable section 1 of /root/.cabal/lib/arm-linux- ghc-7.10.2/text-1.2.1.3/libHStext-1.2.1.3-1l1AN4I48k37RaQ6fm6CEh.a(Fusion.o) for Cortex-A8 erratum because it has no mapping symbols. /usr/bin/ld.gold: warning: cannot scan executable section 1 of /root/.cabal/lib/arm-linux- ghc-7.10.2/text-1.2.1.3/libHStext-1.2.1.3-1l1AN4I48k37RaQ6fm6CEh.a(CaseMapping.o) for Cortex-A8 erratum because it has no mapping symbols. /usr/bin/ld.gold: warning: cannot scan executable section 1 of /root/.cabal/lib/arm-linux- ghc-7.10.2/text-1.2.1.3/libHStext-1.2.1.3-1l1AN4I48k37RaQ6fm6CEh.a(Common.o) for Cortex-A8 erratum because it has no mapping symbols. /usr/bin/ld.gold: warning: cannot scan executable section 1 of /root/.cabal/lib/arm-linux- ghc-7.10.2/text-1.2.1.3/libHStext-1.2.1.3-1l1AN4I48k37RaQ6fm6CEh.a(Size.o) for Cortex-A8 erratum because it has no mapping symbols. /usr/bin/ld.gold: warning: cannot scan executable section 1 of /root/.cabal/lib/arm-linux- ghc-7.10.2/text-1.2.1.3/libHStext-1.2.1.3-1l1AN4I48k37RaQ6fm6CEh.a(Types.o) for Cortex-A8 erratum because it has no mapping symbols. /usr/bin/ld.gold: warning: cannot scan executable section 1 of /root/.cabal/lib/arm-linux- ghc-7.10.2/text-1.2.1.3/libHStext-1.2.1.3-1l1AN4I48k37RaQ6fm6CEh.a(IO.o) for Cortex-A8 erratum because it has no mapping symbols. /usr/bin/ld.gold: warning: cannot scan executable section 1 of /root/.cabal/lib/arm-linux- ghc-7.10.2/text-1.2.1.3/libHStext-1.2.1.3-1l1AN4I48k37RaQ6fm6CEh.a(Unsafe.o) for Cortex-A8 erratum because it has no mapping symbols. /usr/bin/ld.gold: warning: cannot scan executable section 1 of /root/.cabal/lib/arm-linux- ghc-7.10.2/text-1.2.1.3/libHStext-1.2.1.3-1l1AN4I48k37RaQ6fm6CEh.a(Show.o) for Cortex-A8 erratum because it has no mapping symbols. /usr/bin/ld.gold: warning: cannot scan executable section 1 of /root/.cabal/lib/arm-linux- ghc-7.10.2/text-1.2.1.3/libHStext-1.2.1.3-1l1AN4I48k37RaQ6fm6CEh.a(Text.o) for Cortex-A8 erratum because it has no mapping symbols. /usr/bin/ld.gold: warning: cannot scan executable section 1 of /root/.cabal/lib/arm-linux- ghc-7.10.2/text-1.2.1.3/libHStext-1.2.1.3-1l1AN4I48k37RaQ6fm6CEh.a(Array.o) for Cortex-A8 erratum because it has no mapping symbols. /usr/bin/ld.gold: warning: cannot scan executable section 1 of /root/.cabal/lib/arm-linux- ghc-7.10.2/text-1.2.1.3/libHStext-1.2.1.3-1l1AN4I48k37RaQ6fm6CEh.a(Encoding.o) for Cortex-A8 erratum because it has no mapping symbols. /usr/bin/ld.gold: warning: cannot scan executable section 1 of /root/.cabal/lib/arm-linux- ghc-7.10.2/text-1.2.1.3/libHStext-1.2.1.3-1l1AN4I48k37RaQ6fm6CEh.a(Error.o) for Cortex-A8 erratum because it has no mapping symbols. /usr/bin/ld.gold: warning: cannot scan executable section 1 of /root/.cabal/lib/arm-linux- ghc-7.10.2/text-1.2.1.3/libHStext-1.2.1.3-1l1AN4I48k37RaQ6fm6CEh.a(IO.o) for Cortex-A8 erratum because it has no mapping symbols. /usr/bin/ld.gold: warning: cannot scan executable section 1 of /root/.cabal/lib/arm-linux- ghc-7.10.2/text-1.2.1.3/libHStext-1.2.1.3-1l1AN4I48k37RaQ6fm6CEh.a(Internal.o) for Cortex-A8 erratum because it has no mapping symbols. /usr/bin/ld.gold: warning: cannot scan executable section 1 of /root/.cabal/lib/arm-linux- ghc-7.10.2/text-1.2.1.3/libHStext-1.2.1.3-1l1AN4I48k37RaQ6fm6CEh.a(Fusion.o) for Cortex-A8 erratum because it has no mapping symbols. /usr/bin/ld.gold: warning: cannot scan executable section 1 of /root/.cabal/lib/arm-linux- ghc-7.10.2/text-1.2.1.3/libHStext-1.2.1.3-1l1AN4I48k37RaQ6fm6CEh.a(CaseMapping.o) for Cortex-A8 erratum because it has no mapping symbols. /usr/bin/ld.gold: warning: cannot scan executable section 1 of /root/.cabal/lib/arm-linux- ghc-7.10.2/text-1.2.1.3/libHStext-1.2.1.3-1l1AN4I48k37RaQ6fm6CEh.a(Common.o) for Cortex-A8 erratum because it has no mapping symbols. /usr/bin/ld.gold: warning: cannot scan executable section 1 of /root/.cabal/lib/arm-linux- ghc-7.10.2/text-1.2.1.3/libHStext-1.2.1.3-1l1AN4I48k37RaQ6fm6CEh.a(Size.o) for Cortex-A8 erratum because it has no mapping symbols. /usr/bin/ld.gold: warning: cannot scan executable section 1 of /root/.cabal/lib/arm-linux- ghc-7.10.2/text-1.2.1.3/libHStext-1.2.1.3-1l1AN4I48k37RaQ6fm6CEh.a(Types.o) for Cortex-A8 erratum because it has no mapping symbols. /usr/bin/ld.gold: warning: cannot scan executable section 1 of /root/.cabal/lib/arm-linux- ghc-7.10.2/text-1.2.1.3/libHStext-1.2.1.3-1l1AN4I48k37RaQ6fm6CEh.a(IO.o) for Cortex-A8 erratum because it has no mapping symbols. /usr/bin/ld.gold: warning: cannot scan executable section 1 of /root/.cabal/lib/arm-linux- ghc-7.10.2/text-1.2.1.3/libHStext-1.2.1.3-1l1AN4I48k37RaQ6fm6CEh.a(Unsafe.o) for Cortex-A8 erratum because it has no mapping symbols. /usr/bin/ld.gold: warning: cannot scan executable section 1 of /root/.cabal/lib/arm-linux- ghc-7.10.2/text-1.2.1.3/libHStext-1.2.1.3-1l1AN4I48k37RaQ6fm6CEh.a(Show.o) for Cortex-A8 erratum because it has no mapping symbols. /usr/bin/ld.gold: warning: cannot scan executable section 1 of /root/.cabal/lib/arm-linux- ghc-7.10.2/text-1.2.1.3/libHStext-1.2.1.3-1l1AN4I48k37RaQ6fm6CEh.a(Text.o) for Cortex-A8 erratum because it has no mapping symbols. /usr/bin/ld.gold: warning: cannot scan executable section 1 of /root/.cabal/lib/arm-linux- ghc-7.10.2/text-1.2.1.3/libHStext-1.2.1.3-1l1AN4I48k37RaQ6fm6CEh.a(Array.o) for Cortex-A8 erratum because it has no mapping symbols. /usr/bin/ld.gold: warning: cannot scan executable section 1 of /root/.cabal/lib/arm-linux- ghc-7.10.2/text-1.2.1.3/libHStext-1.2.1.3-1l1AN4I48k37RaQ6fm6CEh.a(Encoding.o) for Cortex-A8 erratum because it has no mapping symbols. /usr/bin/ld.gold: warning: cannot scan executable section 1 of /root/.cabal/lib/arm-linux- ghc-7.10.2/text-1.2.1.3/libHStext-1.2.1.3-1l1AN4I48k37RaQ6fm6CEh.a(Error.o) for Cortex-A8 erratum because it has no mapping symbols. /usr/bin/ld.gold: warning: cannot scan executable section 1 of /root/.cabal/lib/arm-linux- ghc-7.10.2/text-1.2.1.3/libHStext-1.2.1.3-1l1AN4I48k37RaQ6fm6CEh.a(IO.o) for Cortex-A8 erratum because it has no mapping symbols. /usr/bin/ld.gold: warning: cannot scan executable section 1 of /root/.cabal/lib/arm-linux- ghc-7.10.2/text-1.2.1.3/libHStext-1.2.1.3-1l1AN4I48k37RaQ6fm6CEh.a(Internal.o) for Cortex-A8 erratum because it has no mapping symbols. /usr/bin/ld.gold: warning: cannot scan executable section 1 of /root/.cabal/lib/arm-linux- ghc-7.10.2/text-1.2.1.3/libHStext-1.2.1.3-1l1AN4I48k37RaQ6fm6CEh.a(Fusion.o) for Cortex-A8 erratum because it has no mapping symbols. /usr/bin/ld.gold: warning: cannot scan executable section 1 of /root/.cabal/lib/arm-linux- ghc-7.10.2/text-1.2.1.3/libHStext-1.2.1.3-1l1AN4I48k37RaQ6fm6CEh.a(CaseMapping.o) for Cortex-A8 erratum because it has no mapping symbols. /usr/bin/ld.gold: warning: cannot scan executable section 1 of /root/.cabal/lib/arm-linux- ghc-7.10.2/text-1.2.1.3/libHStext-1.2.1.3-1l1AN4I48k37RaQ6fm6CEh.a(Common.o) for Cortex-A8 erratum because it has no mapping symbols. /usr/bin/ld.gold: warning: cannot scan executable section 1 of /root/.cabal/lib/arm-linux- ghc-7.10.2/text-1.2.1.3/libHStext-1.2.1.3-1l1AN4I48k37RaQ6fm6CEh.a(Size.o) for Cortex-A8 erratum because it has no mapping symbols. /usr/bin/ld.gold: warning: cannot scan executable section 1 of /root/.cabal/lib/arm-linux- ghc-7.10.2/text-1.2.1.3/libHStext-1.2.1.3-1l1AN4I48k37RaQ6fm6CEh.a(Types.o) for Cortex-A8 erratum because it has no mapping symbols. /usr/bin/ld.gold: warning: cannot scan executable section 1 of /root/.cabal/lib/arm-linux- ghc-7.10.2/text-1.2.1.3/libHStext-1.2.1.3-1l1AN4I48k37RaQ6fm6CEh.a(IO.o) for Cortex-A8 erratum because it has no mapping symbols. /usr/bin/ld.gold: warning: cannot scan executable section 1 of /root/.cabal/lib/arm-linux- ghc-7.10.2/text-1.2.1.3/libHStext-1.2.1.3-1l1AN4I48k37RaQ6fm6CEh.a(Unsafe.o) for Cortex-A8 erratum because it has no mapping symbols. /usr/bin/ld.gold: warning: cannot scan executable section 1 of /root/.cabal/lib/arm-linux- ghc-7.10.2/text-1.2.1.3/libHStext-1.2.1.3-1l1AN4I48k37RaQ6fm6CEh.a(Show.o) for Cortex-A8 erratum because it has no mapping symbols. }}} It compiles, just these warnings are quite painful, especially on real- world projects like the ones using yesod, there's just too much output like this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 9 11:53:02 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Sep 2015 11:53:02 -0000 Subject: [GHC] #10860: The test `setnumcapabilities001` sometimes fails on Phabricator Message-ID: <045.1b9d7e0fabda0a4b3797cc5dc85f2044@haskell.org> #10860: The test `setnumcapabilities001` sometimes fails on Phabricator -------------------------------------+------------------------------------- Reporter: thomie | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Runtime | Version: 7.10.2 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- {{{ setnumcapabilities001: internal error: ASSERTION FAILED: file rts/Schedule.c, line 406 }}} https://phabricator.haskell.org/harbormaster/build/5890/ Here it just timed out: https://phabricator.haskell.org/harbormaster/build/5904/?l=0 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 9 11:59:00 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Sep 2015 11:59:00 -0000 Subject: [GHC] #10860: The test `setnumcapabilities001` sometimes fails on Phabricator In-Reply-To: <045.1b9d7e0fabda0a4b3797cc5dc85f2044@haskell.org> References: <045.1b9d7e0fabda0a4b3797cc5dc85f2044@haskell.org> Message-ID: <060.f1db3fb1b6914b11d652dde609aefc48@haskell.org> #10860: The test `setnumcapabilities001` sometimes fails on Phabricator -------------------------------------+------------------------------------- Reporter: thomie | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"23a301ac36bb7e62bcf91bbcf0eb9e0e37498664/ghc" 23a301ac/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="23a301ac36bb7e62bcf91bbcf0eb9e0e37498664" Testsuite: comment out `setnumcapabilities001` (#10860) Don't mark it expect_broken, because it fails only sometimes. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 9 12:08:50 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Sep 2015 12:08:50 -0000 Subject: [GHC] #10841: Run handler on STM retry In-Reply-To: <045.10ea2aa941550aac6248eb677ce6a5a6@haskell.org> References: <045.10ea2aa941550aac6248eb677ce6a5a6@haskell.org> Message-ID: <060.920eb478a69a59d3be279bb20eef582f@haskell.org> #10841: Run handler on STM retry -------------------------------------+------------------------------------- Reporter: shlevy | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries | Version: 7.10.2 (other) | Resolution: | Keywords: stm Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by shlevy): fryguybob perhaps there's some confusion due to my calling it a "retry" handler? I don't mean merely to catch when the `retry` STM primitive is run, I also mean transaction aborts as simonpj mentioned. Unrelated to that: I realize now that my "try once" primitive won't work because there's no good way for the programmer to figure out when stm state has changed enough in other threads to be worth trying again, so the runtime does have to be in control of the looping. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 9 12:39:59 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Sep 2015 12:39:59 -0000 Subject: [GHC] #10845: Incorrect behavior when let binding implicit CallStack object In-Reply-To: <053.cff44270042de7bde1a56c8d798b5b0a@haskell.org> References: <053.cff44270042de7bde1a56c8d798b5b0a@haskell.org> Message-ID: <068.25565810296075ec86f971969c770f44@haskell.org> #10845: Incorrect behavior when let binding implicit CallStack object -------------------------------------+------------------------------------- Reporter: nitromaster101 | Owner: gridaphobe Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Eric, I see you've taken these implicit-call-stack tickets. Excellent, thank you. Please yell when you understand what is going on, and want to propose a solution. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 9 12:43:52 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Sep 2015 12:43:52 -0000 Subject: [GHC] #10824: Strict let-bindings are processed backwards In-Reply-To: <045.c0cfb865a77b8ab0d0da4471347445ce@haskell.org> References: <045.c0cfb865a77b8ab0d0da4471347445ce@haskell.org> Message-ID: <060.0e67e0eb9969fefa25872f974dcd2149@haskell.org> #10824: Strict let-bindings are processed backwards -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): I don't think we should offer any guarantee for what happens in this case. Our [http://research.microsoft.com/en-us/um/people/simonpj/papers /imprecise-exn.htm imprecise-exceptions paper] says why. I'm not against making the by-default behaviour a bit more intuitive but I don't think we should specify an evaluation order. So I suggest "invalid" here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 9 12:52:05 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Sep 2015 12:52:05 -0000 Subject: [GHC] #10861: `configure -C` yields different results on second run Message-ID: <045.93a4c030c09a570ec3b398fbe4906d19@haskell.org> #10861: `configure -C` yields different results on second run -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.10.2 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Autoconf has a feature to cache the results of a configure run (using `configure -C`), and use it in subsequent runs. It greatly speeds up those subsequent runs. * http://www.gnu.org/software/autoconf/manual/autoconf-2.66/html_node /Cache-Files.html#Cache-Files * http://www.gnu.org/software/autoconf/manual/autoconf-2.66/html_node /Caching-Results.html At least the `FP_GCC_VERSION` macro in aclocal.m4 is currently buggy. The call to AC_CACHE_CHECK should only set the cache variable (fp_cv_gcc_version), but it also sets others (GccLT34 and GccLT44) (side question: how do those interact with clang?). This means that subsequent runs of `configure -C` won't use the right values for GccLT34 and GccLT44, when your gcc is actually older than those. There are likely other bugs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 9 13:01:24 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Sep 2015 13:01:24 -0000 Subject: [GHC] #10842: "Reactive" Template Haskell In-Reply-To: <050.6f7bb562017372f9e5bba0241a40c1a7@haskell.org> References: <050.6f7bb562017372f9e5bba0241a40c1a7@haskell.org> Message-ID: <065.bec7705fc2d63ec73589954f157a70c9@haskell.org> #10842: "Reactive" Template Haskell -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 9699 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by dmcclean): Would this one allow you to cover most of your use cases without the "action at a distance" problem? https://ghc.haskell.org/trac/ghc/ticket/10391 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 9 13:09:53 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Sep 2015 13:09:53 -0000 Subject: [GHC] #10841: Run handler on STM retry In-Reply-To: <045.10ea2aa941550aac6248eb677ce6a5a6@haskell.org> References: <045.10ea2aa941550aac6248eb677ce6a5a6@haskell.org> Message-ID: <060.a3b8bc3536ed7e478bdfea7859a6cee6@haskell.org> #10841: Run handler on STM retry -------------------------------------+------------------------------------- Reporter: shlevy | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries | Version: 7.10.2 (other) | Resolution: | Keywords: stm Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by fryguybob): Yes, the terminology is confusing. There are things you can do inside the current STM to do this all at the user side (I didn't actually type check this): {{{#!hs atomicWithAbortPolicy :: Int -> IO (Maybe a) -> STM a -> IO a atomicWithAbortPolicy tryCount policy action = loop where loop :: IO a loop = do c <- newIORef 0 -- Thread local! res <- atomically $ do n <- unsafeIOToSTM $ readIORef c -- Thread local! if n > tryCount then return Nothing -- Commit transaction nothing in the read-set, so it will -- always succeed. else do unsafeIOToSTM $ writeIORef (n + 1) -- Thread local! Just <$> action case res of Just a -> return a -- action succeeded Nothing -> policy >>= \case Just a -> return a -- give up and return what policy gave. Nothing -> loop -- keep trying. }}} This is all completely safe as the `IORef` used never escapes. Actions on the `IORef` are always performed at the beginning of the transaction. This will also enforce the policy for `retry`, though you really want to make that decision before blocking. By wrapping `action` in `orElse` you can periodically commit `retry`ing transactions (discarding their effects) and run the policy outside of the transaction, loosing the more efficient wakeup. But if you have some `tryCount` you get the best of both by getting the efficient wakeup some of the time, then giving up and doing something else. I have heard that there was a paper that sort of settles the topic of contention management in TM, I will look it up and see what it says. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 9 13:09:59 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Sep 2015 13:09:59 -0000 Subject: [GHC] #10831: Document conditions on deriving Functor In-Reply-To: <048.8298ed09a98386a50539acd12ba36fa5@haskell.org> References: <048.8298ed09a98386a50539acd12ba36fa5@haskell.org> Message-ID: <063.c0c4b2970de6edf10d4cfd954e0a6901@haskell.org> #10831: Document conditions on deriving Functor -------------------------------------+------------------------------------- Reporter: htebalaka | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:3 simonpj]: > But I think we still lack a user-oriented specification, and such a thing would be tremendously welcome. What exactly would we want from a "user-oriented specification"? Do we want to see the compile-time error messages improved? Or do we want to see particular portions of the Commentary page and/or users' guide fleshed out? I'll admit that I didn't do a thorough job of how to follow along with `DeriveFunctor`'s many nuances as a newcomer to GHC in the Commentary page (I had the privilege of understanding it before I wrote it), so please point out specific parts that need work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 9 13:19:10 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Sep 2015 13:19:10 -0000 Subject: [GHC] #10841: Run handler on STM retry In-Reply-To: <045.10ea2aa941550aac6248eb677ce6a5a6@haskell.org> References: <045.10ea2aa941550aac6248eb677ce6a5a6@haskell.org> Message-ID: <060.c08e40a4d8c705ba74204709a9254108@haskell.org> #10841: Run handler on STM retry -------------------------------------+------------------------------------- Reporter: shlevy | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries | Version: 7.10.2 (other) | Resolution: | Keywords: stm Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Ha ha. That is truly horrible! Providing a decent API is what this ticket is really about. I seriously doubt that there is any automatic way to "settle" the topic of contention management, at least without programmer help. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 9 13:22:52 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Sep 2015 13:22:52 -0000 Subject: [GHC] #10841: Run handler on STM retry In-Reply-To: <045.10ea2aa941550aac6248eb677ce6a5a6@haskell.org> References: <045.10ea2aa941550aac6248eb677ce6a5a6@haskell.org> Message-ID: <060.b31731ddbf5939bc1de4cb1b73051893@haskell.org> #10841: Run handler on STM retry -------------------------------------+------------------------------------- Reporter: shlevy | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries | Version: 7.10.2 (other) | Resolution: | Keywords: stm Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by fryguybob): Indeed, I don't think contention management is always automatic, just what practices make it viable. There is a danger with serializing via some lock that all future executions will become serial once the lock is taken once. You certainly don't want users to have to write `atomicWithAbortPolicy`! Also note that what I gave above might not work in a system that supports partial aborts like Le and Fluet's ICFP paper: http://www.cs.rit.edu/~ml9951/icfp15.pdf But their work in a way avoids the problem by keeping more progress which might be enough to get longer transactions through anyway. The pathological case being where your long transaction has a long enough prefix that never has a conflict and is always available to restart from. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 9 13:56:24 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Sep 2015 13:56:24 -0000 Subject: [GHC] #10841: Run handler on STM retry In-Reply-To: <045.10ea2aa941550aac6248eb677ce6a5a6@haskell.org> References: <045.10ea2aa941550aac6248eb677ce6a5a6@haskell.org> Message-ID: <060.47fa5fa23d198392347e71577142d923@haskell.org> #10841: Run handler on STM retry -------------------------------------+------------------------------------- Reporter: shlevy | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries | Version: 7.10.2 (other) | Resolution: | Keywords: stm Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by fryguybob): The relevant paper is here: https://cs.rochester.edu/u/scott/papers/2009_PPoPP_CM.pdf I'll see what I can glean from it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 9 14:08:46 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Sep 2015 14:08:46 -0000 Subject: [GHC] #10494: Representational equalities over AppTys are not hard failures In-Reply-To: <047.6c55cf81fc9e307934dd2710cdafc698@haskell.org> References: <047.6c55cf81fc9e307934dd2710cdafc698@haskell.org> Message-ID: <062.c57b56a58cb84304c8ae592df9a1147c@haskell.org> #10494: Representational equalities over AppTys are not hard failures -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: merge Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T10494 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by crockeea): I'm about to release a package that triggers the bug, so it currently has crufty work-around code that I'd like to kill. I have a collection of functions that coerce functions of one signature to functions of another signature. Many of the definitions are simply `coerce`, but the explicit functions are needed for type inference. Here's an example: Instead of writing {{{ coerceBasis :: (Coercible (o r) (n m' r)) => Tagged '(m,m') ([o r]) -> Tagged m [n m' r] coerceBasis = coerce }}} I have to write {{{ coerceBasis :: (a ~ (o r), b ~ (n m' r), Coercible a b) => Tagged '(m,m') ([o r]) -> Tagged m [n m' r] coerceBasis = coerce }}} introducing two new intermediate type variables and constraints. Is this enough of a problem to make you go through the work of releasing 7.10.3 just for it? Certainly not. Mostly I was just unsure of the status of the patch and didn't want the original bug to be forgotten. That said, I *would* like it resolved sooner rather than later. I saw something on GHC-Devs about releasing builds, which makes a lot of sense to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 9 14:32:42 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Sep 2015 14:32:42 -0000 Subject: [GHC] #10745: Error in fusion when compiling Data.Yaml In-Reply-To: <046.37d8d5c0695542a7552f6e9c30a12ec8@haskell.org> References: <046.37d8d5c0695542a7552f6e9c30a12ec8@haskell.org> Message-ID: <061.e7b83e2afa7f382e91441109af333470@haskell.org> #10745: Error in fusion when compiling Data.Yaml ---------------------------------+----------------------------------------- Reporter: nclarke | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------+----------------------------------------- Comment (by nclarke): I didn't have the sandbox, but this issue has reappeared, so I've been able to build with -dppr-ticks: {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-linux): Tick in rule hpc hpc unstream @ a34_ay7l @ Void @ m_ay7j @ b_ay7k (ConduitWithStream @ a34_ay7l @ Void @ m_ay7j @ b_ay7k (let { $dApplicative_ay7r :: Applicative (ConduitM a34_ay7l Void m_ay7j) [LclId, Str=DmdType] $dApplicative_ay7r = $fApplicativeConduitM @ a34_ay7l @ Void @ m_ay7j ($fFunctorConduitM @ a34_ay7l @ Void @ m_ay7j) } in letrec { loop_ay7s :: b_ay7k -> ConduitM a34_ay7l Void m_ay7j b_ay7k [LclId, Arity=1, Str=DmdType] loop_ay7s = \ (accum_ay7t :: b_ay7k) -> hpc hpc hpc $fMonadConduitM_$c>>= @ a34_ay7l @ Void @ m_ay7j $dApplicative_ay7r @ (Maybe a34_ay7l) @ b_ay7k ((hpc await @ a34_ay7l @ m_ay7j $dMonad1_ay7n) @ Void) (hpc maybe @ (ConduitM a34_ay7l Void m_ay7j b_ay7k) @ a34_ay7l (hpc $fMonadConduitM_$creturn @ a34_ay7l @ Void @ m_ay7j $dApplicative_ay7r @ b_ay7k (hpc accum_ay7t)) (hpc \ (a35_ay7u :: a34_ay7l) -> hpc hpc $fMonadConduitM_$c>>= @ a34_ay7l @ Void @ m_ay7j $dApplicative_ay7r @ b_ay7k @ b_ay7k (hpc $ @ (m_ay7j b_ay7k) @ (ConduitM a34_ay7l Void m_ay7j b_ay7k) (hpc $fMonadBasebaseConduitM_$clift @ a34_ay7l @ Void @ m_ay7j @ b_ay7k $dMonad1_ay7n) (hpc f_ay7p (hpc accum_ay7t) (hpc a35_ay7u))) (\ (accum'_ay7v :: b_ay7k) -> hpc hpc case accum'_ay7v of wild_ay7w { __DEFAULT -> hpc loop_ay7s (hpc wild_ay7w) }))); } in hpc hpc loop_ay7s b1_ay7q) (foldMS @ b_ay7k @ a34_ay7l @ m_ay7j $dMonad1_ay7n f_ay7p b1_ay7q @ Void)) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 9 15:32:19 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Sep 2015 15:32:19 -0000 Subject: [GHC] #10672: GHCi linker does not understand C++ exception tables on Windows In-Reply-To: <045.04cee7c60b130b0ccc29791ed61c4f5f@haskell.org> References: <045.04cee7c60b130b0ccc29791ed61c4f5f@haskell.org> Message-ID: <060.d6a32d00695622cfba0107d0c669692d@haskell.org> #10672: GHCi linker does not understand C++ exception tables on Windows -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Phyx- Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: Runtime System | Version: 7.10.1 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #9297 #10563 | Differential Revisions: #8237 #9907 | -------------------------------------+------------------------------------- Comment (by Phyx-): @lukexi You can find the work in progress code at https://github.com/Mistuke/ghc/tree/rework-windows-pe-linker it should already fix the problem reported here (at least the code compiles and runs and prints three lines). I've only tested it for x86_64 so far. I'll be making a few other changes and test x86 before sending this out for review :) I will keep the branch on GitHub up-to-date. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 9 15:47:45 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Sep 2015 15:47:45 -0000 Subject: [GHC] #10862: No way to exclude current directory from search path Message-ID: <046.896446a44757716ea085cdf95c0a86ea@haskell.org> #10862: No way to exclude current directory from search path -------------------------------------+------------------------------------- Reporter: literon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Having Main.hs in the current directory, executing ghc --make Main -i still compiles the module, even though -i should in theory "reset the search path back to nothing". But it seems nothing ~ the default (current dir). I would propose to either change the behavior, or add a new flag, in order to be able to better control the build environment. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 9 16:04:24 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Sep 2015 16:04:24 -0000 Subject: [GHC] #8524: GHC is inconsistent with the Haskell Report on which Unicode characters are allowed in string and character literals In-Reply-To: <045.aa22727e9338664a3617f731b2d178cd@haskell.org> References: <045.aa22727e9338664a3617f731b2d178cd@haskell.org> Message-ID: <060.0e15cebe6457cfd2544b991db31626dd@haskell.org> #8524: GHC is inconsistent with the Haskell Report on which Unicode characters are allowed in string and character literals -------------------------------------+------------------------------------- Reporter: oerjan | Owner: | RyanGlScott Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.6.3 (Parser) | Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1235 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * owner: => RyanGlScott * differential: => Phab:D1235 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 9 16:21:27 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Sep 2015 16:21:27 -0000 Subject: [GHC] #9825: ghc "panic! (the 'impossible' happened)" building vimus on NixOS In-Reply-To: <047.e4f44909e905adacb4005302519ba187@haskell.org> References: <047.e4f44909e905adacb4005302519ba187@haskell.org> Message-ID: <062.9b682e46345b154bd7faf1f5a9404123@haskell.org> #9825: ghc "panic! (the 'impossible' happened)" building vimus on NixOS -------------------------------------+------------------------------------- Reporter: jzellner | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.3 (Linker) | Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Compile-time | Test Case: crash | Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): I didn't investigate the specifics of the case in this ticket but your theory sounds 100% plausible. See #10761 for another example of the same phenomenon. x86_64 Linux has lazy symbol resolution by default too. I guess x86 Linux must differ in some detail, either in GHC or in the way dynamic linking works. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 9 16:37:44 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Sep 2015 16:37:44 -0000 Subject: [GHC] #8524: GHC is inconsistent with the Haskell Report on which Unicode characters are allowed in string and character literals In-Reply-To: <045.aa22727e9338664a3617f731b2d178cd@haskell.org> References: <045.aa22727e9338664a3617f731b2d178cd@haskell.org> Message-ID: <060.677dd08a9156d985214f631cf9ff76bb@haskell.org> #8524: GHC is inconsistent with the Haskell Report on which Unicode characters are allowed in string and character literals -------------------------------------+------------------------------------- Reporter: oerjan | Owner: | RyanGlScott Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.6.3 (Parser) | Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1235 -------------------------------------+------------------------------------- Comment (by rwbarton): My "Me" column would go Dunno, Yes, Yes. Particularly for the second case (Space/uniWhite in string), I don't see how allowing it would cause much harm and there may well be people using this behavior already. Maybe it would be better to just document this deviation from the Report? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 9 21:41:13 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Sep 2015 21:41:13 -0000 Subject: [GHC] #8258: GHC accepts `data Foo where` in H2010 mode In-Reply-To: <042.7ae0b1be303dde5e66c52f6566614572@haskell.org> References: <042.7ae0b1be303dde5e66c52f6566614572@haskell.org> Message-ID: <057.6fd1c5f66acf384c9ae4726c4b0d28e0@haskell.org> #8258: GHC accepts `data Foo where` in H2010 mode -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: low | Milestone: 7.12.1 Component: Compiler | Version: 7.0.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by siddhanathan): Should a trailing `where` be considered legal? For example, the following is valid: {{{ c = 5 where a = 5 where b = 5 }}} And the code above will be parsed as: {{{ ==================== Parser ==================== c = 5 a = 5 where b = 5 }}} But the trailing `where` after `c = 5` was probably accidental. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 9 21:58:01 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Sep 2015 21:58:01 -0000 Subject: [GHC] #10848: GHC/GHCi should optionally print errors in reversed order In-Reply-To: <043.346863bae2dced560ac8325c22b2fccb@haskell.org> References: <043.346863bae2dced560ac8325c22b2fccb@haskell.org> Message-ID: <058.6bca322473616d21f957d1e987edbba4@haskell.org> #10848: GHC/GHCi should optionally print errors in reversed order -------------------------------------+------------------------------------- Reporter: osa1 | Owner: | siddhanathan Type: feature request | Status: new Priority: lowest | Milestone: Component: GHCi | Version: 7.11 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by siddhanathan): * owner: => siddhanathan -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 9 23:22:05 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Sep 2015 23:22:05 -0000 Subject: [GHC] #10863: "hello world" produces illegal instruction error Message-ID: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> #10863: "hello world" produces illegal instruction error -----------------------------------+---------------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Linux Architecture: arm | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -----------------------------------+---------------------------------- I saw there was a new debian experimental package for 7.10.2, so I installed it on my raspberry pi 2, an arm v7 computer running debian jessie. Someone on twitter had some success with the package, but it didn't work for me. https://packages.debian.org/experimental/armhf/ghc/download See the attached file for versions of things, and test results. This is similar to another attempt where I installed the 7.10.2 binary available from the ghc website. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 9 23:22:43 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Sep 2015 23:22:43 -0000 Subject: [GHC] #10863: "hello world" produces illegal instruction error In-Reply-To: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> References: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> Message-ID: <061.e06d444543e6148f2213a5b611851c63@haskell.org> #10863: "hello world" produces illegal instruction error ----------------------------------+--------------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------+--------------------------------- Changes (by Ansible): * Attachment "install_log" added. install and test of ghc 7.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 9 23:23:32 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Sep 2015 23:23:32 -0000 Subject: [GHC] #10863: "hello world" produces illegal instruction error In-Reply-To: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> References: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> Message-ID: <061.725b3eca2171cf712ba11a021199c45c@haskell.org> #10863: "hello world" produces illegal instruction error ----------------------------------+--------------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------+--------------------------------- Changes (by Ansible): * Attachment "cpuinfo" added. /proc/cpuinfo -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 9 23:25:08 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Sep 2015 23:25:08 -0000 Subject: [GHC] #10863: "hello world" produces illegal instruction error In-Reply-To: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> References: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> Message-ID: <061.cc1b1700fe65c833c09ed75dcfb3e0fe@haskell.org> #10863: "hello world" produces illegal instruction error ----------------------------------+--------------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------+--------------------------------- Changes (by Ansible): * Attachment "ghcinfo" added. ghc --info -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 9 23:37:55 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Sep 2015 23:37:55 -0000 Subject: [GHC] #8405: experiment with using function-sections for linking (for smaller libs and executables) In-Reply-To: <045.ff128453c9ddce6d07b91486f573635a@haskell.org> References: <045.ff128453c9ddce6d07b91486f573635a@haskell.org> Message-ID: <060.f7208127adb91be14564689fc58b0b58@haskell.org> #8405: experiment with using function-sections for linking (for smaller libs and executables) -------------------------------------+------------------------------------- Reporter: carter | Owner: olsner Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by olsner): * owner: => olsner Comment: It seems GNU ld actually has scalability issues with very large numbers of sections too, unfortunately. Found out because I was building libHSghc with split sections, and getting 10 minute link times on some test cases with plugins linking statically against ghc... Since split-objs is specifically disabled for that code I simply disabled split-sections as well. A much cleaned up version of the patch now at https://github.com/olsner/ghc/commits/function-sections-2 - this adds a -split-sections flag that controls the splitting when compiling Haskell code. --gc-sections is always added to the linker command line. (Vague rationale being that after building libraries with split sections, we'll want to bring space savings to users without manual steps or extra flags building their programs/libraries.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 10 00:10:18 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Sep 2015 00:10:18 -0000 Subject: [GHC] #10864: arm: strange closure type 64008 from cabal-install Message-ID: <048.6229c44b2e93186b58e67744c7d1c1ed@haskell.org> #10864: arm: strange closure type 64008 from cabal-install ------------------------------------+---------------------------------- Reporter: muhmuhten | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Linux Architecture: arm | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ------------------------------------+---------------------------------- This is occurring on fedora 22 with ghc and cabal-install directly from the repos; I haven't checked whether the bug is actually downstream. {{{ # dnf install -y cabal-install $ cabal sandbox init cabal: internal error: evacuate(static): strange closure type 65200 (GHC version 7.8.4 for arm_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) $ cabal update Downloading the latest package list from hackage.haskell.org cabal: internal error: evacuate(static): strange closure type 64008 (GHC version 7.8.4 for arm_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 10 05:37:42 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Sep 2015 05:37:42 -0000 Subject: [GHC] #4426: Simplify the rules for implicit quantification In-Reply-To: <046.cc2650d075f9bec123108fe76360a0e2@haskell.org> References: <046.cc2650d075f9bec123108fe76360a0e2@haskell.org> Message-ID: <061.5638ffefede2b82f7cc4111a0f96d435@haskell.org> #4426: Simplify the rules for implicit quantification -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: highest | Milestone: 7.12.1 Component: Compiler | Version: 6.12.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7880 | Differential Revisions: Phab:D211 -------------------------------------+------------------------------------- Comment (by kanetw): Is anyone working on the changes Simon mentioned? Otherwise I'll go ahead and implement them. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 10 09:32:45 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Sep 2015 09:32:45 -0000 Subject: [GHC] #8405: experiment with using function-sections for linking (for smaller libs and executables) In-Reply-To: <045.ff128453c9ddce6d07b91486f573635a@haskell.org> References: <045.ff128453c9ddce6d07b91486f573635a@haskell.org> Message-ID: <060.2d6860efce558911079325558d5e1f5b@haskell.org> #8405: experiment with using function-sections for linking (for smaller libs and executables) -------------------------------------+------------------------------------- Reporter: carter | Owner: olsner Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by refold): Replying to [comment:11 olsner]: > It seems GNU ld actually has scalability issues with very large numbers of sections too, unfortunately. Have you tried the gold linker? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 10 10:08:04 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Sep 2015 10:08:04 -0000 Subject: [GHC] #10365: Make Semigroup as a superclass of Monoid In-Reply-To: <044.91d55a6870e3dd391fca3990f924a9d5@haskell.org> References: <044.91d55a6870e3dd391fca3990f924a9d5@haskell.org> Message-ID: <059.2d92b75082137e84cb9d7f488782f250@haskell.org> #10365: Make Semigroup as a superclass of Monoid -------------------------------------+------------------------------------- Reporter: gidyn | Owner: ekmett Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): And `Data.List.NonEmpty` will be added, according to this [https://www.reddit.com/r/haskell/comments/3ipsc6/ghc_712_release_plan/cuk8dvl reddit comment by ekmett]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 10 12:12:24 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Sep 2015 12:12:24 -0000 Subject: [GHC] #10365: Make Semigroup as a superclass of Monoid In-Reply-To: <044.91d55a6870e3dd391fca3990f924a9d5@haskell.org> References: <044.91d55a6870e3dd391fca3990f924a9d5@haskell.org> Message-ID: <059.aad811e12b75464645f41b7ddb3b4b4c@haskell.org> #10365: Make Semigroup as a superclass of Monoid -------------------------------------+------------------------------------- Reporter: gidyn | Owner: ekmett Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bergmark): * cc: bergmark (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 10 12:20:28 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Sep 2015 12:20:28 -0000 Subject: [GHC] #8258: GHC accepts `data Foo where` in H2010 mode In-Reply-To: <042.7ae0b1be303dde5e66c52f6566614572@haskell.org> References: <042.7ae0b1be303dde5e66c52f6566614572@haskell.org> Message-ID: <057.4a3ab45a448bd7dcd3c4a6fdd3a058b4@haskell.org> #8258: GHC accepts `data Foo where` in H2010 mode -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: low | Milestone: 7.12.1 Component: Compiler | Version: 7.0.4 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * component: Compiler => Compiler (Parser) Comment: `c = 5 where` is ok. From https://www.haskell.org/onlinereport/haskell2010/haskellch4.html: {{{ decl ? (funlhs | pat) rhs rhs ? = exp [where decls] decls ? { decl1 ; ? ; decln } (n ? 0) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 10 12:53:58 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Sep 2015 12:53:58 -0000 Subject: [GHC] #10365: Make Semigroup as a superclass of Monoid (Phase 1) (was: Make Semigroup as a superclass of Monoid) In-Reply-To: <044.91d55a6870e3dd391fca3990f924a9d5@haskell.org> References: <044.91d55a6870e3dd391fca3990f924a9d5@haskell.org> Message-ID: <059.aa990340a49624e4699a262ecfd92866@haskell.org> #10365: Make Semigroup as a superclass of Monoid (Phase 1) -------------------------------------+------------------------------------- Reporter: gidyn | Owner: ekmett Type: feature request | Status: new Priority: high | Milestone: 7.12.1 Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: report- | impact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * keywords: => report-impact * priority: normal => high * milestone: => 7.12.1 Old description: > See http://haskell.1045720.n5.nabble.com/Proposal-Make-Semigroup-as-a > -superclass-of-Monoid-td5767835.html New description: Last proposed in http://thread.gmane.org/gmane.comp.lang.haskell.libraries/24494 === Phase 1 (GHC 7.12) Phase 1 consists in (at the very least) moving `Data.Semigroup` and `Data.List.NonEmpty` into `base` for GHC 7.12 (aka 8.0). If there's enough time we will also implement a warning as part of the first phase: > Add a warning about definitions of an operator named `(<>)` that indicate it will be coming into Prelude in 7.14. We should warn about missing Semigroup instances at any use site of `(<>)` as they'll break in 7.14. The rest of the migration roadmap is outlined in http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/24526 -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 10 14:05:32 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Sep 2015 14:05:32 -0000 Subject: [GHC] #10682: AArch64: dll-split: out of memory (requested 1099512676352 bytes) In-Reply-To: <044.b28ef9f55aa85f3be9d617cd7c0f70a5@haskell.org> References: <044.b28ef9f55aa85f3be9d617cd7c0f70a5@haskell.org> Message-ID: <059.736e97e884bac050fc89a59e9117173c@haskell.org> #10682: AArch64: dll-split: out of memory (requested 1099512676352 bytes) -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1171 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 10 14:12:55 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Sep 2015 14:12:55 -0000 Subject: [GHC] #10865: Poly-kinded Const Message-ID: <048.9e286d630268edb801227c2f20a8ad8a@haskell.org> #10865: Poly-kinded Const -------------------------------------+------------------------------------- Reporter: int-index | Owner: ekmett Type: feature | Status: new request | Priority: normal | Milestone: Component: Core | Version: 7.10.2 Libraries | Keywords: poly- | Operating System: Unknown/Multiple kinded, Const | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Currently `Const` is defined as {{{ newtype Const a b = Const { getConst :: a } }}} I propose to define it poly-kinded in the second argument like so: {{{ newtype Const a (b :: k) = Const { getConst :: a } }}} This should be completely backwards-compatible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 10 14:28:39 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Sep 2015 14:28:39 -0000 Subject: [GHC] #10865: Poly-kinded Const In-Reply-To: <048.9e286d630268edb801227c2f20a8ad8a@haskell.org> References: <048.9e286d630268edb801227c2f20a8ad8a@haskell.org> Message-ID: <063.d9b5e92fa9f67eb740af9ee79cb7492f@haskell.org> #10865: Poly-kinded Const -------------------------------------+------------------------------------- Reporter: int-index | Owner: ekmett Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.2 Resolution: | Keywords: poly- | kinded, Const Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Simply enabling `-XPolyKinds` in the defining module should do the trick. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 10 15:34:29 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Sep 2015 15:34:29 -0000 Subject: [GHC] #10428: GHC cannot match representations using Coercible constraint In-Reply-To: <047.fbead4304e2da30bbf57add55471b5d0@haskell.org> References: <047.fbead4304e2da30bbf57add55471b5d0@haskell.org> Message-ID: <062.c83019c545ec55362bc12b5116afe2b3@haskell.org> #10428: GHC cannot match representations using Coercible constraint -------------------------------------+------------------------------------- Reporter: crockeea | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T10428 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by George): There was a question in email as to whether or not the fix is in 7.10.2. I just tried on 7.10.2 and get the same error so it seems it is not in 7.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 10 18:39:52 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Sep 2015 18:39:52 -0000 Subject: [GHC] #9043: Add missing type class instances for data types in GHC.Generics In-Reply-To: <047.559a569dcd60e85eae168b55411f2520@haskell.org> References: <047.559a569dcd60e85eae168b55411f2520@haskell.org> Message-ID: <062.731525ff24a505f56659c82ec0100d73@haskell.org> #9043: Add missing type class instances for data types in GHC.Generics -------------------------------------+------------------------------------- Reporter: ocharles | Owner: dreixel Type: feature request | Status: infoneeded Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 9766 | Blocking: Related Tickets: #8778 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 10 19:00:33 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Sep 2015 19:00:33 -0000 Subject: [GHC] #8830: internal error: Misaligned section: 18206e5b on Windows In-Reply-To: <047.c72974f625aa2960800193f6a0ae2799@haskell.org> References: <047.c72974f625aa2960800193f6a0ae2799@haskell.org> Message-ID: <062.d6c10321e16b1aa1349b0916308c632b@haskell.org> #8830: internal error: Misaligned section: 18206e5b on Windows -------------------------------+------------------------------------- Reporter: joeyhess | Owner: Type: bug | Status: infoneeded Priority: lowest | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+------------------------------------- Comment (by Phyx-): @joeyhess Do you have a reproducible case for this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 10 19:15:32 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Sep 2015 19:15:32 -0000 Subject: [GHC] #7687: ghc panic on TH and deriveJSON In-Reply-To: <044.a32c208c745370fae93ea4e1da30c72b@haskell.org> References: <044.a32c208c745370fae93ea4e1da30c72b@haskell.org> Message-ID: <059.fe7f205cd32bcd001c929f29fe821331@haskell.org> #7687: ghc panic on TH and deriveJSON -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 7.4.2 Resolution: | Keywords: TH Operating System: Windows | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: 3658 | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => infoneeded Comment: I get the same error @George got. So something changed in aeson and/or hashable. I'll mark this as info needed as two people couldn't reproduce it on a newer GHC -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 10 19:28:44 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Sep 2015 19:28:44 -0000 Subject: [GHC] #10866: Big discovered while installing stack. Message-ID: <053.a74a5b4da5772c7a83c79353fa3c332b@haskell.org> #10866: Big discovered while installing stack. -------------------------------------+------------------------------------- Reporter: | Owner: MichaelOChurch | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: MacOS X Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Below is a dump of the output while trying to build and install stack. Console output told me to report as a GHC bug, so that's what I'm doing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 10 19:29:15 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Sep 2015 19:29:15 -0000 Subject: [GHC] #10866: Big discovered while installing stack. In-Reply-To: <053.a74a5b4da5772c7a83c79353fa3c332b@haskell.org> References: <053.a74a5b4da5772c7a83c79353fa3c332b@haskell.org> Message-ID: <068.51bbd448e43f8c39497ad7d2941b3c37@haskell.org> #10866: Big discovered while installing stack. -------------------------------------+------------------------------------- Reporter: MichaelOChurch | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by MichaelOChurch): * Attachment "ghcbug.txt" added. Console dump while trying to install stack using Cabal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 10 19:32:55 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Sep 2015 19:32:55 -0000 Subject: [GHC] #10866: Big discovered while installing stack. In-Reply-To: <053.a74a5b4da5772c7a83c79353fa3c332b@haskell.org> References: <053.a74a5b4da5772c7a83c79353fa3c332b@haskell.org> Message-ID: <068.376cf61f36109cdf070a7c36ceb513e3@haskell.org> #10866: Big discovered while installing stack. -------------------------------------+------------------------------------- Reporter: MichaelOChurch | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by MichaelOChurch): * status: new => closed * resolution: => fixed Comment: On further inspection, this appears to be an already known bug: https://ghc.haskell.org/trac/ghc/ticket/10322 Disregard. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 11 00:36:21 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Sep 2015 00:36:21 -0000 Subject: [GHC] #367: Infinite loops can hang Concurrent Haskell In-Reply-To: <046.5a2b87104f229d7899f0f85ea5bfdf9e@haskell.org> References: <046.5a2b87104f229d7899f0f85ea5bfdf9e@haskell.org> Message-ID: <061.d01f6b2d3c93d69f625d7f6b5574252b@haskell.org> #367: Infinite loops can hang Concurrent Haskell -------------------------------------+------------------------------------- Reporter: simonpj | Owner: ezyang Type: bug | Status: new Priority: lowest | Milestone: ? Component: Compiler | Version: 6.4.1 Resolution: None | Keywords: scheduler | allocation Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | concurrent/should_run/T367, | concurrent/should_run/T367_letnoescape Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by fryguybob): I thought I had left a note here before, but it appears that I have not! In my work with hardware transactions we run into this when working with lots of cores on an STM red-black tree. When some thread A performs a rotation while another thread B is searching through the rotated node thread B can enter a non-allocating infinite loop due to seeing an inconsistent view of memory. I think that hardware transactions make this occur more frequently, but there is nothing about the STM that prevents this. We always build with `-fno-omit-yields` now and do not see any issues. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 11 00:38:33 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Sep 2015 00:38:33 -0000 Subject: [GHC] #10857: "ghci -XMonomorphismRestriction" doesn't turn on the monomorphism restriction In-Reply-To: <047.0bca38b39289a4db2d373be62522bc3d@haskell.org> References: <047.0bca38b39289a4db2d373be62522bc3d@haskell.org> Message-ID: <062.3b6164ecefe67239fef8ded34c6c07f1@haskell.org> #10857: "ghci -XMonomorphismRestriction" doesn't turn on the monomorphism restriction -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #3202, #3217 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * related: => #3202, #3217 Comment: `ghci -XNoExtendedDefaultRules` does't turn off `ExtendedDefaultRules` either: {{{ Prelude> :showi language base language is: Haskell2010 with the following modifiers: -XNoDatatypeContexts -XExtendedDefaultRules -XNoMonomorphismRestriction -XNondecreasingIndentation }}} This seems to be by design. From https://ghc.haskell.org/trac/ghc/ticket/3217#comment:15: The DynFlags used to compile code will be computed as follows. ... When compiling an expression typed on the GHCi command line: * Start with the baseline DynFlags * Apply flags specified on the original command-line * (Perhaps: apply flags specified by :set in this GHCi session. We aren't sure whether or not to do this.) * Apply GHCi baseline command-prompt flags (e.g. special defaulting rules) * Apply flags specified by :seti in this GHCi session * If there is a fully-open module M, apply flags specified in M itself. That is, flags in M get the last word. I agree it is confusing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 11 01:22:50 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Sep 2015 01:22:50 -0000 Subject: [GHC] #10375: arm: ghci hits an illegal instruction In-Reply-To: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> References: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> Message-ID: <059.55efc78911ede2ac3c835d3aeb411736@haskell.org> #10375: arm: ghci hits an illegal instruction -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: Runtime System | Version: 7.10.1 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by erikd): * component: GHCi => Runtime System (Linker) Comment: All the previous debugging had produced confusing, contradictory and un- repeatable results so I dropped back to simple wolf-fence debugging with `putStrLn` and over about 3 hours managed to narrow this down to the function `GhciMonad.turnOffBuffering`. Modifying that function as follows: {{{ turnOffBuffering :: IO () turnOffBuffering = do putStrLn "turnOffBuffering start" hdls <- mapM getHandle [stdin_ptr,stdout_ptr,stderr_ptr] putStrLn "turnOffBuffering middle" mapM_ (\h -> hSetBuffering h NoBuffering) hdls putStrLn "turnOffBuffering end" }}} and running the previous test results in: {{{ GHCi, version 7.11.20150910: http://www.haskell.org/ghc/ :? for help turnOffBuffering start turnOffBuffering middle Illegal instruction }}} so that it seems that calling `hSetBuffering` causes the crash. However, `hSetBuffering` is not the problem. Rather, `hSetBuffering` is the first function to be run from the `Base` package which is loaded with the runtime linker. Seeing this reminded me of #2972 which was a linker problem, so modifying the "Component" field of this ticket to reflect that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 11 02:12:22 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Sep 2015 02:12:22 -0000 Subject: [GHC] #10375: arm: ghci hits an illegal instruction In-Reply-To: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> References: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> Message-ID: <059.a0c202adf88801dd0e92b18c7f08432d@haskell.org> #10375: arm: ghci hits an illegal instruction -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: Runtime System | Version: 7.10.1 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by erikd): Readig more from #2972, I see that all the comments about PowerPC being limited to 24 bit offsets for relative branch instructions should also apply to Arm. However, enabling `USE_CONTIGUOUS_MMAP` in `rts/linker.c` for `arm_HOST_ARCH` as well as `powerpc_HOST_ARCH` doesn't fix this issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 11 07:18:21 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Sep 2015 07:18:21 -0000 Subject: [GHC] #10365: Implement Semigroup as a superclass of Monoid Proposal (Phase 1) (was: Make Semigroup as a superclass of Monoid (Phase 1)) In-Reply-To: <044.91d55a6870e3dd391fca3990f924a9d5@haskell.org> References: <044.91d55a6870e3dd391fca3990f924a9d5@haskell.org> Message-ID: <059.8a2853d072a604fe610a3f6edad7435c@haskell.org> #10365: Implement Semigroup as a superclass of Monoid Proposal (Phase 1) -------------------------------------+------------------------------------- Reporter: gidyn | Owner: ekmett Type: feature request | Status: new Priority: high | Milestone: 7.12.1 Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: report- | impact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Old description: > Last proposed in > http://thread.gmane.org/gmane.comp.lang.haskell.libraries/24494 > > === Phase 1 (GHC 7.12) > > Phase 1 consists in (at the very least) moving `Data.Semigroup` and > `Data.List.NonEmpty` into `base` for GHC 7.12 (aka 8.0). > > If there's enough time we will also implement a warning as part of the > first phase: > > > Add a warning about definitions of an operator named `(<>)` that > indicate it will be coming into Prelude in 7.14. We should warn about > missing Semigroup instances at any use site of `(<>)` as they'll break in > 7.14. > > The rest of the migration roadmap is outlined in > http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/24526 New description: More details in Proposal/SemigroupMonoid === Phase 1 (GHC 7.12) Phase 1 consists in (at the very least) moving `Data.Semigroup` and `Data.List.NonEmpty` into `base` for GHC 7.12 (aka 8.0). If there's enough time we will also implement a warning as part of the first phase: > Add a warning about definitions of an operator named `(<>)` that indicate it will be coming into Prelude in 7.14. We should warn about missing Semigroup instances at any use site of `(<>)` as they'll break in 7.14. -- Comment (by hvr): added link to new Proposal/SemigroupMonoid wiki page (still a draft) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 11 07:42:29 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Sep 2015 07:42:29 -0000 Subject: [GHC] #10857: "ghci -XMonomorphismRestriction" doesn't turn on the monomorphism restriction In-Reply-To: <047.0bca38b39289a4db2d373be62522bc3d@haskell.org> References: <047.0bca38b39289a4db2d373be62522bc3d@haskell.org> Message-ID: <062.6e6d5a5857d504b55161c4345e316cb3@haskell.org> #10857: "ghci -XMonomorphismRestriction" doesn't turn on the monomorphism restriction -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #3202, #3217 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): That ''is'' confusing! What about putting (4) immediately after (1), so that it can be modified by command line or :set commands? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 11 08:41:56 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Sep 2015 08:41:56 -0000 Subject: [GHC] #10623: Handling of ASCII encodings introduced in D898 breaks Unicode terminal detection In-Reply-To: <046.3a764cfd54e5a4e4443ef4864c8fddbf@haskell.org> References: <046.3a764cfd54e5a4e4443ef4864c8fddbf@haskell.org> Message-ID: <061.30daf513205115a372c82baa82c45cbc@haskell.org> #10623: Handling of ASCII encodings introduced in D898 breaks Unicode terminal detection -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T8958a Blocked By: | Blocking: Related Tickets: #10298, #7695 | Differential Revisions: | Phab:D1059, Phab:D1085 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: 7.10.2 => 7.10.3 Comment: Moving out to 7.10.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 11 08:42:43 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Sep 2015 08:42:43 -0000 Subject: [GHC] #9637: Type level programming needs an error function In-Reply-To: <047.3309ef9af8755e67dc24602c9e6ec77f@haskell.org> References: <047.3309ef9af8755e67dc24602c9e6ec77f@haskell.org> Message-ID: <062.180be731b7289c055e6f3f8247ca92d7@haskell.org> #9637: Type level programming needs an error function -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9180, #9636 | Differential Revisions: Phab:D1236 -------------------------------------+------------------------------------- Changes (by simonpj): * differential: => Phab:D1236 Old description: > When doing type level programming you often need a way to report errors. > I suggest a closed type family called Error with special semantics. > It is kinded like this Error :: Symbol -> k1 -> k2 > > If this function has to be reduced during constraint solving it will > simply generate a type error with the given string and printing the type > as extra information (this kind can be generalized a lot if we want to). > > I've found that having this function gives more accurate and earlier > error messages. New description: When doing type level programming you often need a way to report errors. I suggest a closed type family called Error with special semantics. It is kinded like this Error :: Symbol -> k1 -> k2 If this function has to be reduced during constraint solving it will simply generate a type error with the given string and printing the type as extra information (this kind can be generalized a lot if we want to). I've found that having this function gives more accurate and earlier error messages. Wiki design page: [wiki:CustomTypeErros] -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 11 08:43:58 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Sep 2015 08:43:58 -0000 Subject: [GHC] #9907: "Unknown PEi386 section name `.text$printf'" error in GHCi on Windows In-Reply-To: <051.9bd9875fb01e6198fe81abe3cec3e53a@haskell.org> References: <051.9bd9875fb01e6198fe81abe3cec3e53a@haskell.org> Message-ID: <066.aa2bd23bf42a8ef2f98d37f27883a281@haskell.org> #9907: "Unknown PEi386 section name `.text$printf'" error in GHCi on Windows -------------------------------------+------------------------------------- Reporter: mmikolajczyk | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 7.10.3 Component: GHCi | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #7103, #10051, | Differential Revisions: Phab:D671 #7056, #8546 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: 7.10.1 => 7.10.3 Comment: Moving to 7.10.3, in case there's a fix. Thanks Phyx-! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 11 08:44:41 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Sep 2015 08:44:41 -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.1f79703b060cd9c6fead66fdeac40569@haskell.org> #9878: Static pointers in GHCi cause panic -------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D586 | Phab:D587 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: 7.10.1 => 7.10.3 Comment: Moving to 7.10.3 as it causes a bug on Windows. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 11 08:46:18 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Sep 2015 08:46:18 -0000 Subject: [GHC] #9646: Simplifer non-determinism leading to 8 fold difference in run time performance In-Reply-To: <044.91d1be288ff53f5ea138a0b071967333@haskell.org> References: <044.91d1be288ff53f5ea138a0b071967333@haskell.org> Message-ID: <059.39075ed783b6efa46f7066bf117a256a@haskell.org> #9646: Simplifer non-determinism leading to 8 fold difference in run time performance -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.3 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: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: 7.10.1 => 7.10.3 Comment: Moving to 7.10.3 - would be nice to fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 11 08:46:55 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Sep 2015 08:46:55 -0000 Subject: [GHC] #9058: System.IO.openTempFile does not scale In-Reply-To: <045.41fdb1eece4d843bb1a26f72af3a8a36@haskell.org> References: <045.41fdb1eece4d843bb1a26f72af3a8a36@haskell.org> Message-ID: <060.4a4273bf6f0c39e963b358ebff345c7a@haskell.org> #9058: System.IO.openTempFile does not scale -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: 7.10.1 => 8.0.1 Comment: Moving to 8.0.1 (since the semantics aren't going to change in a minor point release). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 11 08:47:36 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Sep 2015 08:47:36 -0000 Subject: [GHC] #1407: Add the ability to :set -l{foo} in .ghci files In-Reply-To: <044.ced6846230ff2e238418885a3d68ddd9@haskell.org> References: <044.ced6846230ff2e238418885a3d68ddd9@haskell.org> Message-ID: <059.69150a027f5e1a769e6a2104a2d03b51@haskell.org> #1407: Add the ability to :set -l{foo} in .ghci files -------------------------------------+------------------------------------- Reporter: guest | Owner: archblob Type: feature request | Status: new Priority: normal | Milestone: 7.10.3 Component: GHCi | Version: 6.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D194 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: 7.10.1 => 7.10.3 Comment: Moving to 7.10.3, in case we want to investigate this, since it causes some failures. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 11 08:49:20 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Sep 2015 08:49:20 -0000 Subject: [GHC] #7830: Error: operand out of range In-Reply-To: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> References: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> Message-ID: <059.a51911d0f7b7ffb4912e6dd5749cdfde@haskell.org> #7830: Error: operand out of range -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Installing GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: 7.8.1 => 8.0.1 Comment: Moving to 8.0.1 (since presumably we won't fix this in the 7.8 branch :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 11 08:49:58 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Sep 2015 08:49:58 -0000 Subject: [GHC] #7482: GHC.Event overwrites main IO managers hooks to RTS In-Reply-To: <053.8265638cb53ac37cc1aae74a0afb4d97@haskell.org> References: <053.8265638cb53ac37cc1aae74a0afb4d97@haskell.org> Message-ID: <068.c110cabfb79092b758a76337020e785c@haskell.org> #7482: GHC.Event overwrites main IO managers hooks to RTS -------------------------------------+------------------------------------- Reporter: AndreasVoellmy | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: libraries/base | Version: 7.4.1 Resolution: | Keywords: IO | Manager, RTS Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: 7.8.1 => 8.0.1 Comment: Moving out to 8.0.1 (since this was milestoned to an old release). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 11 09:09:47 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Sep 2015 09:09:47 -0000 Subject: [GHC] #9637: Type level programming needs an error function In-Reply-To: <047.3309ef9af8755e67dc24602c9e6ec77f@haskell.org> References: <047.3309ef9af8755e67dc24602c9e6ec77f@haskell.org> Message-ID: <062.3a9be94092e904256c70a83c5df60180@haskell.org> #9637: Type level programming needs an error function -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9180, #9636 | Differential Revisions: Phab:D1236 -------------------------------------+------------------------------------- Comment (by simonpj): On the implementation front, I have some suggestions, which I've added under `SLPJ alternative design` on the wiki page [wiki:CustomTypeErros] (The title of the wiki page is mis-spelled. Rename?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 11 09:12:05 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Sep 2015 09:12:05 -0000 Subject: [GHC] #9646: Simplifer non-determinism leading to 8 fold difference in run time performance In-Reply-To: <044.91d1be288ff53f5ea138a0b071967333@haskell.org> References: <044.91d1be288ff53f5ea138a0b071967333@haskell.org> Message-ID: <059.d2acd6f93c36fd77cf55ca8248be1a71@haskell.org> #9646: Simplifer non-determinism leading to 8 fold difference in run time performance -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.3 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): > Moving to 7.10.3 - would be nice to fix. I don't understand. It's apparently fixed in 7.9 and so should be fixed in 7.10.2, right? What we need is a test case so we will know if it regresses. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 11 09:26:11 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Sep 2015 09:26:11 -0000 Subject: [GHC] #7830: Error: operand out of range In-Reply-To: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> References: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> Message-ID: <059.360ba6504c3ef08325f1cd9735cbb208@haskell.org> #7830: Error: operand out of range -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Installing GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by erikd): Looked through the git log to see if I could find possible breaking commits. The most obvious one was this: {{{ commit d3c1dda60d0ec07fc7f593bfd83ec9457dfa7984 Author: Peter Trommler Date: Fri Jul 3 19:09:06 2015 +0200 Implement PowerPC 64-bit native code backend for Linux }}} but this commit builds fine. Currently running a git bisect. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 11 09:36:53 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Sep 2015 09:36:53 -0000 Subject: [GHC] #4426: Simplify the rules for implicit quantification In-Reply-To: <046.cc2650d075f9bec123108fe76360a0e2@haskell.org> References: <046.cc2650d075f9bec123108fe76360a0e2@haskell.org> Message-ID: <061.0e7dc4cad5cf0012e4852c878f059714@haskell.org> #4426: Simplify the rules for implicit quantification -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: feature request | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 6.12.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7880 | Differential Revisions: Phab:D211 -------------------------------------+------------------------------------- Changes (by simonpj): * owner: => simonpj Comment: Yes, I am working on it, as part of some refactoring in the front end that I'm busy with. Thanks for the offer though! (There are plenty of other tickets, so you should not lack for opportunity.) Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 11 11:38:23 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Sep 2015 11:38:23 -0000 Subject: [GHC] #10867: Primop types should not mention () Message-ID: <046.c2e6159f1c64c1079ec9b781aa715970@haskell.org> #10867: Primop types should not mention () -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- I've just noticed that two primpops have types that mention tuples (see `compiler/prelude/primops.txt.pp`): {{{ primop FinalizeWeakOp "finalizeWeak#" GenPrimOp Weak# a -> State# RealWorld -> (# State# RealWorld, Int#, (State# RealWorld -> (# State# RealWorld, () #)) #) primop Check "check#" GenPrimOp (State# RealWorld -> (# State# RealWorld, a #) ) -> (State# RealWorld -> (# State# RealWorld, () #) ) }}} But they really really shouldn't. The unit tuple is a type defined in Haskell, and it makes an awkward cycle if the supposedly-truly-primitive primpops refer to it. (Discovered during the saga of [Phab:D757].) Most primpops do not do this; eg {{{ primop WriteMutVarOp "writeMutVar#" GenPrimOp MutVar# s a -> a -> State# s -> State# s }}} Now `check#` and `finalizeWeak#` are pretty obscure primops and I don't think anyone will mind if I fix their type signatures. But in addition to doing that, I'll have to look at their implementations. '''But where ''are'' those implementations??''' I can't find anything in the RTS. While thinking about it * Both come with literally zero Haddock documentation which is terrible. The type of both is pretty obscure. * `check#` is a very short name for very specialised STM operation. Surely we should call it `addSTMInvariant` or something like that? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 11 13:10:30 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Sep 2015 13:10:30 -0000 Subject: [GHC] #10826: [Security] Safe Haskell can be bypassed via annotations In-Reply-To: <045.6042fe6f9f535df81b6d3e710bdd3ea9@haskell.org> References: <045.6042fe6f9f535df81b6d3e710bdd3ea9@haskell.org> Message-ID: <060.4b6b942bfdccc61c0c183a75e8084186@haskell.org> #10826: [Security] Safe Haskell can be bypassed via annotations -------------------------------------+------------------------------------- Reporter: spinda | Owner: kanetw Type: bug | Status: merge Priority: highest | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: phab:D1226 -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 11 13:23:42 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Sep 2015 13:23:42 -0000 Subject: [GHC] #8524: GHC is inconsistent with the Haskell Report on which Unicode characters are allowed in string and character literals In-Reply-To: <045.aa22727e9338664a3617f731b2d178cd@haskell.org> References: <045.aa22727e9338664a3617f731b2d178cd@haskell.org> Message-ID: <060.f4ec5f694d48d43072f2753f1d0e6ed8@haskell.org> #8524: GHC is inconsistent with the Haskell Report on which Unicode characters are allowed in string and character literals -------------------------------------+------------------------------------- Reporter: oerjan | Owner: | RyanGlScott Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.6.3 (Parser) | Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1235 -------------------------------------+------------------------------------- Comment (by RyanGlScott): It looks like I might have jumped the gun on this a bit too early! That's okay, though?let's figure out what exactly needs to change. It looks like people want Space/uniWhite in strings, which GHC already allows, so no changes are needed there. At least one person has expressed the desire for inclusion of Format in string and Space uniWhite in string gaps, so unless anyone has any objections, should we push to make GHC as inclusive as possible w.r.t. Unicode? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 11 14:55:46 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Sep 2015 14:55:46 -0000 Subject: [GHC] #10867: Primop types should not mention () In-Reply-To: <046.c2e6159f1c64c1079ec9b781aa715970@haskell.org> References: <046.c2e6159f1c64c1079ec9b781aa715970@haskell.org> Message-ID: <061.b8bfdec6978144865710dd77b146cbe9@haskell.org> #10867: Primop types should not mention () -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by fryguybob): The `check#` implementation is found here: https://ghc.haskell.org/trac/ghc/browser/ghc/rts/PrimOps.cmm#L1320 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 11 15:12:47 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Sep 2015 15:12:47 -0000 Subject: [GHC] #8524: GHC is inconsistent with the Haskell Report on which Unicode characters are allowed in string and character literals In-Reply-To: <045.aa22727e9338664a3617f731b2d178cd@haskell.org> References: <045.aa22727e9338664a3617f731b2d178cd@haskell.org> Message-ID: <060.92bdf9cd1d0ac3764fc2492ecde089df@haskell.org> #8524: GHC is inconsistent with the Haskell Report on which Unicode characters are allowed in string and character literals -------------------------------------+------------------------------------- Reporter: oerjan | Owner: | RyanGlScott Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.6.3 (Parser) | Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1235 -------------------------------------+------------------------------------- Changes (by thomie): * cc: hvr (added) Comment: @RyanGlScott: sorry about that, I should not have put the newcomer keyword on this ticket prematurely. Some code: * Whitespace characters that the report excludes from strings: {{{ > delete '\SP' $ filter isSpace ['\0'..] "\t\n\v\f\r\160\5760\8192\8193\8194\8195\8196\8197\8198\8199\8200\8201\8202\8239\8287\12288" }}} * Whitespace characters that GHC excludes from strings: {{{ > filter (\c -> generalCategory c == Control && isSpace c) ['\0'..] "\t\n\v\f\r" }}} * `generalCategories` that the report and GHC also exclude from strings: {{{ > nub $ map generalCategory $ filter (not . isPrint) ['\0'..] [Control,Format,NotAssigned,LineSeparator,ParagraphSeparator,Surrogate,PrivateUse] }}} If we're going to be "as inclusive as possible", why not allow all of these? Are there any downsides to this? Perhaps under a new flag `FullUnicodeStrings`, enabled by default and disabled in Haskell98 and Haskell2010 mode. I'm also ok with just mentioning the current deviation from the report in https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/bugs-and- infelicities.html. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 11 15:30:34 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Sep 2015 15:30:34 -0000 Subject: [GHC] #10867: Primop types should not mention () In-Reply-To: <046.c2e6159f1c64c1079ec9b781aa715970@haskell.org> References: <046.c2e6159f1c64c1079ec9b781aa715970@haskell.org> Message-ID: <061.5cd08f47e305b429a856ff6be9d577d5@haskell.org> #10867: Primop types should not mention () -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Great. But what would need to change if we want the type of `check#` to be {{{ primop Check "check#" GenPrimOp (State# RealWorld -> (# State# RealWorld, a #) ) -> State# RealWorld -> State# RealWorld }}} more like other primops. Somehow it must be returning that unit tuple. (Or perhaps not and it's always been broken!!!) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 11 15:35:13 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Sep 2015 15:35:13 -0000 Subject: [GHC] #10867: Primop types should not mention () In-Reply-To: <046.c2e6159f1c64c1079ec9b781aa715970@haskell.org> References: <046.c2e6159f1c64c1079ec9b781aa715970@haskell.org> Message-ID: <061.ea5b8efe6d42ca9c4959b120bf1c4342@haskell.org> #10867: Primop types should not mention () -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by fryguybob): And `finalizeWeak#` is here: https://ghc.haskell.org/trac/ghc/browser/ghc/rts/PrimOps.cmm#L679 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 11 15:43:56 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Sep 2015 15:43:56 -0000 Subject: [GHC] #10867: Primop types should not mention () In-Reply-To: <046.c2e6159f1c64c1079ec9b781aa715970@haskell.org> References: <046.c2e6159f1c64c1079ec9b781aa715970@haskell.org> Message-ID: <061.6eb5cc69fc1c1000d8c95bd177d58dac@haskell.org> #10867: Primop types should not mention () -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by fryguybob): The `checkzh` primop ends with `return ()` which is syntax and turns into `mkReturn` with an empty list of `CmmActual`. Not sure if that helps. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 11 15:48:05 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Sep 2015 15:48:05 -0000 Subject: [GHC] #10867: Primop types should not mention () In-Reply-To: <046.c2e6159f1c64c1079ec9b781aa715970@haskell.org> References: <046.c2e6159f1c64c1079ec9b781aa715970@haskell.org> Message-ID: <061.e77bbae01e1f896f987adef5f9f08c7d@haskell.org> #10867: Primop types should not mention () -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by fryguybob): Other primops like `CopySmallArrayOp#` end with `return ()` in cmm and have a type `... -> State# s -> State# s`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 11 15:49:21 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Sep 2015 15:49:21 -0000 Subject: [GHC] #8524: GHC is inconsistent with the Haskell Report on which Unicode characters are allowed in string and character literals In-Reply-To: <045.aa22727e9338664a3617f731b2d178cd@haskell.org> References: <045.aa22727e9338664a3617f731b2d178cd@haskell.org> Message-ID: <060.8dc114ee5a26960e0795f77f2d2e8ccf@haskell.org> #8524: GHC is inconsistent with the Haskell Report on which Unicode characters are allowed in string and character literals -------------------------------------+------------------------------------- Reporter: oerjan | Owner: | RyanGlScott Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.6.3 (Parser) | Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1235 -------------------------------------+------------------------------------- Comment (by oerjan): Replying to [comment:6 thomie]: > If we're going to be "as inclusive as possible", why not allow all of these? Are there any downsides to this? Perhaps under a new flag `FullUnicodeStrings`, enabled by default and disabled in Haskell98 and Haskell2010 mode. A couple thoughts: Allowing \n in strings severely messes with layout. I've always assumed that's why it was disallowed in the first place. I suppose this also applies to the other *Separators and perhaps "\v\f\r" too (which would probably be *Separators if they weren't grandfathered as Control). And \r has the varying newline encoding issue. Unless I'm severely mistaken, Surrogate only exists because of the Unicode multiple encodings mess, and shouldn't ever really be ''used'' in UTF-8. I guess including them is fairly harmless but might trip up someone doing a bad encoding conversion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 11 16:01:32 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Sep 2015 16:01:32 -0000 Subject: [GHC] #10867: Primop types should not mention () In-Reply-To: <046.c2e6159f1c64c1079ec9b781aa715970@haskell.org> References: <046.c2e6159f1c64c1079ec9b781aa715970@haskell.org> Message-ID: <061.31940a5ec0697cf29552399bf926b34a@haskell.org> #10867: Primop types should not mention () -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by fryguybob): For the broader question of the STM data invariant feature, it is slightly broken (#7930) and may be a significant amount of work to keep around if we use an implementation that keeps an approximate read-set for performance gains. I have asked around before and never found any users of the feature or code in the wild that uses the feature. Its usefulness for discovering problems in user code is limited in highly concurrent settings. The implementation takes a lock on every `TVar` when the transaction has touched an invariant meaning it simply will not see some interleavings that might be the exact ones that violate the invariant. Perhaps a better approach in the space is to extend D?j? Fu from Michael Walker and Colin Runciman to cover the same territory but include all the most significant interleavings. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 11 16:04:08 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Sep 2015 16:04:08 -0000 Subject: [GHC] #10867: Primop types should not mention () In-Reply-To: <046.c2e6159f1c64c1079ec9b781aa715970@haskell.org> References: <046.c2e6159f1c64c1079ec9b781aa715970@haskell.org> Message-ID: <061.edf6b7de9f9ef3879a8e0d4faa870a45@haskell.org> #10867: Primop types should not mention () -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): I'd be ok with removing the STM data invariant feature altogether, if that seemed sensible. As you say, it is barely (never?) used. You are now the person closest to the metal, so please feel free to propose changes to GHC. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 11 16:04:55 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Sep 2015 16:04:55 -0000 Subject: [GHC] #10867: Primop types should not mention () In-Reply-To: <046.c2e6159f1c64c1079ec9b781aa715970@haskell.org> References: <046.c2e6159f1c64c1079ec9b781aa715970@haskell.org> Message-ID: <061.85e5b09a09cf2c9a30ba171aafc3edd0@haskell.org> #10867: Primop types should not mention () -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * cc: simonmar (added) Comment: Simon M: might you comment on what we need to do on the RTS side if we change the types of these to primops? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 11 16:17:09 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Sep 2015 16:17:09 -0000 Subject: [GHC] #10836: Better error reporting for closed type families In-Reply-To: <048.66b5b5c8ba8fcc7fd5bf86c3bc169961@haskell.org> References: <048.66b5b5c8ba8fcc7fd5bf86c3bc169961@haskell.org> Message-ID: <063.5db952f084686e2ac9487237e96f104a@haskell.org> #10836: Better error reporting for closed type families -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: T10836 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"a870738a3b34d264c63656783e84168a230d7da4/ghc" a870738/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a870738a3b34d264c63656783e84168a230d7da4" Improve rejigConRes (again) I think this patch finally works around the delicacy in the strictness of TcTyClsDecls.rejigConRes. See the notes with that function and Note [Checking GADT return types]. As a result, we fix Trac #10836, and improve Trac #7175 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 11 16:17:09 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Sep 2015 16:17:09 -0000 Subject: [GHC] #7175: Panic when wrongly using a type family as return types for GADTs In-Reply-To: <047.441799c7bbeef8d39b2646811008e078@haskell.org> References: <047.441799c7bbeef8d39b2646811008e078@haskell.org> Message-ID: <062.aedad571c2db409f7bb1ac25041cdd82@haskell.org> #7175: Panic when wrongly using a type family as return types for GADTs -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.6.1 Component: Compiler | Version: 7.6.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Compile-time | Test Case: crash | typecheck/should_fail/T7175 Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"a870738a3b34d264c63656783e84168a230d7da4/ghc" a870738/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a870738a3b34d264c63656783e84168a230d7da4" Improve rejigConRes (again) I think this patch finally works around the delicacy in the strictness of TcTyClsDecls.rejigConRes. See the notes with that function and Note [Checking GADT return types]. As a result, we fix Trac #10836, and improve Trac #7175 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 11 16:17:09 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Sep 2015 16:17:09 -0000 Subject: [GHC] #10806: Type error and type level (<=) together cause GHC to hang In-Reply-To: <048.9b3d349db1bfdcff1a2e281d43595c9a@haskell.org> References: <048.9b3d349db1bfdcff1a2e281d43595c9a@haskell.org> Message-ID: <063.c3f6f27efa6abf9d10d8c60e901cbfda@haskell.org> #10806: Type error and type level (<=) together cause GHC to hang -------------------------------------+------------------------------------- Reporter: htebalaka | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"487c90edd3c36406bdc020afd79a6696ae52c19b/ghc" 487c90ed/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="487c90edd3c36406bdc020afd79a6696ae52c19b" Add a test for Trac #10806 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 11 16:17:09 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Sep 2015 16:17:09 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.9b72eb28c1070a1e56a1f44af82836d2@haskell.org> #6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.4.1 Resolution: fixed | Keywords: | TypeFamilies, Injective Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T6018, | T6018fail, T6018rnfail, T6018th, | T6018failclosed1, T6018failclosed2, | T6018failclosed3, T6018failclosed4, | T6018failclosed5, T6018failclosed6, | T6018failclosed7, T6018failclosed8, | T6018failclosed9, | T6018failclosed10, | T6018failclosed11, | T6018failclosed12, T6018ghci, | T6018ghcifail, T6018ghcirnfail Blocked By: | Blocking: Related Tickets: #4259, #10832, | Differential Revisions: Phab:D202 #10833 | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"a7f690972629672510c71149d7d7c6ffe6217201/ghc" a7f6909/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a7f690972629672510c71149d7d7c6ffe6217201" A CFunEqCan can be Derived This fixes the ASSERTION failures in indexed-types/should_fail/T5439 typecheck/should_fail/T5490 when GHC is compiled with -DDEBUG See Phab:D202 attached to Trac #6018 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 11 16:19:21 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Sep 2015 16:19:21 -0000 Subject: [GHC] #10806: Type error and type level (<=) together cause GHC to hang In-Reply-To: <048.9b3d349db1bfdcff1a2e281d43595c9a@haskell.org> References: <048.9b3d349db1bfdcff1a2e281d43595c9a@haskell.org> Message-ID: <063.ab9ac0bff8caf12cce3e438cc7217b3c@haskell.org> #10806: Type error and type level (<=) together cause GHC to hang -------------------------------------+------------------------------------- Reporter: htebalaka | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: indexed- | types/should_compile/T10806 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => indexed-types/should_compile/T10806 * resolution: => fixed Comment: The test generates an error message (as it should) and does not make the compiler loop. So I'll close. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 11 16:19:59 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Sep 2015 16:19:59 -0000 Subject: [GHC] #9907: "Unknown PEi386 section name `.text$printf'" error in GHCi on Windows In-Reply-To: <051.9bd9875fb01e6198fe81abe3cec3e53a@haskell.org> References: <051.9bd9875fb01e6198fe81abe3cec3e53a@haskell.org> Message-ID: <066.17fafdddfe66c9ebde31386588f006b6@haskell.org> #9907: "Unknown PEi386 section name `.text$printf'" error in GHCi on Windows -------------------------------------+------------------------------------- Reporter: mmikolajczyk | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 7.10.3 Component: GHCi | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #7103, #10051, | Differential Revisions: Phab:D671 #7056, #8546 | -------------------------------------+------------------------------------- Comment (by Phyx-): @thoughtpolice Yes there will be a fix :) I have changed the code to identify most of the sections based on the flags in the PE file instead of the section names. So we don't have to keep a list of white-listed sections, so it should be much more resilient to changes. The only sections still being ignored by names are a few debugging ones, but it's fine since those are reserved names and currently we don't do debug section relocations. I'm just trying to find where the constant 17 comes from, but from looking at the generated .s files, I think this might be a bug in GAS. I'll submit a diff this weekend after I finish checking if the related bug reports are also fixed :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 11 16:20:18 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Sep 2015 16:20:18 -0000 Subject: [GHC] #10836: Better error reporting for closed type families In-Reply-To: <048.66b5b5c8ba8fcc7fd5bf86c3bc169961@haskell.org> References: <048.66b5b5c8ba8fcc7fd5bf86c3bc169961@haskell.org> Message-ID: <063.2830ef0c971c4358024666ddc27d768e@haskell.org> #10836: Better error reporting for closed type families -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | typecheck/should_fail/T10836 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: T10836 => typecheck/should_fail/T10836 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 11 18:56:31 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Sep 2015 18:56:31 -0000 Subject: [GHC] #10849: Injective type families broke debug build In-Reply-To: <046.e8b4c4e36c78bdca2257be09559c6daa@haskell.org> References: <046.e8b4c4e36c78bdca2257be09559c6daa@haskell.org> Message-ID: <061.0e4e2f95626be6c752c9d9e18573a168@haskell.org> #10849: Injective type families broke debug build -------------------------------------+------------------------------------- Reporter: nomeata | Owner: jstolarek Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by jstolarek): * status: new => closed * resolution: => fixed Comment: Fixed by Simon in a7f690972629672510c71149d7d7c6ffe6217201 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 11 19:04:56 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Sep 2015 19:04:56 -0000 Subject: [GHC] #10868: Make GHC generics capable of handling unboxed types Message-ID: <050.27f7f36fe7ccd6ec83005e9e4d3a8968@haskell.org> #10868: Make GHC generics capable of handling unboxed types -------------------------------------+------------------------------------- Reporter: | Owner: RyanGlScott RyanGlScott | Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #8468 Differential Revisions: | -------------------------------------+------------------------------------- Currently, GHC generics will not accept any unboxed constructor arguments: {{{ $ ghci GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help ?> :set -XMagicHash -XDeriveGeneric ?> :m + GHC.Generics GHC.Exts ?> data IntHash = IntHash Int# deriving Generic :4:38: Can't make a derived instance of ?Generic IntHash?: IntHash must not have unlifted or polymorphic arguments In the data declaration for ?IntHash? }}} This makes GHC generics strictly less powerful than `deriving` clauses in some scenarios, as typeclasses like `Eq`, `Ord`, and `Show` are capable of special-casing certain unboxed types: {{{ ?> :set -ddump-deriv ?> data IntHash = IntHash Int# deriving Show ==================== Derived instances ==================== Derived instances: instance GHC.Show.Show Ghci1.IntHash where GHC.Show.showsPrec a_a1OJ (Ghci1.IntHash b1_a1OK) = GHC.Show.showParen ((a_a1OJ GHC.Classes.>= 11)) ((GHC.Base..) (GHC.Show.showString "IntHash ") (GHC.Show.showsPrec 11 (GHC.Types.I# b1_a1OK))) GHC.Show.showList = GHC.Show.showList__ (GHC.Show.showsPrec 0) }}} As discussed on the GHC devs mailing list [https://mail.haskell.org/pipermail/ghc-devs/2015-September/009895.html previously], Andres suggested adding new generic representation types to mark where `Int#`, `Char#`, etc. are used (suggesting the name `UInt` to represent `Int#`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 11 19:11:59 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Sep 2015 19:11:59 -0000 Subject: [GHC] #10867: Primop types should not mention () In-Reply-To: <046.c2e6159f1c64c1079ec9b781aa715970@haskell.org> References: <046.c2e6159f1c64c1079ec9b781aa715970@haskell.org> Message-ID: <061.8f6bdcc2a214e604402d0249d0914d06@haskell.org> #10867: Primop types should not mention () -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonmar): The RTS refers to lots of things that are defined in Haskell, incidentally, not just in primops. The full list is in `rts/Prelude.h`. But you can change these primops if necessary. You probably didn't find the implementations because they're Z-encoded; `finalizeWeak#` is `stg_finalizzeWeakzh` in `rts/PrimOps.h`. It returns the finalizer of a weak pointer, which has type `State# RealWorld -> (# State# RealWorld, () #)`, but you could always lie and give it a more general type. The wrapper in `GHC.Weak` will probably work unchanged. We already lie in the type of `mkWeak#` in a similar way, for reasons I forget. It looks like `check#` has the wrong type anyway, its implementation returns `()` (ie. zero return values in Cmm), so its Haskell type should have a return type of `State# RealWorld`. Feel free to change its name at the same time, I agree it's a silly name! When changing this you'll need to run the tests in the stm package, which I think aren't run by default. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 11 19:31:01 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Sep 2015 19:31:01 -0000 Subject: [GHC] #10869: Option to dump preprocessed source Message-ID: <046.34bba2c2c1e4ccec0498d1f1e04c25f9@haskell.org> #10869: Option to dump preprocessed source -------------------------------------+------------------------------------- Reporter: phischu | Owner: Type: feature | Status: new request | Priority: low | Milestone: Component: Driver | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- It would be awesome if GHC had an option `-ddump-preprocessed` that dumps the source code for each module after preprocessing. I am not sure what the current definition of "preprocessing" is but I mean the output of at least the following tools: happy, alex, c2hs, hsc2hs and cpp. Additionally even if a module was not subject to any preprocessing it should be dumped anyway. Use case: I want to parse module files from packages from hackage with `haskell-src-exts` but find it prohibitively difficult to get the preprocessing right. The idea is that after `cabal install` with ghc options `-ddump-preprocessed -ddump-to-file -dumpdir real_modules` you get a complete working set of haskell modules that can be parsed directly without any preprocessing in folder `real_modules`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 11 19:39:53 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Sep 2015 19:39:53 -0000 Subject: [GHC] #10869: Option to dump preprocessed source In-Reply-To: <046.34bba2c2c1e4ccec0498d1f1e04c25f9@haskell.org> References: <046.34bba2c2c1e4ccec0498d1f1e04c25f9@haskell.org> Message-ID: <061.e26321cb0fd8c25d734548eaffa77e44@haskell.org> #10869: Option to dump preprocessed source -------------------------------------+------------------------------------- Reporter: phischu | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Driver | Version: 7.10.2 Resolution: | Keywords: easy Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * keywords: => easy -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 11 19:40:58 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Sep 2015 19:40:58 -0000 Subject: [GHC] #10869: Option to dump preprocessed source In-Reply-To: <046.34bba2c2c1e4ccec0498d1f1e04c25f9@haskell.org> References: <046.34bba2c2c1e4ccec0498d1f1e04c25f9@haskell.org> Message-ID: <061.78e8a0af9d724fbedea8a0d77c583d01@haskell.org> #10869: Option to dump preprocessed source -------------------------------------+------------------------------------- Reporter: phischu | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Driver | Version: 7.10.2 Resolution: | Keywords: easy Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by mpickering): I'm fairly sure there is already this option? Maybe it's `-E`.. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 11 19:48:08 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Sep 2015 19:48:08 -0000 Subject: [GHC] #10869: Option to dump preprocessed source In-Reply-To: <046.34bba2c2c1e4ccec0498d1f1e04c25f9@haskell.org> References: <046.34bba2c2c1e4ccec0498d1f1e04c25f9@haskell.org> Message-ID: <061.46aa2fd08cc2279228f8521d46a31a18@haskell.org> #10869: Option to dump preprocessed source -------------------------------------+------------------------------------- Reporter: phischu | Owner: Type: feature request | Status: closed Priority: low | Milestone: Component: Driver | Version: 7.10.2 Resolution: invalid | Keywords: easy Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => invalid Comment: Replying to [comment:2 mpickering]: > I'm fairly sure there is already this option? Maybe it's `-E`.. Exactly, see: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/modes.html #options-order The option -E runs just the pre-processing passes of the compiler, dumping the result in a file. GHC doesn't run `happy, alex, c2hs or hsc2hs` for you, so I don't think there's anything to do here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 11 19:59:56 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Sep 2015 19:59:56 -0000 Subject: [GHC] #10836: Better error reporting for closed type families In-Reply-To: <048.66b5b5c8ba8fcc7fd5bf86c3bc169961@haskell.org> References: <048.66b5b5c8ba8fcc7fd5bf86c3bc169961@haskell.org> Message-ID: <063.a28bbb16507a14bd3acc27dc54806e4b@haskell.org> #10836: Better error reporting for closed type families -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | typecheck/should_fail/T10836 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by jstolarek): Simon, this change is a huge improvement over the previous situation, but not everything is yet perfect. Consider this: {{{#!hs type family FClosed a b c = (result :: *) | result -> a b c where FClosed Int Char Bool = Bool FClosed Char Bool Int = Int FClosed Bool Int Char = Int type family Bar a = r | r -> a where Bar Int = Bool Bar Bool = Int Bar Bool = Char bar :: Bar a -> Bar a bar x = x barapp :: Char barapp = bar 'c' }}} I would expect to get two errors: {{{ T6018.hs:8:5: error: Type family equations violate injectivity annotation: FClosed Char Bool Int = Int FClosed Bool Int Char = Int In the equations for closed type family ?FClosed? In the type family declaration for ?FClosed? T6018.hs:20:14: error: Couldn't match expected type ?Bar a0? with actual type ?Char? The type variable ?a0? is ambiguous In the first argument of ?bar?, namely ?'c'? In the expression: bar 'c' In an equation for ?barapp?: barapp = bar 'c' }}} But I only get the first one. Is this expected? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 11 20:03:25 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Sep 2015 20:03:25 -0000 Subject: [GHC] #10870: PPC.Ppr: Shift by 32 bits is not allowed. Message-ID: <046.266af0561f46fb382b81907ac208339a@haskell.org> #10870: PPC.Ppr: Shift by 32 bits is not allowed. -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (CodeGen) | Keywords: | Operating System: Unknown/Multiple Architecture: powerpc | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Hi, when compiling `vector-algorithms` on powerpc, I get {{{ [ 7 of 10] Compiling Data.Vector.Algorithms.Tim ( src/Data/Vector/Algorithms/Tim.hs, dist- ghc/build/Data/Vector/Algorithms/Tim.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for powerpc-unknown-linux): PPC.Ppr: Shift by 32 bits is not allowed. }}} I do not get this error on other 32bit architectures. The offending code seems to be {{{ minrun :: Int -> Int minrun n0 = (n0 `unsafeShiftR` extra) + if (lowMask .&. n0) > 0 then 1 else 0 where -- smear the bits down from the most significant bit !n1 = n0 .|. unsafeShiftR n0 1 !n2 = n1 .|. unsafeShiftR n1 2 !n3 = n2 .|. unsafeShiftR n2 4 !n4 = n3 .|. unsafeShiftR n3 8 !n5 = n4 .|. unsafeShiftR n4 16 !n6 = n5 .|. unsafeShiftR n5 32 }}} The call to panic was introduced by Erik in the fix for #5900. Is the code at fault, or the compiler? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 11 20:07:21 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Sep 2015 20:07:21 -0000 Subject: [GHC] #7830: Error: operand out of range In-Reply-To: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> References: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> Message-ID: <059.1e664ef9b37c2c1b8cb1b9866302fe1f@haskell.org> #7830: Error: operand out of range -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Installing GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): > Currently running a git bisect. Great, keep us up-to-date. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 11 20:22:23 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Sep 2015 20:22:23 -0000 Subject: [GHC] #10856: Record update doesn't emit new constraints In-Reply-To: <047.de834d55250d835a617b774942ee7049@haskell.org> References: <047.de834d55250d835a617b774942ee7049@haskell.org> Message-ID: <062.8abfb56d96a7f82ec55c37a0a57d2ae9@haskell.org> #10856: Record update doesn't emit new constraints -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by mpickering): * cc: mpickering (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 11 21:41:36 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Sep 2015 21:41:36 -0000 Subject: [GHC] #7830: Error: operand out of range In-Reply-To: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> References: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> Message-ID: <059.9f19e6c8ae158c380c8dff900916fb22@haskell.org> #7830: Error: operand out of range -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Installing GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by erikd): According to git bisect, the commit that broke PowerPC was: {{{ commit 5d57087e314bd484dbe14958f9b422be3ac6641a Author: Thomas Miedema Date: Wed Aug 5 11:31:21 2015 +0200 Pretty: fix a broken invariant (#10735) }}} but since that doesn't touch any of the PowerPC specific code, the PowerPC code gen problem is simply a by-product of this patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 11 21:56:05 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Sep 2015 21:56:05 -0000 Subject: [GHC] #10870: PPC.Ppr: Shift by 32 bits is not allowed. In-Reply-To: <046.266af0561f46fb382b81907ac208339a@haskell.org> References: <046.266af0561f46fb382b81907ac208339a@haskell.org> Message-ID: <061.9904df47503f4883ac40435aa4257765@haskell.org> #10870: PPC.Ppr: Shift by 32 bits is not allowed. ---------------------------------------+---------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (CodeGen) | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------------+---------------------------------- Comment (by erikd): Maybe adding the panic was the wrong thing to do there. On 32 bit PowerPC, a right shift of 32 bits should just result in zero. However, the PowerPC codegen now supports 64 bit PowerPC, so we need to be careful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 11 23:22:33 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Sep 2015 23:22:33 -0000 Subject: [GHC] #10836: Better error reporting for closed type families In-Reply-To: <048.66b5b5c8ba8fcc7fd5bf86c3bc169961@haskell.org> References: <048.66b5b5c8ba8fcc7fd5bf86c3bc169961@haskell.org> Message-ID: <063.917813cb8e2f171d4370dbfe937270b3@haskell.org> #10836: Better error reporting for closed type families -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | typecheck/should_fail/T10836 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Jan Stolarek ): In [changeset:"f30a49250a0c96e9fb1b86d541657029a9aa8d51/ghc" f30a4925/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f30a49250a0c96e9fb1b86d541657029a9aa8d51" Testsuite cleanup As a result of fixing #10836 it is now possible to merge 11 different tests for #6018 into one }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 11 23:22:33 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Sep 2015 23:22:33 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.27732408d4e3d48a15e8f0f17fd23667@haskell.org> #6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.4.1 Resolution: fixed | Keywords: | TypeFamilies, Injective Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T6018, | T6018fail, T6018rnfail, T6018th, | T6018failclosed1, T6018failclosed2, | T6018failclosed3, T6018failclosed4, | T6018failclosed5, T6018failclosed6, | T6018failclosed7, T6018failclosed8, | T6018failclosed9, | T6018failclosed10, | T6018failclosed11, | T6018failclosed12, T6018ghci, | T6018ghcifail, T6018ghcirnfail Blocked By: | Blocking: Related Tickets: #4259, #10832, | Differential Revisions: Phab:D202 #10833 | -------------------------------------+------------------------------------- Comment (by Jan Stolarek ): In [changeset:"f30a49250a0c96e9fb1b86d541657029a9aa8d51/ghc" f30a4925/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f30a49250a0c96e9fb1b86d541657029a9aa8d51" Testsuite cleanup As a result of fixing #10836 it is now possible to merge 11 different tests for #6018 into one }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 11 23:32:40 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Sep 2015 23:32:40 -0000 Subject: [GHC] #8552: Rename StgArrWords to StgArrBytes In-Reply-To: <047.162074162cf551ca6b1ad3c66a412848@haskell.org> References: <047.162074162cf551ca6b1ad3c66a412848@haskell.org> Message-ID: <062.aa77d6f7b5dd227b74faeec3efcc8f46@haskell.org> #8552: Rename StgArrWords to StgArrBytes -------------------------------------+------------------------------------- Reporter: Tarrasch | Owner: | siddhanathan Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1233 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"7ad4b3c1419fefbb01fd4643f374150abd1d11e2/ghc" 7ad4b3c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7ad4b3c1419fefbb01fd4643f374150abd1d11e2" s/StgArrWords/StgArrBytes/ Rename StgArrWords to StgArrBytes (see Trac #8552) Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D1233 GHC Trac Issues: #8552 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 12 01:37:36 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Sep 2015 01:37:36 -0000 Subject: [GHC] #10868: Make GHC generics capable of handling unboxed types In-Reply-To: <050.27f7f36fe7ccd6ec83005e9e4d3a8968@haskell.org> References: <050.27f7f36fe7ccd6ec83005e9e4d3a8968@haskell.org> Message-ID: <065.de905ffd1d4e996f932c173c67718184@haskell.org> #10868: Make GHC generics capable of handling unboxed types -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: | RyanGlScott Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8468 | Differential Revisions: Phab:D1239 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * differential: => Phab:D1239 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 12 01:52:58 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Sep 2015 01:52:58 -0000 Subject: [GHC] #10871: Implement "buildable" interface files which can be directly compiled without source Message-ID: <045.f4306fd46ddf30e7464e9ea8971267bf@haskell.org> #10871: Implement "buildable" interface files which can be directly compiled without source -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- A fat interface file is like a normal hi file, but with extra information so that GHC can *recompile* the associated module without having to parse, rename and typecheck the source code again. The proposed command-line interface is something like (subject to bikeshedding): {{{ ghc -c A.hs -fno-code -fwrite-buildable-interface # produces a .hi-build file, then ghc -c A.hi-build # completes building, as if ghc -c A.hs had been called }}} The primary motivation for this is to support partially compiling indefinite packages, which cannot be compiled to object code due to the fact that some of the dependencies haven't been provided yet. However, there are some other cases where this might be useful: 1. Supercompilation requires having the source of all bindings, buildable interfaces can make this information available, even beyond what storing inlinings might provide 2. A buildable interface file can be used to build variants of a source, e.g. profiling and optimization, even "on the fly" by GHC if necessary. And maybe more we haven't thought of yet. The primary function you need to implement is a function from `ModIface`/`ModDetails` to `TcGblEnv`, which can then be fed to the desugarer. I'm looking at what things we need to add to `ModIface` to support this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 12 07:35:39 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Sep 2015 07:35:39 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.29a92d6a349d56cc2c3f365499638fb4@haskell.org> #6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.4.1 Resolution: fixed | Keywords: | TypeFamilies, Injective Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T6018, | T6018fail, T6018rnfail, T6018th, | T6018failclosed1, T6018failclosed2, | T6018ghci, T6018ghcifail, | T6018ghcirnfail Blocked By: | Blocking: Related Tickets: #4259, #10832, | Differential Revisions: Phab:D202 #10833 | -------------------------------------+------------------------------------- Changes (by jstolarek): * testcase: T6018, T6018fail, T6018rnfail, T6018th, T6018failclosed1, T6018failclosed2, T6018failclosed3, T6018failclosed4, T6018failclosed5, T6018failclosed6, T6018failclosed7, T6018failclosed8, T6018failclosed9, T6018failclosed10, T6018failclosed11, T6018failclosed12, T6018ghci, T6018ghcifail, T6018ghcirnfail => T6018, T6018fail, T6018rnfail, T6018th, T6018failclosed1, T6018failclosed2, T6018ghci, T6018ghcifail, T6018ghcirnfail -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 12 08:37:23 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Sep 2015 08:37:23 -0000 Subject: [GHC] #10872: More informative assertion for non-unique TH names Message-ID: <048.31528093886b2ab66084097b2ba3a854@haskell.org> #10872: More informative assertion for non-unique TH names -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Let's say that by accident I have duplicated uniques of Template Haskell built-in identifiers defined in `THNames` module: {{{#!hs returnQIdKey = mkPreludeMiscIdUnique 200 bindQIdKey = mkPreludeMiscIdUnique 200 }}} If I have a debugging build (`-DDEBUG`) and start a GHCi session it crashes immediately with a very uninformative error message: {{{ GHCi, version 7.11.20150903: http://www.haskell.org/ghc/ :? for help :1:1: error: Bad interface file: /dane/projekty/ghc/build/libraries/base/dist- install/build/Prelude.hi ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.11.20150903 for x86_64-unknown-linux): ASSERT failed! <
> Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I have no idea where this assertion comes from as it gives absolutely no clue as to what caused the problem. During ICFP this costed me and Richard a total of around 6 man-hours. We should replace that assertion with something more meaningful. One thing we could do is add an assertion to the definition of `THNames.templateHaskellNames` that makes sure that `length templateHaskellNames == length (nub templateHaskellNames)`. That by itself is very simple but the problem is that the uninformative assertion given above still kicks in first. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 12 09:22:40 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Sep 2015 09:22:40 -0000 Subject: [GHC] #7830: Error: operand out of range In-Reply-To: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> References: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> Message-ID: <059.f3299ca141816ca7cd21511c6da61b0d@haskell.org> #7830: Error: operand out of range -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Installing GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by erikd): The generated code that causes a problem looks like: {{{ stw 31, 36328(1) lwz 31, 67(14) stw 29, 36336(1) lwz 29, 71(14) stw 28, 36344(1) lwz 28, 75(14) stw 26, 36352(1) }}} The problem is, that according to https://www-01.ibm.com/support/knowledgecenter/ssw_aix_71/com.ibm.aix.alangref/idalangref_stw_st_instrs.htm the offset is a signed 16 bit value and 36336 can'nt be represented in a signed 16 bit value. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 12 09:49:18 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Sep 2015 09:49:18 -0000 Subject: [GHC] #8406: Invalid object in isRetainer() or Segfault In-Reply-To: <047.cda95cb1752355077595406288b06592@haskell.org> References: <047.cda95cb1752355077595406288b06592@haskell.org> Message-ID: <062.6c28bf94b8f902e09548a8f349e65dfc@haskell.org> #8406: Invalid object in isRetainer() or Segfault -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 8.0.1 Component: Runtime System | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by pallly): I have the same problem, here is my code: http://hub.darcs.net/pallly/hdur When I run the executable with +RTS -hr, it crashes with the "Invalid object in isRetainer(): 8". (Maybe you'll need to press the 'o' key). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 12 11:37:19 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Sep 2015 11:37:19 -0000 Subject: [GHC] #10510: Testsuite driver does not run tests in parallel on Windows In-Reply-To: <045.f7051a2be634cd79e52b8850db4fc44f@haskell.org> References: <045.f7051a2be634cd79e52b8850db4fc44f@haskell.org> Message-ID: <060.6b7a981996b68aaa5f2793aef221bda3@haskell.org> #10510: Testsuite driver does not run tests in parallel on Windows -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Test Suite | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): This is still an issue for me. {{{ $ uname -a MINGW64_NT-6.3 ghc-msys2 2.0.0(0.275/5/3) 2014-10-09 11:14 x86_64 Msys }}} {{{ $ systeminfo Host Name: GHC-MSYS2 OS Name: Microsoft Windows Server 2012 R2 Standard OS Version: 6.3.9600 N/A Build 9600 OS Manufacturer: Microsoft Corporation OS Configuration: Standalone Server OS Build Type: Multiprocessor Free Registered Owner: Rackspace Registered Organization: Rackspace Product ID: 00252-70000-00000-AA535 Original Install Date: 10/4/2014, 8:10:48 AM System Boot Time: 9/12/2015, 11:29:35 AM System Manufacturer: Xen System Model: HVM domU System Type: x64-based PC Processor(s): 4 Processor(s) Installed. [01]: Intel64 Family 6 Model 62 Stepping 4 GenuineIntel ~2600 Mhz [02]: Intel64 Family 6 Model 62 Stepping 4 GenuineIntel ~2599 Mhz [03]: Intel64 Family 6 Model 62 Stepping 4 GenuineIntel ~2599 Mhz [04]: Intel64 Family 6 Model 62 Stepping 4 GenuineIntel ~2599 Mhz BIOS Version: Xen 4.1.5, 11/28/2013 Windows Directory: C:\Windows System Directory: C:\Windows\system32 Boot Device: \Device\HarddiskVolume1 System Locale: en-us;English (United States) Input Locale: en-us;English (United States) Time Zone: (UTC) Coordinated Universal Time Total Physical Memory: 4,092 MB Available Physical Memory: 3,503 MB Virtual Memory: Max Size: 6,140 MB Virtual Memory: Available: 5,496 MB Virtual Memory: In Use: 644 MB Page File Location(s): C:\pagefile.sys Domain: WORKGROUP Logon Server: N/A Hotfix(s): 59 Hotfix(s) Installed. [01]: KB2894852 [02]: KB2894856 [03]: KB2896496 [04]: KB2918614 [05]: KB2919355 [06]: KB2919442 [07]: KB2920189 [08]: KB2926765 [09]: KB2931358 [10]: KB2931366 [11]: KB2937220 [12]: KB2938066 [13]: KB2938772 [14]: KB2939087 [15]: KB2939471 [16]: KB2939576 [17]: KB2949621 [18]: KB2950153 [19]: KB2954879 [20]: KB2955164 [21]: KB2956575 [22]: KB2957189 [23]: KB2958262 [24]: KB2959626 [25]: KB2959977 [26]: KB2961072 [27]: KB2962409 [28]: KB2964718 [29]: KB2965500 [30]: KB2965788 [31]: KB2966826 [32]: KB2966828 [33]: KB2967917 [34]: KB2971203 [35]: KB2972213 [36]: KB2973114 [37]: KB2973201 [38]: KB2973351 [39]: KB2973448 [40]: KB2975061 [41]: KB2975719 [42]: KB2976627 [43]: KB2976897 [44]: KB2977174 [45]: KB2977629 [46]: KB2977765 [47]: KB2978668 [48]: KB2979582 [49]: KB2981580 [50]: KB2982791 [51]: KB2984006 [52]: KB2988948 [53]: KB2989647 [54]: KB2990532 [55]: KB2993100 [56]: KB2993651 [57]: KB2994897 [58]: KB2995004 [59]: KB2998527 Network Card(s): 2 NIC(s) Installed. [01]: Citrix PV Network Adapter Connection Name: public0 DHCP Enabled: No IP address(es) [01]: 104.130.171.101 [02]: fe80::8c4e:3953:209a:d97e [03]: 2001:4802:7801:104:903:8a71:7342:99a1 [02]: Citrix PV Network Adapter Connection Name: private0 DHCP Enabled: No IP address(es) [01]: 10.209.1.81 [02]: fe80::8d64:adaf:4a4b:b531 Hyper-V Requirements: A hypervisor has been detected. Features required for Hyper-V will not be displayed. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 12 11:53:00 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Sep 2015 11:53:00 -0000 Subject: [GHC] #10478: Shorter import syntax In-Reply-To: <046.5e60b02b9fe497cdf59ecd5b37a450a2@haskell.org> References: <046.5e60b02b9fe497cdf59ecd5b37a450a2@haskell.org> Message-ID: <061.02a9c81a9bd1ce158a373b08a9b0f14f@haskell.org> #10478: Shorter import syntax -------------------------------------+------------------------------------- Reporter: acowley | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1238 -------------------------------------+------------------------------------- Changes (by thomie): * differential: => Phab:D1238 Comment: Other discussions of this proposal: * https://mail.haskell.org/pipermail/haskell-cafe/2015-June/119942.html * https://www.reddit.com/r/haskell/comments/38vsef/proposal_shorter_import_syntax/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 12 12:14:56 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Sep 2015 12:14:56 -0000 Subject: [GHC] #8176: Language extensions not registered In-Reply-To: <045.79de2871493b7288b102990a0c57a18c@haskell.org> References: <045.79de2871493b7288b102990a0c57a18c@haskell.org> Message-ID: <060.c15a106214b7c5b07338a317d1708f50@haskell.org> #8176: Language extensions not registered -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | tests/driver/T4437.hs Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * keywords: => newcomer * status: closed => new * resolution: fixed => * owner: thoughtpolice => Comment: Task for a newcomer. `testsuite/tests/driver/T4437.hs` currently contains: {{{ expectedGhcOnlyExtensions :: [String] expectedGhcOnlyExtensions = ["RelaxedLayout", "AlternativeLayoutRule", "AlternativeLayoutRuleTransitional", "StaticPointers", "StrictData"] }}} The last 2 extensions should be registered with Cabal. Submit a pull request to https://github.com/haskell/Cabal/pulls. I don't know what the first 3 are about, they are not listed on https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/flag- reference.html. Try to find out if they can be deleted. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 12 12:15:11 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Sep 2015 12:15:11 -0000 Subject: [GHC] #8176: Language extensions not registered In-Reply-To: <045.79de2871493b7288b102990a0c57a18c@haskell.org> References: <045.79de2871493b7288b102990a0c57a18c@haskell.org> Message-ID: <060.040d74f58f33ed12165200724b70566d@haskell.org> #8176: Language extensions not registered -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | tests/driver/T4437.hs Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * type: bug => task -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 12 12:15:34 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Sep 2015 12:15:34 -0000 Subject: [GHC] #8176: Language extensions not registered In-Reply-To: <045.79de2871493b7288b102990a0c57a18c@haskell.org> References: <045.79de2871493b7288b102990a0c57a18c@haskell.org> Message-ID: <060.18dfe9232393d1f6c99beb812f4a018a@haskell.org> #8176: Language extensions not registered -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | tests/driver/T4437.hs Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * milestone: 7.8.1 => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 12 12:25:15 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Sep 2015 12:25:15 -0000 Subject: [GHC] #8176: Language extensions not registered In-Reply-To: <045.79de2871493b7288b102990a0c57a18c@haskell.org> References: <045.79de2871493b7288b102990a0c57a18c@haskell.org> Message-ID: <060.701f7d67fa746b5681b610dbebe93e2e@haskell.org> #8176: Language extensions not registered -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | tests/driver/T4437.hs Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * keywords: newcomer => Comment: See also https://github.com/haskell/cabal/issues/2291. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 12 16:21:38 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Sep 2015 16:21:38 -0000 Subject: [GHC] #365: GHC dies silently with faulty preprocessor In-Reply-To: <045.970f5372032e408119e71a3210b4ecaf@haskell.org> References: <045.970f5372032e408119e71a3210b4ecaf@haskell.org> Message-ID: <060.539a2d2197162afefc355f856d354db1@haskell.org> #365: GHC dies silently with faulty preprocessor -------------------------------------+------------------------------------- Reporter: josefs | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: closed => new * os: => Windows * failure: => None/Unknown * version: 6.4 => 7.11 * architecture: => Unknown/Multiple * owner: simonmar => * resolution: Fixed => Old description: > {{{ > This is perhaps a minor nuisance but I had to spend > quite some time to track down my bug. When ghc is given > a preprocessor which for some reason cannot execute > then ghc just dies silently without giving any > indication as to what the problem was. It would be nice > with a little message hinting at the problem on stderr. > > Oh, and by the way, the -F flag doesn't have any > documentation. It is only mentioned together with -optF. > }}} New description: {{{ This is perhaps a minor nuisance but I had to spend quite some time to track down my bug. When ghc is given a preprocessor which for some reason cannot execute then ghc just dies silently without giving any indication as to what the problem was. It would be nice with a little message hinting at the problem on stderr. Oh, and by the way, the -F flag doesn't have any documentation. It is only mentioned together with -optF. }}} -- Comment: This is still an issue. {{{ $ echo 'main = return ()' > hello.hs $ touch wibble # The faulty preprocessor. $ chmod +x wibble $ ghc -F -pgmF ./wibble -c hello.hs # Note: no error message. $ echo $? # But the command failed. 1 }}} Compiling with `-v` shows: {{{ *** Haskell pre-processor: "./wibble" "hello.hs" "hello.hs" "C:\msys64\tmp\ghc3020_0\ghc3020_1.hspp" Failed: "./wibble" "hello.hs" "hello.hs" "C:\msys64\tmp\ghc3020_0\ghc3020_1.hspp" ./wibble: runInteractiveProcess: invalid argument (Exec format error) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 12 16:41:36 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Sep 2015 16:41:36 -0000 Subject: [GHC] #365: GHC dies silently with faulty preprocessor In-Reply-To: <045.970f5372032e408119e71a3210b4ecaf@haskell.org> References: <045.970f5372032e408119e71a3210b4ecaf@haskell.org> Message-ID: <060.71b3846650c8f07f8768fa10a5c94251@haskell.org> #365: GHC dies silently with faulty preprocessor -------------------------------------+------------------------------------- Reporter: josefs | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): It seems the `-pgmF` is just plain broken on Windows (msys2). The following fails in the same way as `wibble` above: {{{ $ echo 'cat $2 > $3' > preprocess $ chmod +x preprocess $ ghc -F -pgmF ./preprocess hello.hs $ echo $? $ 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 12 16:49:27 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Sep 2015 16:49:27 -0000 Subject: [GHC] #365: GHC dies silently with faulty preprocessor In-Reply-To: <045.970f5372032e408119e71a3210b4ecaf@haskell.org> References: <045.970f5372032e408119e71a3210b4ecaf@haskell.org> Message-ID: <060.c97a146b044d585693a69cc5626dcfa2@haskell.org> #365: GHC dies silently with faulty preprocessor -------------------------------------+------------------------------------- Reporter: josefs | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): Oh, Phyx on #ghc says `-pgmF` requires a `.bat` file. Sure enough, then it works: {{{ $ echo 'cat %2 > %3' > preprocess.bat $ chmod +x preprocess.bat $ ghc -F -pgmF ./preprocess.bat hello.hs C:\msys64\tmp\test>cat "hello.hs" 1>"C:\msys64\tmp\ghc1556_0\ghc1556_1.hspp" $ echo $? 0 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 12 17:13:53 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Sep 2015 17:13:53 -0000 Subject: [GHC] #9399: CPP does not process test case enum01.hs correctly In-Reply-To: <042.8bd2b8ed84f95b67c9cae49884c4f662@haskell.org> References: <042.8bd2b8ed84f95b67c9cae49884c4f662@haskell.org> Message-ID: <057.1d3b16871e08412637370a91e908980c@haskell.org> #9399: CPP does not process test case enum01.hs correctly -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.11 Resolution: | Keywords: cpp Operating System: Windows | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: enum01.hs Blocked By: | Blocking: Related Tickets: #365 | Differential Revisions: Phab:D957 -------------------------------------+------------------------------------- Changes (by thomie): * status: closed => new * resolution: fixed => * related: => #365 * version: 7.8.3 => 7.11 * milestone: 7.10.2 => * owner: rwbarton => * os: MacOS X => Windows Comment: Now it's broken on Windows. GHC on Windows can't handle a shell script as an argument to `-pgmF`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 12 17:50:20 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Sep 2015 17:50:20 -0000 Subject: [GHC] #7830: Error: operand out of range In-Reply-To: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> References: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> Message-ID: <059.063cc33937323419224e9eed95f67128@haskell.org> #7830: Error: operand out of range -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Installing GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by trommler): This looks like code spilling registers onto the stack. But why are the offsets so large? Could you attach the entire assembler file? I tried to reproduce on powerpc64 HEAD but compile failed to typecheck in package uualib. I'll try to reproduce with the commit you mentioned in comment:24. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 12 18:38:19 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Sep 2015 18:38:19 -0000 Subject: [GHC] #9399: CPP does not process test case enum01.hs correctly In-Reply-To: <042.8bd2b8ed84f95b67c9cae49884c4f662@haskell.org> References: <042.8bd2b8ed84f95b67c9cae49884c4f662@haskell.org> Message-ID: <057.bf9a4794324a05803a407f3e07ade33d@haskell.org> #9399: CPP does not process test case enum01.hs correctly -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.11 Resolution: | Keywords: cpp Operating System: Windows | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: enum01.hs Blocked By: | Blocking: Related Tickets: #365 | Differential Revisions: Phab:D957 -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"37081acc74b9820b284161c95b16ff878fc5830f/ghc" 37081acc/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="37081acc74b9820b284161c95b16ff878fc5830f" Testsuite: mark enum01-enum03 expect_broken(#9399) on Windows }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 12 18:49:28 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Sep 2015 18:49:28 -0000 Subject: [GHC] #365: GHC dies silently with faulty preprocessor In-Reply-To: <045.970f5372032e408119e71a3210b4ecaf@haskell.org> References: <045.970f5372032e408119e71a3210b4ecaf@haskell.org> Message-ID: <060.d9da3133d9c9e9149e695723842c45e3@haskell.org> #365: GHC dies silently with faulty preprocessor -------------------------------------+------------------------------------- Reporter: josefs | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Phyx-): More specifically, I think the issue here is with the use of [https://github.com/haskell/process/blob/52cad6528a01b7cca011ac1c4ef7d33b1f500532/cbits/runProcess.c runInteractiveProcess], which ultimately calls [https://msdn.microsoft.com /en-us/library/windows/desktop/ms682425(v=vs.85).aspx CreateProcess] on Windows. The problem is that processes created using `CreateProcess` must be known by the Windows loader. From the MSDN page. "This module can be a Windows-based application. It can be some other type of module (for example, MS-DOS or OS/2) if the appropriate subsystem is available on the local computer. " Since .py are not known by the system loader the call fails with `Exec format error` I think there are two solutions: * Specify `cmd.exe` or rather, whatever `ComSpec` is pointing to as the application and the preprocessor to run as the argument. * Alternatively use `ShellExecute` instead of `CreateProcess` to start the preprocessors. However both of them won't necessarily fix the tests that are failing, since that would require the .py extension to be registered to the python2 in msys. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 12 19:01:57 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Sep 2015 19:01:57 -0000 Subject: [GHC] #10870: PPC.Ppr: Shift by 32 bits is not allowed. In-Reply-To: <046.266af0561f46fb382b81907ac208339a@haskell.org> References: <046.266af0561f46fb382b81907ac208339a@haskell.org> Message-ID: <061.bdb8dac75fb4422ec84ad158847ba987@haskell.org> #10870: PPC.Ppr: Shift by 32 bits is not allowed. ---------------------------------------+---------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (CodeGen) | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------------+---------------------------------- Changes (by trommler): * cc: trommler (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 12 19:31:19 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Sep 2015 19:31:19 -0000 Subject: [GHC] #10871: Implement "buildable" interface files which can be directly compiled without source In-Reply-To: <045.f4306fd46ddf30e7464e9ea8971267bf@haskell.org> References: <045.f4306fd46ddf30e7464e9ea8971267bf@haskell.org> Message-ID: <060.50bbfcf5396579999f780af044ff3c71@haskell.org> #10871: Implement "buildable" interface files which can be directly compiled without source -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by ezyang: Old description: > A fat interface file is like a normal hi file, but with extra information > so that GHC can *recompile* the associated module without having to > parse, rename and typecheck the source code again. The proposed command- > line interface is something like (subject to bikeshedding): > > {{{ > ghc -c A.hs -fno-code -fwrite-buildable-interface > # produces a .hi-build file, then > ghc -c A.hi-build > # completes building, as if ghc -c A.hs had been called > }}} > > The primary motivation for this is to support partially compiling > indefinite packages, which cannot be compiled to object code due to the > fact that some of the dependencies haven't been provided yet. However, > there are some other cases where this might be useful: > > 1. Supercompilation requires having the source of all bindings, buildable > interfaces can make this information available, even beyond what storing > inlinings might provide > 2. A buildable interface file can be used to build variants of a source, > e.g. profiling and optimization, even "on the fly" by GHC if necessary. > > And maybe more we haven't thought of yet. > > The primary function you need to implement is a function from > `ModIface`/`ModDetails` to `TcGblEnv`, which can then be fed to the > desugarer. I'm looking at what things we need to add to `ModIface` to > support this. New description: A fat interface file is like a normal hi file, but with extra information so that GHC can *recompile* the associated module without having to parse, rename and typecheck the source code again. The proposed command-line interface is something like (subject to bikeshedding): {{{ ghc -c A.hs -fno-code -fwrite-buildable-interface # produces a .hi-build file, then ghc -c A.hi-build # completes building, as if ghc -c A.hs had been called }}} The primary motivation for this is to support partially compiling indefinite packages, which cannot be compiled to object code due to the fact that some of the dependencies haven't been provided yet. However, there are some other cases where this might be useful: 1. Supercompilation requires having the source of all bindings, buildable interfaces can make this information available, even beyond what storing inlinings might provide 2. A buildable interface file can be used to build variants of a source, e.g. profiling and optimization, even "on the fly" by GHC if necessary. And maybe more we haven't thought of yet. Note: we DO run the desugarer before we write out the buildable interface (so we are essentially serializing a `ModGuts`, not a `TcGblEnv`). This does mean that you can't rebuild a buildable interface with hpc (that's done during desugaring) but that seems like a small price to pay. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 12 19:51:56 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Sep 2015 19:51:56 -0000 Subject: [GHC] #10871: Implement "buildable" interface files which can be directly compiled without source In-Reply-To: <045.f4306fd46ddf30e7464e9ea8971267bf@haskell.org> References: <045.f4306fd46ddf30e7464e9ea8971267bf@haskell.org> Message-ID: <060.e29fa8c605152bc04d5955e5405bee3b@haskell.org> #10871: Implement "buildable" interface files which can be directly compiled without source -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by ezyang: Old description: > A fat interface file is like a normal hi file, but with extra information > so that GHC can *recompile* the associated module without having to > parse, rename and typecheck the source code again. The proposed command- > line interface is something like (subject to bikeshedding): > > {{{ > ghc -c A.hs -fno-code -fwrite-buildable-interface > # produces a .hi-build file, then > ghc -c A.hi-build > # completes building, as if ghc -c A.hs had been called > }}} > > The primary motivation for this is to support partially compiling > indefinite packages, which cannot be compiled to object code due to the > fact that some of the dependencies haven't been provided yet. However, > there are some other cases where this might be useful: > > 1. Supercompilation requires having the source of all bindings, buildable > interfaces can make this information available, even beyond what storing > inlinings might provide > 2. A buildable interface file can be used to build variants of a source, > e.g. profiling and optimization, even "on the fly" by GHC if necessary. > > And maybe more we haven't thought of yet. > > Note: we DO run the desugarer before we write out the buildable interface > (so we are essentially serializing a `ModGuts`, not a `TcGblEnv`). This > does mean that you can't rebuild a buildable interface with hpc (that's > done during desugaring) but that seems like a small price to pay. New description: A fat interface file is like a normal hi file, but with extra information so that GHC can *recompile* the associated module without having to parse, rename and typecheck the source code again. The proposed command-line interface is something like (subject to bikeshedding): {{{ ghc -c A.hs -fno-code -fwrite-buildable-interface # produces a .hi-build file, then ghc -c A.hi-build # completes building, as if ghc -c A.hs had been called }}} The primary motivation for this is to support partially compiling indefinite packages, which cannot be compiled to object code due to the fact that some of the dependencies haven't been provided yet. However, there are some other cases where this might be useful: 1. Supercompilation requires having the source of all bindings, buildable interfaces can make this information available, even beyond what storing inlinings might provide 2. A buildable interface file can be used to build variants of a source, e.g. profiling and optimization, even "on the fly" by GHC if necessary. 3. GHCi can take advantage of information from buildable interface files to give more detailed information about otherwise "compiled" modules And maybe more we haven't thought of yet. Note: we DO run the desugarer before we write out the buildable interface (so we are essentially serializing a `ModGuts`, not a `TcGblEnv`). This does mean that you can't rebuild a buildable interface with hpc (that's done during desugaring) but that seems like a small price to pay. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 12 20:03:24 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Sep 2015 20:03:24 -0000 Subject: [GHC] #10653: PatternSynonyms should be imported/exported as part of the wildcard notation In-Reply-To: <049.0e5a3c33a167308dc99ecaed5730df14@haskell.org> References: <049.0e5a3c33a167308dc99ecaed5730df14@haskell.org> Message-ID: <064.e7e5f88151fa35d106d695e37233b15a@haskell.org> #10653: PatternSynonyms should be imported/exported as part of the wildcard notation -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: mpickering Type: feature request | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: pattern | synonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by mpickering): * priority: normal => high * owner: => mpickering Comment: I think this ticket is quite crucial to widespread usage of pattern synonyms. I will write up a design proposal on the wiki and post to ghc- devs for feedback. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 12 20:26:00 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Sep 2015 20:26:00 -0000 Subject: [GHC] #10873: Bad error message for incorrect pattern synonym signature Message-ID: <049.1015737e7e3a324fd7db7cc49a97b354@haskell.org> #10873: Bad error message for incorrect pattern synonym signature -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 (Type checker) | Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Consider the following program {{{ {-# LANGUAGE PatternSynonyms #-} pattern Pat :: Show a => () => a -> Maybe a pattern Pat a = Just a }}} GHC complains that {{{ test.hs:4:9: No instance for (Show a) arising from a pattern }}} I think this is quite difficult to understand. The problem is that matching on `Just a` doesn't provide the show constraint (it provides no constraints). A better error message here would explain this fact and maybe a short explanation of the difference between prov/req in a pattern synonym signature. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 12 21:26:46 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Sep 2015 21:26:46 -0000 Subject: [GHC] #7830: Error: operand out of range In-Reply-To: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> References: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> Message-ID: <059.2df619bd193f4b03929148318f8aaa22@haskell.org> #7830: Error: operand out of range -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Installing GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by erikd): The file is too big to attach (even Bzip2 compressed its over 300k where as the limited is 256k) so I made it available here: http://www.mega- nerd.com/erikd/PprC.s.bz2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 12 21:41:44 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Sep 2015 21:41:44 -0000 Subject: [GHC] #6037: Compile-time crash with sources with non-representable unicode characters In-Reply-To: <043.7207ef363a1d98123424aaa571c817fa@haskell.org> References: <043.7207ef363a1d98123424aaa571c817fa@haskell.org> Message-ID: <058.ca38d52777ed34bd5dacff826a4230ba@haskell.org> #6037: Compile-time crash with sources with non-representable unicode characters -------------------------------------+------------------------------------- Reporter: akio | Owner: snoyberg Type: bug | Status: merge Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: T6037 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"c8d438fb027cbefa31941d8397539c481a03a74f/ghc" c8d438f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c8d438fb027cbefa31941d8397539c481a03a74f" Testsuite: mark T6037 expect_fail on Windows (#6037) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 12 22:28:20 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Sep 2015 22:28:20 -0000 Subject: [GHC] #10796: Illegal data constructor name: `fromList' ... When splicing a TH expression In-Reply-To: <045.67153471687796395f900337ba5220e7@haskell.org> References: <045.67153471687796395f900337ba5220e7@haskell.org> Message-ID: <060.27b07faaa5bec747da97b18c2f2e0ad8@haskell.org> #10796: Illegal data constructor name: `fromList' ... When splicing a TH expression -------------------------------------+------------------------------------- Reporter: erisco | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.8.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * os: Windows => Unknown/Multiple * architecture: x86_64 (amd64) => Unknown/Multiple Comment: Not just Windows. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 12 23:51:41 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Sep 2015 23:51:41 -0000 Subject: [GHC] #10871: Implement "buildable" interface files which can be directly compiled without source In-Reply-To: <045.f4306fd46ddf30e7464e9ea8971267bf@haskell.org> References: <045.f4306fd46ddf30e7464e9ea8971267bf@haskell.org> Message-ID: <060.e5a7c91e34a2c630a41d9fb36dc7e8aa@haskell.org> #10871: Implement "buildable" interface files which can be directly compiled without source -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by ezyang: Old description: > A fat interface file is like a normal hi file, but with extra information > so that GHC can *recompile* the associated module without having to > parse, rename and typecheck the source code again. The proposed command- > line interface is something like (subject to bikeshedding): > > {{{ > ghc -c A.hs -fno-code -fwrite-buildable-interface > # produces a .hi-build file, then > ghc -c A.hi-build > # completes building, as if ghc -c A.hs had been called > }}} > > The primary motivation for this is to support partially compiling > indefinite packages, which cannot be compiled to object code due to the > fact that some of the dependencies haven't been provided yet. However, > there are some other cases where this might be useful: > > 1. Supercompilation requires having the source of all bindings, buildable > interfaces can make this information available, even beyond what storing > inlinings might provide > 2. A buildable interface file can be used to build variants of a source, > e.g. profiling and optimization, even "on the fly" by GHC if necessary. > 3. GHCi can take advantage of information from buildable interface files > to give more detailed information about otherwise "compiled" modules > > And maybe more we haven't thought of yet. > > Note: we DO run the desugarer before we write out the buildable interface > (so we are essentially serializing a `ModGuts`, not a `TcGblEnv`). This > does mean that you can't rebuild a buildable interface with hpc (that's > done during desugaring) but that seems like a small price to pay. New description: A fat interface file is like a normal hi file, but with extra information so that GHC can *recompile* the associated module without having to parse, rename and typecheck the source code again. The proposed command-line interface is something like (subject to bikeshedding): {{{ ghc -c A.hs -fno-code -fwrite-buildable-interface # produces a .hi-build file, then ghc -c A.hi-build # completes building, as if ghc -c A.hs had been called }}} The primary motivation for this is to support partially compiling indefinite packages, which cannot be compiled to object code due to the fact that some of the dependencies haven't been provided yet. However, there are some other cases where this might be useful: 1. Supercompilation requires having the source of all bindings, buildable interfaces can make this information available, even beyond what storing inlinings might provide 2. A buildable interface file can be used to build variants of a source, e.g. profiling and optimization, even "on the fly" by GHC if necessary. 3. GHCi can take advantage of information from buildable interface files to give more detailed information about otherwise "compiled" modules And maybe more we haven't thought of yet. Note: we DO run the desugarer before we write out the buildable interface (so we are essentially serializing a `ModGuts`, not a `TcGblEnv`). This does mean that you can't rebuild a buildable interface with hpc (that's done during desugaring) but that seems like a small price to pay. Question: should we tidy the Core bindings before serializing them out? This is only relevant for determining if `A.hi` files need to be rebuilt if `A.hi-build` changes: if we can avoid needless churn on `A.hi-build`, some `A.hi` files may not need to be rebuilt. However, we'd have to be pretty bang-on certain that the extra tidying phase wouldn't cause change in how we end up compiling things, which is unclear because tidying will drop things that might have been profitable during simplification, but are no longer profitable now. So the answer is probably no. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 13 07:10:23 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Sep 2015 07:10:23 -0000 Subject: [GHC] #10870: PPC.Ppr: Shift by 32 bits is not allowed. In-Reply-To: <046.266af0561f46fb382b81907ac208339a@haskell.org> References: <046.266af0561f46fb382b81907ac208339a@haskell.org> Message-ID: <061.4363d0654f1033f6fbfff7e4e2abf250@haskell.org> #10870: PPC.Ppr: Shift by 32 bits is not allowed. ---------------------------------------+---------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (CodeGen) | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------------+---------------------------------- Comment (by erikd): I'm currently working on the ghc-7.10 branch because the master branch currently does not compile on PowerPC due to #7830. I have a test program: {{{ import Data.Bits import Data.Int import Data.Word shift32R :: (Bits a, Num a) => a -> a shift32R x = unsafeShiftR x 32 main :: IO () main = do print $ map shift32R [ 123456, 0x7fffffff :: Int ] print $ map shift32R [ 123456, 0xffffffff :: Word ] print $ map shift32R [ 123456678, 123456678123456678 :: Int64 ] print $ map shift32R [ 123456678, 123456678123456678 :: Word64 ] }}} and I have a fix that seems to work (PowerPC output is same as for x86_64 and Arm), but the compiler prints 14 identical instances of the warning: {{{ WARNING: file compiler/simplCore/SimplEnv.hs, line 530 showl_a1O5 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 13 09:17:24 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Sep 2015 09:17:24 -0000 Subject: [GHC] #7253: Top-level bindings in ghci In-Reply-To: <048.88d72a7323b37dac89e81e376b48b907@haskell.org> References: <048.88d72a7323b37dac89e81e376b48b907@haskell.org> Message-ID: <063.8314facdf712ba561eadace44af6b9c9@haskell.org> #7253: Top-level bindings in ghci -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): See also this thread: https://mail.haskell.org/pipermail/ghc- devs/2015-August/009623.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 13 09:28:18 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Sep 2015 09:28:18 -0000 Subject: [GHC] #10870: PPC.Ppr: Shift by 32 bits is not allowed. In-Reply-To: <046.266af0561f46fb382b81907ac208339a@haskell.org> References: <046.266af0561f46fb382b81907ac208339a@haskell.org> Message-ID: <061.ae695163b1cef4c5a48c635a078d027f@haskell.org> #10870: PPC.Ppr: Shift by 32 bits is not allowed. ---------------------------------------+---------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (CodeGen) | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------------+---------------------------------- Comment (by erikd): Recompiled from scratch and the weird warning was gone. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 13 11:16:17 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Sep 2015 11:16:17 -0000 Subject: [GHC] #10874: Implement `:type-at`, `:all-types`, `:loc-at` in GHCi Message-ID: <042.bc0030991d1508d8ebcd4c859c529fc3@haskell.org> #10874: Implement `:type-at`, `:all-types`, `:loc-at` in GHCi -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- We missed the opportunity to merge this for GHC 7.10 but I hope this can make it for GHC 8.0 See https://github.com/chrisdone/ghci-ng/blob/master/README.md for a description of the new GHCi commands I've started rebasing the changes from Chris' ghci-ng repo against GHC HEAD and pushed the work-in-progress state as branch `wip/T10874`. One blocker right now is the use of SYB to traverse the AST which I don't want to drag into GHC as a dependency. So one thing that needs to be done is rewrite those 20 lines of code without relying on SYB. Other than that some minor polishing needs to be done. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 13 11:21:22 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Sep 2015 11:21:22 -0000 Subject: [GHC] #10653: PatternSynonyms should be imported/exported as part of the wildcard notation In-Reply-To: <049.0e5a3c33a167308dc99ecaed5730df14@haskell.org> References: <049.0e5a3c33a167308dc99ecaed5730df14@haskell.org> Message-ID: <064.ed2c739a88fa93b077357227bba89086@haskell.org> #10653: PatternSynonyms should be imported/exported as part of the wildcard notation -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: mpickering Type: feature request | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: pattern | synonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by mpickering): Reid, Your example is not a valid bidirectional synonym as the RHS contains a view pattern. You are right that such synonyms can exist though. Here is an example. {{{ {-# LANGUAGE PatternSynonyms, ViewPatterns #-} module Foo where class C f where build :: a -> f a destruct :: f a -> a pattern P :: () => C f => a -> f a pattern P x <- (destruct -> x) where P x = build x }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 13 12:33:56 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Sep 2015 12:33:56 -0000 Subject: [GHC] #10653: PatternSynonyms should be imported/exported as part of the wildcard notation In-Reply-To: <049.0e5a3c33a167308dc99ecaed5730df14@haskell.org> References: <049.0e5a3c33a167308dc99ecaed5730df14@haskell.org> Message-ID: <064.75e501cc661d9d990ff511933661991f@haskell.org> #10653: PatternSynonyms should be imported/exported as part of the wildcard notation -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: mpickering Type: feature request | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: pattern | synonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by mpickering): I have added a [https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms#Associatingsynonymswithtypes section] to the wiki summarising this issue. I will start to work on an implementation based on Richard's idea if this doesn't seem to be too magical. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 13 15:30:33 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Sep 2015 15:30:33 -0000 Subject: [GHC] #10874: Implement `:type-at`, `:all-types`, `:loc-at` in GHCi In-Reply-To: <042.bc0030991d1508d8ebcd4c859c529fc3@haskell.org> References: <042.bc0030991d1508d8ebcd4c859c529fc3@haskell.org> Message-ID: <057.52f217c8d423e4fdf008b7f0d4d8406e@haskell.org> #10874: Implement `:type-at`, `:all-types`, `:loc-at` in GHCi -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1240 -------------------------------------+------------------------------------- Changes (by hvr): * status: new => patch * differential: => Phab:D1240 Old description: > We missed the opportunity to merge this for GHC 7.10 but I hope this can > make it for GHC 8.0 > > See https://github.com/chrisdone/ghci-ng/blob/master/README.md for a > description of the new GHCi commands > > I've started rebasing the changes from Chris' ghci-ng repo against GHC > HEAD and pushed the work-in-progress state as branch `wip/T10874`. > > One blocker right now is the use of SYB to traverse the AST which I don't > want to drag into GHC as a dependency. So one thing that needs to be done > is rewrite those 20 lines of code without relying on SYB. > > Other than that some minor polishing needs to be done. New description: We missed the opportunity to merge this for GHC 7.10 but I hope this can make it for GHC 8.0 See https://github.com/chrisdone/ghci-ng/blob/master/README.md for a description of the new GHCi commands -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 13 15:47:51 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Sep 2015 15:47:51 -0000 Subject: [GHC] #10847: :info should print minimal definition In-Reply-To: <043.c6e083f7f51bc9197fc9d4b0280ca574@haskell.org> References: <043.c6e083f7f51bc9197fc9d4b0280ca574@haskell.org> Message-ID: <058.e9e0f2b75e2203cf0d3596c4623d5191@haskell.org> #10847: :info should print minimal definition -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: GHCi | Version: 7.11 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by cocreature): Hey, I'd like to take a stab at this. I am a newcomer but I managed to get a prototype working, so it should mostly be the case of changing the formatting and adding a testcase. I'll try to send a patch in the next weeks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 13 15:48:13 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Sep 2015 15:48:13 -0000 Subject: [GHC] #10847: :info should print minimal definition In-Reply-To: <043.c6e083f7f51bc9197fc9d4b0280ca574@haskell.org> References: <043.c6e083f7f51bc9197fc9d4b0280ca574@haskell.org> Message-ID: <058.14799d232c0f26e9ca2b08e3d0fcc426@haskell.org> #10847: :info should print minimal definition -------------------------------------+------------------------------------- Reporter: osa1 | Owner: cocreature Type: feature request | Status: new Priority: lowest | Milestone: Component: GHCi | Version: 7.11 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by cocreature): * owner: => cocreature -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 13 16:57:26 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Sep 2015 16:57:26 -0000 Subject: [GHC] #10623: Handling of ASCII encodings introduced in D898 breaks Unicode terminal detection In-Reply-To: <046.3a764cfd54e5a4e4443ef4864c8fddbf@haskell.org> References: <046.3a764cfd54e5a4e4443ef4864c8fddbf@haskell.org> Message-ID: <061.dc5ed06109a69803e792f3f5010f0f33@haskell.org> #10623: Handling of ASCII encodings introduced in D898 breaks Unicode terminal detection -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T8958a Blocked By: | Blocking: Related Tickets: #10298, #7695 | Differential Revisions: | Phab:D1059, Phab:D1085 -------------------------------------+------------------------------------- Comment (by rwbarton): It's not a regression, just a new test (I added it in dbe6dac96543f426297a59d8d16c3f5afacf42d4). The test uses `mkTextEncoding "ASCII"` which clearly (if you read `GHC.IO.Encoding.mkTextEncoding'`) won't work on Windows. It didn't work in the past either except between e28462de700240288519a016d0fe44d4360d9ffd and d69dfba4e27c4ec33459906fd87c9a56a371f510. Should we make it work, i.e., handle encodings in our hard-coded list as ASCII on Windows too? Personally I don't see why not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 13 17:01:40 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Sep 2015 17:01:40 -0000 Subject: [GHC] #10863: "hello world" produces illegal instruction error In-Reply-To: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> References: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> Message-ID: <061.f69732ac7b834633b1132ee616f36064@haskell.org> #10863: "hello world" produces illegal instruction error ----------------------------------+--------------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------+--------------------------------- Comment (by rwbarton): Thanks for the report. Could you also try running the crashing executable under gdb and attach the output of `bt`, `disas` and `info reg`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 13 17:21:51 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Sep 2015 17:21:51 -0000 Subject: [GHC] #10831: Document conditions on deriving Functor In-Reply-To: <048.8298ed09a98386a50539acd12ba36fa5@haskell.org> References: <048.8298ed09a98386a50539acd12ba36fa5@haskell.org> Message-ID: <063.e8484dbe5002440ac778bbf94d61f5d7@haskell.org> #10831: Document conditions on deriving Functor -------------------------------------+------------------------------------- Reporter: htebalaka | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): Replying to [comment:4 RyanGlScott]: > Replying to [comment:3 simonpj]: > > But I think we still lack a user-oriented specification, and such a thing would be tremendously welcome. > > What exactly would we want from a "user-oriented specification"? Do we want to see the compile-time error messages improved? Or do we want to see particular portions of the Commentary page and/or users' guide fleshed out? The user's guide should contain an explanation sufficient for a user to understand what types will and will not work with deriving Functor. Ideally this should contain examples of both sorts. The wiki is intended for developer-facing documentation; users shouldn't have to consult the wiki to find out how to use a feature. I think the errors (at least the error appearing in this ticket; I haven't looked at others if there are any) are fine, assuming that there is documentation added to the user's guide that explains in more detail what is wrong here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 13 17:22:52 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Sep 2015 17:22:52 -0000 Subject: [GHC] #10682: AArch64: dll-split: out of memory (requested 1099512676352 bytes) In-Reply-To: <044.b28ef9f55aa85f3be9d617cd7c0f70a5@haskell.org> References: <044.b28ef9f55aa85f3be9d617cd7c0f70a5@haskell.org> Message-ID: <059.4071454fe55b466a30a547c8b987fc40@haskell.org> #10682: AArch64: dll-split: out of memory (requested 1099512676352 bytes) -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1171 -------------------------------------+------------------------------------- Comment (by rwbarton): So, this is fixed right? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 13 17:25:52 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Sep 2015 17:25:52 -0000 Subject: [GHC] #10831: Document conditions on deriving Functor In-Reply-To: <048.8298ed09a98386a50539acd12ba36fa5@haskell.org> References: <048.8298ed09a98386a50539acd12ba36fa5@haskell.org> Message-ID: <063.19bbc3bdc47dea8fa9ed9535893c0043@haskell.org> #10831: Document conditions on deriving Functor -------------------------------------+------------------------------------- Reporter: htebalaka | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by RyanGlScott): > The user's guide should contain an explanation sufficient for a user to understand what types will and will not work with deriving Functor. Ideally this should contain examples of both sorts. > > The wiki is intended for developer-facing documentation; users shouldn't have to consult the wiki to find out how to use a feature. OK, that makes sense. I definitely got a bit lazy by the time I got to the users' guide and more-or-less copypasted what was in the wiki?I'll try to address this when I get a chance. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 13 17:33:22 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Sep 2015 17:33:22 -0000 Subject: [GHC] #9221: (super!) linear slowdown of parallel builds on 40 core machine In-Reply-To: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> References: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> Message-ID: <060.34790f1f654c6fdd32ac14c246e35a8c@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #910, #8224 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by slyfox): Didin't try to inspect thunks for TSOs yet. Another datapoint: Built whole GHC with ```SRC_HC_OPTS += -feager-blackholing``` and ran on the same source from comment 28 with ```-j${i} +RTS -A128M >/dev/null```. The best wall-clock (real) result is achieved on -j8 (for box with 8 logical cores!) {{{ $ for i in `seq 1 40`; do echo "running $i"; time ./mk.bash -j${i} +RTS -A128M >/dev/null; done running 1 real 0m45.510s user 0m41.844s sys 0m2.699s running 2 real 0m26.609s user 0m42.121s sys 0m4.227s running 3 real 0m20.976s user 0m47.452s sys 0m5.892s running 4 real 0m18.391s user 0m48.771s sys 0m7.716s running 5 real 0m16.504s user 0m53.015s sys 0m9.339s running 6 real 0m16.108s user 0m59.391s sys 0m12.256s running 7 real 0m15.845s user 1m3.952s sys 0m15.632s running 8 real 0m15.163s user 1m9.096s sys 0m14.940s running 9 real 0m15.693s user 1m11.332s sys 0m17.059s running 10 real 0m16.155s user 1m13.646s sys 0m18.863s running 11 real 0m16.595s user 1m16.520s sys 0m19.622s running 12 real 0m19.407s user 1m18.191s sys 0m22.702s running 13 real 0m17.047s user 1m18.216s sys 0m22.033s running 14 real 0m17.668s user 1m19.592s sys 0m24.237s running 15 real 0m18.087s user 1m21.217s sys 0m26.945s running 16 real 0m18.304s user 1m21.447s sys 0m28.425s running 17 real 0m18.912s user 1m23.788s sys 0m29.615s running 18 real 0m19.715s user 1m24.838s sys 0m32.569s running 19 real 0m20.534s user 1m25.534s sys 0m31.648s running 20 real 0m21.440s user 1m27.836s sys 0m42.114s }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 13 17:58:09 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Sep 2015 17:58:09 -0000 Subject: [GHC] #8326: Place heap checks common in case alternatives before the case In-Reply-To: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> References: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> Message-ID: <063.9d371f952bbc183ce423f338894fae1d@haskell.org> #8326: Place heap checks common in case alternatives before the case -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: 8317 Related Tickets: #1498 | Differential Revisions: Phab:D343 -------------------------------------+------------------------------------- Comment (by rwbarton): I ran a nofib benchmark with these changes and there was mostly no effect, aside from a few changes in the plus-or-minus 5-10% range that I could not explain. When I find a larger block of free time I'll return to this subject (should be more pleasant now that ghcspeed will benchmark wip branches). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 13 18:44:40 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Sep 2015 18:44:40 -0000 Subject: [GHC] #10875: Unexpected defaulting of partial type signatures and inconsistent behaviour when -fdefer-typed-holes is set. Message-ID: <047.47e931d5fc4e6515630dc5cf2498378f@haskell.org> #10875: Unexpected defaulting of partial type signatures and inconsistent behaviour when -fdefer-typed-holes is set. -------------------------------------+------------------------------------- Reporter: holzensp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: MacOS X PartialTypeSignatures TypedHoles | Architecture: x86_64 | Type of failure: Incorrect (amd64) | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Maybe this should be one bug report and one feature request, but for now, I'll report them together. Consider the following program: {{{#!hs {-#LANGUAGE PartialTypeSignatures #-} {-#LANGUAGE NamedWildCards #-} {-#LANGUAGE NoMonomorphismRestriction #-} foo :: _ => _outer foo x = round $ (undefined::_inner) (1 + x) }}} This produces the following output in GHCi: {{{ Foo.hs:5:8: Warning: Found hole ?_? with inferred constraints: (Integral b, Num a) In the type signature for ?foo?: _ => _outer Foo.hs:5:13: Warning: Found hole ?_outer? with type: a -> b Where: ?b? is a rigid type variable bound by the inferred type of foo :: (Integral b, Num a) => a -> b at Foo.hs:6:1 ?a? is a rigid type variable bound by the inferred type of foo :: (Integral b, Num a) => a -> b at Foo.hs:6:1 In the type signature for ?foo?: _ => _outer Foo.hs:6:29: Warning: Found hole ?_inner? with type: a -> Double Where: ?a? is a rigid type variable bound by the inferred type of foo :: (Integral b, Num a) => a -> b at Foo.hs:6:1 Relevant bindings include x :: a (bound at Foo.hs:6:5) foo :: a -> b (bound at Foo.hs:6:1) In an expression type signature: _inner In the expression: undefined :: _inner In the second argument of ?($)?, namely ?(undefined :: _inner) (1 + x)? Ok, modules loaded: Main. }}} The inferred constraints for `_` (which I can't give a name, unfortunately) and the type reported in place of `_outer` are exactly what I expected. The type for `_inner` surprises me. Okay, the type is ambiguous, so for anything as general as `undefined`, arguably, it would need to default to something. Let's use a typed hole instead of `undefined`: {{{#!hs foo :: _ => _outer foo x = round $ _hole (1 + x) }}} gives {{{ Foo.hs:6:17: Found hole ?_hole? with type: a -> Double Where: ?a? is a rigid type variable bound by the inferred type of foo :: a -> b at Foo.hs:6:1 Relevant bindings include x :: a (bound at Foo.hs:6:5) foo :: a -> b (bound at Foo.hs:6:1) In the expression: _hole In the second argument of ?($)?, namely ?_hole (1 + x)? In the expression: round $ _hole (1 + x) Failed, modules loaded: none. }}} Holy Guacamole, it still defaults to `Double`. I would consider this a bug, because GHC is telling me, that whatever I put there must result in a `Double`, which is too restrictive to be true. However, I seem to recall from the OutsideIn paper that there were some cases, even without GADTs, where principality was difficult. Was this one of them? Moving on, I was actually trying to get all my holes typed for me in one compiler execution. GHC behaves according to spec; typed holes produce errors by default and when something breaks on an error, it doesn't produce the warnings for partial type signatures. Let's `-fdefer-typed- holes` and compile again: {{{ Prelude> :set -fdefer-typed-holes Prelude> :r [1 of 1] Compiling Main ( Foo.hs, interpreted ) Foo.hs:5:8: Warning: Found hole ?_? with inferred constraints: () In the type signature for ?foo?: _ => _outer Foo.hs:5:13: Warning: Found hole ?_outer? with type: a -> b Where: ?b? is a rigid type variable bound by the inferred type of foo :: a -> b at Foo.hs:6:1 ?a? is a rigid type variable bound by the inferred type of foo :: a -> b at Foo.hs:6:1 In the type signature for ?foo?: _ => _outer Foo.hs:6:17: Warning: Found hole ?_hole? with type: a -> Double Where: ?a? is a rigid type variable bound by the inferred type of foo :: a -> b at Foo.hs:6:1 Relevant bindings include x :: a (bound at Foo.hs:6:5) foo :: a -> b (bound at Foo.hs:6:1) In the expression: _hole In the second argument of ?($)?, namely ?_hole (1 + x)? In the expression: round $ _hole (1 + x) Ok, modules loaded: Main. }}} Surely, this must be wrong. Suddenly `()` is the inferred set of constraints and an unconstrained `a -> b` will do for `_outer`. I would argue that the `1 +` still demainds `Num a`, even if `round`'s `RealFrac` constraint is satisfied by `_hole` producing a `Double`. As said, maybe the erroneous types reported when `-fdefer-typed-holes` are a separate issue from the type of `_hole` not being the principal type, but I'm unsure, so I reported them together. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 13 19:27:40 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Sep 2015 19:27:40 -0000 Subject: [GHC] #8326: Place heap checks common in case alternatives before the case In-Reply-To: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> References: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> Message-ID: <063.f3a87a756ab6f93c7b5b2102883a163b@haskell.org> #8326: Place heap checks common in case alternatives before the case -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: 8317 Related Tickets: #1498 | Differential Revisions: Phab:D343 -------------------------------------+------------------------------------- Comment (by jstolarek): Replying to [comment:37 rwbarton]: > a few changes in the plus-or-minus 5-10% range that I could not explain Random idea: check ordering of assembly blocks (a.k.a #8082) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 13 19:50:38 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Sep 2015 19:50:38 -0000 Subject: [GHC] #10682: AArch64: dll-split: out of memory (requested 1099512676352 bytes) In-Reply-To: <044.b28ef9f55aa85f3be9d617cd7c0f70a5@haskell.org> References: <044.b28ef9f55aa85f3be9d617cd7c0f70a5@haskell.org> Message-ID: <059.3a2cadd6652d4c2b4f63663839c4068e@haskell.org> #10682: AArch64: dll-split: out of memory (requested 1099512676352 bytes) -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1171 -------------------------------------+------------------------------------- Changes (by erikd): * status: patch => closed * resolution: => fixed Comment: Sorry, yes it is. Closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 13 20:17:43 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Sep 2015 20:17:43 -0000 Subject: [GHC] #10682: AArch64: dll-split: out of memory (requested 1099512676352 bytes) In-Reply-To: <044.b28ef9f55aa85f3be9d617cd7c0f70a5@haskell.org> References: <044.b28ef9f55aa85f3be9d617cd7c0f70a5@haskell.org> Message-ID: <059.ad65cbd51c62a5339cee0454502182aa@haskell.org> #10682: AArch64: dll-split: out of memory (requested 1099512676352 bytes) -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1171 -------------------------------------+------------------------------------- Comment (by RyanGlScott): This is still happening to me on an x86_64 machine: {{{ inplace/bin/dll-split compiler/stage2/build/.depend-v-dyn.haskell "DynFlags" "Annotations ApiAnnotation Avail Bag BasicTypes Binary BooleanFormula BreakArray BufWrite Class CmdLineParser CmmType CoAxiom ConLike Coercion Config Constants CoreArity CoreFVs CoreSubst CoreSyn CoreTidy CoreUnfold CoreUtils CoreSeq CoreStats CostCentre Ctype DataCon Demand Digraph DriverPhases DynFlags Encoding ErrUtils Exception FamInstEnv FastFunctions FastMutInt FastString Fingerprint FiniteMap ForeignCall Hooks HsBinds HsDecls HsDoc HsExpr HsImpExp HsLit PlaceHolder HsPat HsSyn HsTypes HsUtils HscTypes IOEnv Id IdInfo IfaceSyn IfaceType InstEnv Kind Lexeme Lexer ListSetOps Literal Maybes MkCore MkId Module MonadUtils Name NameEnv NameSet OccName OccurAnal OptCoercion OrdList Outputable PackageConfig Packages Pair Panic PatSyn PipelineMonad Platform PlatformConstants PprCore PrelNames PrelRules Pretty PrimOp RdrName Rules Serialized SrcLoc StaticFlags StringBuffer TcEvidence TcRnTypes TcType TrieMap TyCon Type TypeRep TysPrim TysWiredIn Unify UniqFM UniqSet UniqSupply Unique Util Var VarEnv VarSet Bitmap BlockId ByteCodeAsm ByteCodeInstr ByteCodeItbls CLabel Cmm CmmCallConv CmmExpr CmmInfo CmmMachOp CmmNode CmmSwitch CmmUtils CodeGen.Platform CodeGen.Platform.ARM CodeGen.Platform.ARM64 CodeGen.Platform.NoRegs CodeGen.Platform.PPC CodeGen.Platform.PPC_Darwin CodeGen.Platform.SPARC CodeGen.Platform.X86 CodeGen.Platform.X86_64 Hoopl Hoopl.Dataflow InteractiveEvalTypes MkGraph PprCmm PprCmmDecl PprCmmExpr Reg RegClass SMRep StgCmmArgRep StgCmmClosure StgCmmEnv StgCmmLayout StgCmmMonad StgCmmProf StgCmmTicky StgCmmUtils StgSyn Stream" dll-split: out of memory (requested 1099512676352 bytes) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 13 20:21:27 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Sep 2015 20:21:27 -0000 Subject: [GHC] #10876: stack overflow regression Message-ID: <044.3685b2599dc5dd8fb0cf47784fa834c3@haskell.org> #10876: stack overflow regression -------------------------------------+------------------------------------- Reporter: dmwit | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- I would like to teach GHC that `<=` is transitive. I tried a module that looks like this: {{{#!hs {-# LANGUAGE GADTs, Rank2Types, TypeOperators #-} import GHC.TypeLits trans :: (a <= b, b <= c) => ((a <= c) => d) -> d trans = undefined }}} In 7.8, this is a type error; in 7.10 the compiler thinks a long time before emitting a stack overflow exception. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 13 20:25:18 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Sep 2015 20:25:18 -0000 Subject: [GHC] #10682: AArch64: dll-split: out of memory (requested 1099512676352 bytes) In-Reply-To: <044.b28ef9f55aa85f3be9d617cd7c0f70a5@haskell.org> References: <044.b28ef9f55aa85f3be9d617cd7c0f70a5@haskell.org> Message-ID: <059.70e126b4b9f53f9c3ddd4e5f1139f49a@haskell.org> #10682: AArch64: dll-split: out of memory (requested 1099512676352 bytes) -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1171 -------------------------------------+------------------------------------- Comment (by rwbarton): This ticket is about aarch64, could you file another ticket? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 13 20:29:33 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Sep 2015 20:29:33 -0000 Subject: [GHC] #10877: x86_64: dll-split: out of memory (requested 1099512676352 bytes) Message-ID: <050.ab3ee9d3ff60499476bc10d829ff13d9@haskell.org> #10877: x86_64: dll-split: out of memory (requested 1099512676352 bytes) -------------------------------------+------------------------------------- Reporter: | Owner: RyanGlScott | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Building GHC (amd64) | failed Test Case: | Blocked By: Blocking: | Related Tickets: #10682 Differential Revisions: | -------------------------------------+------------------------------------- Attempting to build GHC on an x86_64 Linux machine fails for me: {{{ $ make ===--- building phase 0 make --no-print-directory -f ghc.mk phase=0 phase_0_builds make[1]: Nothing to be done for `phase_0_builds'. ===--- building phase 1 make --no-print-directory -f ghc.mk phase=1 phase_1_builds make[1]: Nothing to be done for `phase_1_builds'. ===--- building final phase make --no-print-directory -f ghc.mk phase=final all inplace/bin/dll-split compiler/stage2/build/.depend-v-dyn.haskell "DynFlags" "Annotations ApiAnnotation Avail Bag BasicTypes Binary BooleanFormula BreakArray BufWrite Class CmdLineParser CmmType CoAxiom ConLike Coercion Config Constants CoreArity CoreFVs CoreSubst CoreSyn CoreTidy CoreUnfold CoreUtils CoreSeq CoreStats CostCentre Ctype DataCon Demand Digraph DriverPhases DynFlags Encoding ErrUtils Exception FamInstEnv FastFunctions FastMutInt FastString Fingerprint FiniteMap ForeignCall Hooks HsBinds HsDecls HsDoc HsExpr HsImpExp HsLit PlaceHolder HsPat HsSyn HsTypes HsUtils HscTypes IOEnv Id IdInfo IfaceSyn IfaceType InstEnv Kind Lexeme Lexer ListSetOps Literal Maybes MkCore MkId Module MonadUtils Name NameEnv NameSet OccName OccurAnal OptCoercion OrdList Outputable PackageConfig Packages Pair Panic PatSyn PipelineMonad Platform PlatformConstants PprCore PrelNames PrelRules Pretty PrimOp RdrName Rules Serialized SrcLoc StaticFlags StringBuffer TcEvidence TcRnTypes TcType TrieMap TyCon Type TypeRep TysPrim TysWiredIn Unify UniqFM UniqSet UniqSupply Unique Util Var VarEnv VarSet Bitmap BlockId ByteCodeAsm ByteCodeInstr ByteCodeItbls CLabel Cmm CmmCallConv CmmExpr CmmInfo CmmMachOp CmmNode CmmSwitch CmmUtils CodeGen.Platform CodeGen.Platform.ARM CodeGen.Platform.ARM64 CodeGen.Platform.NoRegs CodeGen.Platform.PPC CodeGen.Platform.PPC_Darwin CodeGen.Platform.SPARC CodeGen.Platform.X86 CodeGen.Platform.X86_64 Hoopl Hoopl.Dataflow InteractiveEvalTypes MkGraph PprCmm PprCmmDecl PprCmmExpr Reg RegClass SMRep StgCmmArgRep StgCmmClosure StgCmmEnv StgCmmLayout StgCmmMonad StgCmmProf StgCmmTicky StgCmmUtils StgSyn Stream" dll-split: out of memory (requested 1099512676352 bytes) make[1]: *** [compiler/stage2/dll-split.stamp] Error 1 make: *** [all] Error 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 13 20:29:57 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Sep 2015 20:29:57 -0000 Subject: [GHC] #10682: AArch64: dll-split: out of memory (requested 1099512676352 bytes) In-Reply-To: <044.b28ef9f55aa85f3be9d617cd7c0f70a5@haskell.org> References: <044.b28ef9f55aa85f3be9d617cd7c0f70a5@haskell.org> Message-ID: <059.fe54276935e60b6d6d5d7429532203dc@haskell.org> #10682: AArch64: dll-split: out of memory (requested 1099512676352 bytes) -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: #10877 | Differential Revisions: Phab:D1171 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #10877 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 13 20:47:09 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Sep 2015 20:47:09 -0000 Subject: [GHC] #10875: Unexpected defaulting of partial type signatures and inconsistent behaviour when -fdefer-typed-holes is set. In-Reply-To: <047.47e931d5fc4e6515630dc5cf2498378f@haskell.org> References: <047.47e931d5fc4e6515630dc5cf2498378f@haskell.org> Message-ID: <062.9c2eb0bfb9270eb7c081ec125b7d61b6@haskell.org> #10875: Unexpected defaulting of partial type signatures and inconsistent behaviour when -fdefer-typed-holes is set. -------------------------------------+------------------------------------- Reporter: holzensp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | PartialTypeSignatures TypedHoles Operating System: MacOS X | Architecture: x86_64 Type of failure: Incorrect | (amd64) warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by holzensp: Old description: > Maybe this should be one bug report and one feature request, but for now, > I'll report them together. Consider the following program: > {{{#!hs > {-#LANGUAGE PartialTypeSignatures #-} > {-#LANGUAGE NamedWildCards #-} > {-#LANGUAGE NoMonomorphismRestriction #-} > > foo :: _ => _outer > foo x = round $ (undefined::_inner) (1 + x) > }}} > This produces the following output in GHCi: > {{{ > Foo.hs:5:8: Warning: > Found hole ?_? with inferred constraints: (Integral b, Num a) > In the type signature for ?foo?: _ => _outer > > Foo.hs:5:13: Warning: > Found hole ?_outer? with type: a -> b > Where: ?b? is a rigid type variable bound by > the inferred type of foo :: (Integral b, Num a) => a -> b > at Foo.hs:6:1 > ?a? is a rigid type variable bound by > the inferred type of foo :: (Integral b, Num a) => a -> b > at Foo.hs:6:1 > In the type signature for ?foo?: _ => _outer > > Foo.hs:6:29: Warning: > Found hole ?_inner? with type: a -> Double > Where: ?a? is a rigid type variable bound by > the inferred type of foo :: (Integral b, Num a) => a -> b > at Foo.hs:6:1 > Relevant bindings include > x :: a (bound at Foo.hs:6:5) > foo :: a -> b (bound at Foo.hs:6:1) > In an expression type signature: _inner > In the expression: undefined :: _inner > In the second argument of ?($)?, namely > ?(undefined :: _inner) (1 + x)? > Ok, modules loaded: Main. > }}} > The inferred constraints for `_` (which I can't give a name, > unfortunately) and the type reported in place of `_outer` are exactly > what I expected. The type for `_inner` surprises me. Okay, the type is > ambiguous, so for anything as general as `undefined`, arguably, it would > need to default to something. > > Let's use a typed hole instead of `undefined`: > {{{#!hs > foo :: _ => _outer > foo x = round $ _hole (1 + x) > }}} > gives > {{{ > Foo.hs:6:17: > Found hole ?_hole? with type: a -> Double > Where: ?a? is a rigid type variable bound by > the inferred type of foo :: a -> b at Foo.hs:6:1 > Relevant bindings include > x :: a (bound at Foo.hs:6:5) > foo :: a -> b (bound at Foo.hs:6:1) > In the expression: _hole > In the second argument of ?($)?, namely ?_hole (1 + x)? > In the expression: round $ _hole (1 + x) > Failed, modules loaded: none. > }}} > Holy Guacamole, it still defaults to `Double`. I would consider this a > bug, because GHC is telling me, that whatever I put there must result in > a `Double`, which is too restrictive to be true. However, I seem to > recall from the OutsideIn paper that there were some cases, even without > GADTs, where principality was difficult. Was this one of them? > > Moving on, I was actually trying to get all my holes typed for me in one > compiler execution. GHC behaves according to spec; typed holes produce > errors by default and when something breaks on an error, it doesn't > produce the warnings for partial type signatures. Let's `-fdefer-typed- > holes` and compile again: > {{{ > Prelude> :set -fdefer-typed-holes > Prelude> :r > [1 of 1] Compiling Main ( Foo.hs, interpreted ) > > Foo.hs:5:8: Warning: > Found hole ?_? with inferred constraints: () > In the type signature for ?foo?: _ => _outer > > Foo.hs:5:13: Warning: > Found hole ?_outer? with type: a -> b > Where: ?b? is a rigid type variable bound by > the inferred type of foo :: a -> b at Foo.hs:6:1 > ?a? is a rigid type variable bound by > the inferred type of foo :: a -> b at Foo.hs:6:1 > In the type signature for ?foo?: _ => _outer > > Foo.hs:6:17: Warning: > Found hole ?_hole? with type: a -> Double > Where: ?a? is a rigid type variable bound by > the inferred type of foo :: a -> b at Foo.hs:6:1 > Relevant bindings include > x :: a (bound at Foo.hs:6:5) > foo :: a -> b (bound at Foo.hs:6:1) > In the expression: _hole > In the second argument of ?($)?, namely ?_hole (1 + x)? > In the expression: round $ _hole (1 + x) > Ok, modules loaded: Main. > }}} > Surely, this must be wrong. Suddenly `()` is the inferred set of > constraints and an unconstrained `a -> b` will do for `_outer`. I would > argue that the `1 +` still demainds `Num a`, even if `round`'s `RealFrac` > constraint is satisfied by `_hole` producing a `Double`. > > As said, maybe the erroneous types reported when `-fdefer-typed-holes` > are a separate issue from the type of `_hole` not being the principal > type, but I'm unsure, so I reported them together. New description: Maybe this should be one bug report and one feature request, but for now, I'll report them together. Consider the following program: {{{#!hs {-#LANGUAGE PartialTypeSignatures #-} {-#LANGUAGE NamedWildCards #-} {-#LANGUAGE NoMonomorphismRestriction #-} foo :: _ => _outer foo x = round $ (undefined::_inner) (1 + x) }}} This produces the following output in GHCi: {{{ Foo.hs:5:8: Warning: Found hole ?_? with inferred constraints: (Integral b, Num a) In the type signature for ?foo?: _ => _outer Foo.hs:5:13: Warning: Found hole ?_outer? with type: a -> b Where: ?b? is a rigid type variable bound by the inferred type of foo :: (Integral b, Num a) => a -> b at Foo.hs:6:1 ?a? is a rigid type variable bound by the inferred type of foo :: (Integral b, Num a) => a -> b at Foo.hs:6:1 In the type signature for ?foo?: _ => _outer Foo.hs:6:29: Warning: Found hole ?_inner? with type: a -> Double Where: ?a? is a rigid type variable bound by the inferred type of foo :: (Integral b, Num a) => a -> b at Foo.hs:6:1 Relevant bindings include x :: a (bound at Foo.hs:6:5) foo :: a -> b (bound at Foo.hs:6:1) In an expression type signature: _inner In the expression: undefined :: _inner In the second argument of ?($)?, namely ?(undefined :: _inner) (1 + x)? Ok, modules loaded: Main. }}} The inferred constraints for `_` (which I can't give a name, unfortunately) and the type reported in place of `_outer` are exactly what I expected. The type for `_inner` surprises me. Okay, the type is ambiguous, so for anything as general as `undefined`, arguably, it would need to default to something. Let's use a typed hole instead of `undefined`: {{{#!hs foo :: _ => _outer foo x = round $ _hole (1 + x) }}} gives {{{ Foo.hs:6:17: Found hole ?_hole? with type: a -> Double Where: ?a? is a rigid type variable bound by the inferred type of foo :: a -> b at Foo.hs:6:1 Relevant bindings include x :: a (bound at Foo.hs:6:5) foo :: a -> b (bound at Foo.hs:6:1) In the expression: _hole In the second argument of ?($)?, namely ?_hole (1 + x)? In the expression: round $ _hole (1 + x) Failed, modules loaded: none. }}} Holy Guacamole, it still defaults to `Double`. I would consider this a bug, because GHC is telling me, that whatever I put there must result in a `Double`, which is too restrictive to be true. However, I seem to recall from the OutsideIn paper that there were some cases, even without GADTs, where principality was difficult. Was this one of them? Moving on, I was actually trying to get all my holes typed for me in one compiler execution. GHC behaves according to spec; typed holes produce errors by default and when something breaks on an error, it doesn't produce the warnings for partial type signatures. Let's `-fdefer-typed- holes` and compile again: {{{ Prelude> :set -fdefer-typed-holes Prelude> :r [1 of 1] Compiling Main ( Foo.hs, interpreted ) Foo.hs:5:8: Warning: Found hole ?_? with inferred constraints: () In the type signature for ?foo?: _ => _outer Foo.hs:5:13: Warning: Found hole ?_outer? with type: a -> b Where: ?b? is a rigid type variable bound by the inferred type of foo :: a -> b at Foo.hs:6:1 ?a? is a rigid type variable bound by the inferred type of foo :: a -> b at Foo.hs:6:1 In the type signature for ?foo?: _ => _outer Foo.hs:6:17: Warning: Found hole ?_hole? with type: a -> Double Where: ?a? is a rigid type variable bound by the inferred type of foo :: a -> b at Foo.hs:6:1 Relevant bindings include x :: a (bound at Foo.hs:6:5) foo :: a -> b (bound at Foo.hs:6:1) In the expression: _hole In the second argument of ?($)?, namely ?_hole (1 + x)? In the expression: round $ _hole (1 + x) Ok, modules loaded: Main. }}} Surely, this must be wrong. Suddenly `()` is the inferred set of constraints and an unconstrained `a -> b` will do for `_outer`. I would argue that the `1 +` still demainds `Num a` and that `round` still requires an instance of `Integral b`, even if `round`'s `RealFrac` constraint is satisfied by `_hole` producing a `Double`. As said, maybe the erroneous types reported when `-fdefer-typed-holes` are a separate issue from the type of `_hole` not being the principal type, but I'm unsure, so I reported them together. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 13 20:47:33 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Sep 2015 20:47:33 -0000 Subject: [GHC] #8176: Language extensions not registered In-Reply-To: <045.79de2871493b7288b102990a0c57a18c@haskell.org> References: <045.79de2871493b7288b102990a0c57a18c@haskell.org> Message-ID: <060.ae146a52dd69b25e1c0f5153452dc936@haskell.org> #8176: Language extensions not registered -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | tests/driver/T4437.hs Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:10 thomie]: > I don't know what the first 3 are about, they are not listed on https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/flag- reference.html. Try to find out if they can be deleted. That very question comes up before every major GHC release ;-) See e.g. https://mail.haskell.org/pipermail/ghc- devs/2013-September/002267.html short answer: those are not considered official yet -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 13 22:16:27 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Sep 2015 22:16:27 -0000 Subject: [GHC] #10847: :info should print minimal definition In-Reply-To: <043.c6e083f7f51bc9197fc9d4b0280ca574@haskell.org> References: <043.c6e083f7f51bc9197fc9d4b0280ca574@haskell.org> Message-ID: <058.855b7db69b96f0349cd2bf0cad7657b8@haskell.org> #10847: :info should print minimal definition -------------------------------------+------------------------------------- Reporter: osa1 | Owner: cocreature Type: feature request | Status: new Priority: lowest | Milestone: 8.0.1 Component: GHCi | Version: 7.11 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: Phab:D1241 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * related: => Phab:D1241 * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 13 22:16:38 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Sep 2015 22:16:38 -0000 Subject: [GHC] #10847: :info should print minimal definition In-Reply-To: <043.c6e083f7f51bc9197fc9d4b0280ca574@haskell.org> References: <043.c6e083f7f51bc9197fc9d4b0280ca574@haskell.org> Message-ID: <058.59bafc4d3cf8f71b940c5fa819170190@haskell.org> #10847: :info should print minimal definition -------------------------------------+------------------------------------- Reporter: osa1 | Owner: cocreature Type: feature request | Status: new Priority: lowest | Milestone: 8.0.1 Component: GHCi | Version: 7.11 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1241 -------------------------------------+------------------------------------- Changes (by thomie): * differential: => Phab:D1241 * related: Phab:D1241 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 13 22:52:56 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Sep 2015 22:52:56 -0000 Subject: [GHC] #10863: "hello world" produces illegal instruction error In-Reply-To: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> References: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> Message-ID: <061.2a9d9bd1b3dbbf7920eef521a7056a1d@haskell.org> #10863: "hello world" produces illegal instruction error ----------------------------------+--------------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------+--------------------------------- Comment (by Ansible): Ok here you go. I build it like so: > ghc hello.hs -debug And the gdb output: `(gdb) run Starting program: /home/bburdette/code/ghcbug/hello [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/arm-linux- gnueabihf/libthread_db.so.1". Program received signal SIGILL, Illegal instruction. 0x0000abc0 in main () (gdb) bt #0 0x0000abc0 in main () (gdb) disas Dump of assembler code for function main: 0x0000abb0 <+0>: push {r4, r7, lr} 0x0000abb2 <+2>: sub sp, #36 ; 0x24 0x0000abb4 <+4>: add r7, sp, #8 0x0000abb6 <+6>: str r0, [r7, #4] 0x0000abb8 <+8>: str r1, [r7, #0] 0x0000abba <+10>: movw r3, #57520 ; 0xe0b0 0x0000abbe <+14>: movt r3, #61 ; 0x3d 0x0000abc2 <+18>: add.w r4, r7, #12 0x0000abc6 <+22>: ldmia.w r3, {r0, r1, r2} 0x0000abca <+26>: stmia.w r4, {r0, r1, r2} 0x0000abce <+30>: movs r3, #1 0x0000abd0 <+32>: str r3, [r7, #12] 0x0000abd2 <+34>: movs r3, #1 0x0000abd4 <+36>: str r3, [r7, #20] 0x0000abd6 <+38>: mov r2, sp 0x0000abd8 <+40>: add.w r3, r7, #16 0x0000abdc <+44>: ldmia.w r3, {r0, r1} 0x0000abe0 <+48>: stmia.w r2, {r0, r1} 0x0000abe4 <+52>: ldr r3, [r7, #12] 0x0000abe6 <+54>: ldr r0, [r7, #4] 0x0000abe8 <+56>: ldr r1, [r7, #0] 0x0000abea <+58>: movw r2, #45368 ; 0xb138 0x0000abee <+62>: movt r2, #62 ; 0x3e 0x0000abf2 <+66>: bl 0x38f26c End of assembler dump. (gdb) info reg r0 0x1624b0 1451184 r1 0x76cff004 1993338884 r2 0x3eb138 4108600 r3 0x76c03400 1992307712 r4 0x40c590 4244880 r5 0x76c033a0 1992307616 r6 0x76c01ffc 1992302588 r7 0x3f68a0 4155552 r8 0x3eb128 4108584 r9 0x0 0 r10 0x76fff000 1996484608 r11 0x76c03064 1992306788 r12 0x76df08f1 1994328305 sp 0x7effd4a0 0x7effd4a0 lr 0x39c119 3784985 pc 0xabc0 0xabc0 cpsr 0x20010010 536936464 (gdb) ` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 13 22:57:09 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Sep 2015 22:57:09 -0000 Subject: [GHC] #10863: "hello world" produces illegal instruction error In-Reply-To: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> References: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> Message-ID: <061.eb943f4f5eb05a772aca8df805b1666b@haskell.org> #10863: "hello world" produces illegal instruction error ----------------------------------+--------------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------+--------------------------------- Changes (by Ansible): * Attachment "gdb_output" added. gdb output -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 13 23:15:53 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Sep 2015 23:15:53 -0000 Subject: [GHC] #8405: experiment with using function-sections for linking (for smaller libs and executables) In-Reply-To: <045.ff128453c9ddce6d07b91486f573635a@haskell.org> References: <045.ff128453c9ddce6d07b91486f573635a@haskell.org> Message-ID: <060.2e82cfefa54d55c1fee44d2158870032@haskell.org> #8405: experiment with using function-sections for linking (for smaller libs and executables) -------------------------------------+------------------------------------- Reporter: carter | Owner: olsner Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1242 -------------------------------------+------------------------------------- Changes (by olsner): * differential: => Phab:D1242 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 00:41:02 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 00:41:02 -0000 Subject: [GHC] #10863: "hello world" produces illegal instruction error In-Reply-To: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> References: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> Message-ID: <061.caa18b23b8bf34755a183c9f167453bd@haskell.org> #10863: "hello world" produces illegal instruction error ----------------------------------+--------------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------+--------------------------------- Comment (by rwbarton): Ok so `main` is Thumb code (mixed 2- and 4-byte instructions) but it was called as ARM mode. The evidence is that the T bit (bit 5, `0x00000200`) in the CPSR is not set, and we are in the middle of a Thumb instruction `main+16`, presumably by managing to stumble through four 32-bit ARM instructions. I don't understand ''why'' `main` is Thumb code though. `main` is built from a C file with `gcc` when the executable is built. Could you attach the output of building your program with `ghc -v`? I assume `gcc` is not being invoked with `-mthumb`... Maybe a dumb question, but can you compile and run a simple C hello world program? If you run it in gdb and break on `main`, is it ARM code or Thumb code? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 00:51:18 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 00:51:18 -0000 Subject: [GHC] #10863: "hello world" produces illegal instruction error In-Reply-To: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> References: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> Message-ID: <061.53e747a5217605b8cac11ebcbead397c@haskell.org> #10863: "hello world" produces illegal instruction error ----------------------------------+--------------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------+--------------------------------- Changes (by Ansible): * Attachment "gcc_test" added. test of gcc - hello world C prog -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 00:51:56 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 00:51:56 -0000 Subject: [GHC] #10863: "hello world" produces illegal instruction error In-Reply-To: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> References: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> Message-ID: <061.07f68c8a0f1dcb10ed976d793c998388@haskell.org> #10863: "hello world" produces illegal instruction error ----------------------------------+--------------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------+--------------------------------- Changes (by Ansible): * Attachment "ghc-v" added. "ghc -v hello.hs -debug" -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 00:53:47 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 00:53:47 -0000 Subject: [GHC] #7830: Error: operand out of range In-Reply-To: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> References: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> Message-ID: <059.60695a2aed1c2864e48642b2005b5ed6@haskell.org> #7830: Error: operand out of range -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Installing GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by erikd): Compiling git HEAD (currently c8d438fb02 but anything after commit 5d57087e31 is basically the same) fails on PowerPC due to the issue in this ticket (comment 19 and later). When it fails, the generated assembler for `compiler/cmm/PprC.hs` is about 300000 lines of code, but if I compile the tree at commit bcfae08c0b (the one before 5d57087e31) the generated assemble for this file is only 135297 lines of code. Ignoring the stage1 compiler and looking at compiling `compiler/cmm/PprC.hs` with ghc-7.8.4 I see: {{{ revision wc -l PprC.s lwz_count stw_count --------------------------------------------------------------------- commit bcfae08c0b 135297 27751 30921 HEAD (c8d438fb02) 279333 70407 77666 }}} where {{{ lwz_count = grep lwz PprC.s | wc -l stw_count = grep stw PprC.s | wc -l }}} Just out of curiosity I decided to do the same test on x86_64/linux and found: {{{ revision wc -l PprC.s --------------------------------- commit bcfae08c0b 119246 HEAD (c8d438fb02) 246768 }}} a near doubling of the code size. Is it possible we are inlining something we shouldn't? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 00:58:18 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 00:58:18 -0000 Subject: [GHC] #10863: "hello world" produces illegal instruction error In-Reply-To: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> References: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> Message-ID: <061.adb4ade0f989cd434b3c23659b18ea1a@haskell.org> #10863: "hello world" produces illegal instruction error ----------------------------------+--------------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------+--------------------------------- Changes (by Ansible): * Attachment "break_on_main" added. break on main in gdb. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 00:59:17 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 00:59:17 -0000 Subject: [GHC] #10375: arm: ghci hits an illegal instruction In-Reply-To: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> References: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> Message-ID: <059.a5884a3b47d09127d27774d5b43d7b7d@haskell.org> #10375: arm: ghci hits an illegal instruction -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: Runtime System | Version: 7.10.1 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): Replying to [comment:41 erikd]: > From: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0489c/CIHGJHED.html > > The instruction matches: > > {{{ > op{type}{cond} Rt, [Rn, #offset]! ; pre-indexed > }}} > > but the under the section titled "Register restrictions" it says: > > {{{ > Rn must be different from Rt in the pre-index and post-index forms. > }}} Pre-indexed instructions have a trailing `!`, though. This syntax means something like "increment `Rn` by `#offset`, then operate on the value pointed to by the updated `Rn`". That's why `Rn` cannot also appear as `Rt`, there would be two stores to the same register in the same instruction. The offending instruction here is `ldr r3, [r3, #0]` without a `!`, which is just a `r3 = *r3`. I suspect the issue is actually executing Thumb code in ARM mode, as appears to be the case in #10863, though I still have no idea as to the cause. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 01:02:03 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 01:02:03 -0000 Subject: [GHC] #10863: "hello world" produces illegal instruction error In-Reply-To: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> References: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> Message-ID: <061.4d7ad753c9e3c3b6f8e7fd4ae835b8fc@haskell.org> #10863: "hello world" produces illegal instruction error ----------------------------------+--------------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------+--------------------------------- Comment (by Ansible): Ok I compiled a 'hello world' program in gdb and broke on main and did 'disas'. Whether these are ARM instructions or not I have no idea. Also added other attachments for ghc -v and 'hello world' output. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 01:02:44 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 01:02:44 -0000 Subject: [GHC] #10863: "hello world" produces illegal instruction error In-Reply-To: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> References: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> Message-ID: <061.0e62cc2e932b927387bb76c4387cd912@haskell.org> #10863: "hello world" produces illegal instruction error ----------------------------------+--------------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------+--------------------------------- Comment (by rwbarton): Ok, so the C main is clearly Thumb code too. Can you check `info reg`? And also use `-fforce-recomp` for ghc. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 01:04:40 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 01:04:40 -0000 Subject: [GHC] #10863: "hello world" produces illegal instruction error In-Reply-To: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> References: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> Message-ID: <061.24c0e18096bc997f4157fc8017e2f59a@haskell.org> #10863: "hello world" produces illegal instruction error ----------------------------------+--------------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------+--------------------------------- Changes (by Ansible): * Attachment "break_on_main" added. break on main in gdb. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 01:04:40 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 01:04:40 -0000 Subject: [GHC] #10863: "hello world" produces illegal instruction error In-Reply-To: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> References: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> Message-ID: <061.adb4ade0f989cd434b3c23659b18ea1a@haskell.org> #10863: "hello world" produces illegal instruction error ----------------------------------+--------------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------+--------------------------------- Changes (by Ansible): * Attachment "break_on_main" removed. break on main in gdb. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 01:07:34 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 01:07:34 -0000 Subject: [GHC] #10863: "hello world" produces illegal instruction error In-Reply-To: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> References: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> Message-ID: <061.e7d3028d72714df411a7d922e9018259@haskell.org> #10863: "hello world" produces illegal instruction error ----------------------------------+--------------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------+--------------------------------- Comment (by Ansible): Ok appended the info_reg section onto the existing break_on_main file. I gave it a shot with "ghc -fforce-recomp hello.hs" but the resulting executable still crashes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 01:14:45 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 01:14:45 -0000 Subject: [GHC] #10863: "hello world" produces illegal instruction error In-Reply-To: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> References: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> Message-ID: <061.5601c77359a355092ce8050c99c90664@haskell.org> #10863: "hello world" produces illegal instruction error ----------------------------------+--------------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------+--------------------------------- Comment (by rwbarton): Sorry, I meant `ghc -v -fforce-recomp`. Otherwise it doesn't really rebuild anything, and the `-v` output is not helpful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 01:17:47 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 01:17:47 -0000 Subject: [GHC] #10863: "hello world" produces illegal instruction error In-Reply-To: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> References: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> Message-ID: <061.b08e4d9d0f8f3bfbf287c10fde43d01a@haskell.org> #10863: "hello world" produces illegal instruction error ----------------------------------+--------------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------+--------------------------------- Comment (by rwbarton): Ok so here CPSR is `0x60000030` which has the T bit set (`0x20`). So the CPU knows it is executing Thumb instructions. I don't understand what is different about what we are doing though... I mean we are presumably linking against the same libc that contains the call to `main`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 01:19:03 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 01:19:03 -0000 Subject: [GHC] #10863: "hello world" produces illegal instruction error In-Reply-To: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> References: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> Message-ID: <061.e034d37d994d83350a45597384fbb661@haskell.org> #10863: "hello world" produces illegal instruction error ----------------------------------+--------------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------+--------------------------------- Changes (by Ansible): * Attachment "ghc-v-fforce-recomp" added. output from: "ghc -v -fforce-recomp hello.hs" -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 01:46:20 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 01:46:20 -0000 Subject: [GHC] #7830: Error: operand out of range In-Reply-To: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> References: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> Message-ID: <059.78813ac03cf873b3d1461c5d54be02ab@haskell.org> #7830: Error: operand out of range -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Installing GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by erikd): I noticed that since the above numbers are using the bootstrap compiler with `-O0`. As a test, on PowerPC, changed `-O0` to `-O2` which cause the generated assembly file to grow to 302144 lines of code. At @rwbarton's suggestion added `NOINLINE` pragmas to `above_` and `beside_` functions in `compiler/utils/Pretty.hs` and now the assembler file for `compiler/cmm/PprC.hs` is 158390 lines. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 02:16:20 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 02:16:20 -0000 Subject: [GHC] #10878: Near doubling of generated code size for compiler/cmm/PprC.hs with commit 5d57087e31 Message-ID: <044.9d94a947d4932234addf1109fa44fa7c@haskell.org> #10878: Near doubling of generated code size for compiler/cmm/PprC.hs with commit 5d57087e31 -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- As noted in https://ghc.haskell.org/trac/ghc/ticket/7830#comment:28, changes to `compiler/utils/Pretty.hs` in commit 5d57087e31 results in a near doubling of the generated code size of compiler/cmm/PprC.hs` on x86_64/linux. On powerpc/linux this code growth caused this file to fail to build. At @rwbarton's suggestion, I added `NOINLINE` pragmas to `above_` and `beside_` of `compiler/utils/Pretty.hs` and that brought the generated code size down to be just a little more than 30% bigger than it was before commit 5d57087e31. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 02:18:29 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 02:18:29 -0000 Subject: [GHC] #7830: Error: operand out of range In-Reply-To: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> References: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> Message-ID: <059.94117849f6aa3073c02fce421293bc9b@haskell.org> #7830: Error: operand out of range -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Installing GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by erikd): Since the doubling of generated code size for `compiler/cmm/PprC.hs` is not PowerPC specific, opened ticket #10878. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 02:20:14 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 02:20:14 -0000 Subject: [GHC] #10878: Near doubling of generated code size for compiler/cmm/PprC.hs with commit 5d57087e31 In-Reply-To: <044.9d94a947d4932234addf1109fa44fa7c@haskell.org> References: <044.9d94a947d4932234addf1109fa44fa7c@haskell.org> Message-ID: <059.09c28f9f908c73a48ba915363b988c5f@haskell.org> #10878: Near doubling of generated code size for compiler/cmm/PprC.hs with commit 5d57087e31 -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by erikd): @thomie, if you are happy with the `NOINLINE` solution suggested by @rwbarton, I'm happy to whip up a phab review for this and push it through. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 02:31:30 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 02:31:30 -0000 Subject: [GHC] #10863: "hello world" produces illegal instruction error In-Reply-To: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> References: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> Message-ID: <061.2671f9bfc5142ef6d3d082d069327087@haskell.org> #10863: "hello world" produces illegal instruction error ----------------------------------+--------------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | 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 Mon Sep 14 02:39:33 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 02:39:33 -0000 Subject: [GHC] #10863: "hello world" produces illegal instruction error In-Reply-To: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> References: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> Message-ID: <061.105553625146494b3c2042685d043bae@haskell.org> #10863: "hello world" produces illegal instruction error ----------------------------------+--------------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------+--------------------------------- Comment (by rwbarton): Since I don't have any other good ideas, does your C program also work if you build it with `-fuse-ld=gold`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 02:43:59 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 02:43:59 -0000 Subject: [GHC] #10863: "hello world" produces illegal instruction error In-Reply-To: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> References: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> Message-ID: <061.61d419e0781df1ea09d2e06883bc7984@haskell.org> #10863: "hello world" produces illegal instruction error ----------------------------------+--------------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------+--------------------------------- Comment (by Ansible): yep, it does work with that option. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 02:47:48 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 02:47:48 -0000 Subject: [GHC] #10863: "hello world" produces illegal instruction error In-Reply-To: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> References: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> Message-ID: <061.5d69b49215b5e110df1cff4eb84e548f@haskell.org> #10863: "hello world" produces illegal instruction error ----------------------------------+--------------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------+--------------------------------- Comment (by erikd): I grabbed the same compiler from http://ftp.us.debian.org/debian/pool/main/g/ghc/ghc_7.10.2-2_armhf.deb and compiled up a "hello world" program. The compiler worked fine as did the resulting executable. I inspected the file `/usr/lib/ghc/settings` and found: {{{ ("C compiler link flags", " -fuse-ld=gold -Wl,-z,noexecstack"), ("ld command", "/usr/bin/ld.gold"), ("LLVM llc command", "llc-3.5"), ("LLVM opt command", "opt-3.5") }}} which is exactly as I expected. Here are the versions of llvm/binutils/gcc that I have on my machine: {{{ llvm-3.5 1:3.5.2-1 armhf Modular compiler and toolchain technologies binutils 2.25.1-1 armhf GNU assembler, linker and binary utilities gcc 4:4.9.2-4 armhf GNU C compiler }}} @Ansible, please check your versions of the above. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 02:57:15 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 02:57:15 -0000 Subject: [GHC] #10863: "hello world" produces illegal instruction error In-Reply-To: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> References: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> Message-ID: <061.bf4de38a337827a1b2de8875af1a8859@haskell.org> #10863: "hello world" produces illegal instruction error ----------------------------------+--------------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------+--------------------------------- Comment (by Ansible): Ok here's some version info from my machine. Check your reddit pms, rwbarton. {{{ ("C compiler link flags", " -fuse-ld=gold -Wl,-z,noexecstack"), ("ld command", "/usr/bin/ld.gold"), ("LLVM llc command", "llc-3.5"), ("LLVM opt command", "opt-3.5") }}} {{{ ii llvm-3.5 1:3.5-10 armhf Modular compiler and toolchain technologies ii llvm-3.5-dev 1:3.5-10 armhf Modular compiler and toolchain technologies, libraries and headers ii llvm-3.5-runtime 1:3.5-10 armhf Modular compiler and toolchain technologies, IR interpreter ii gcc 4:4.9.2-2 armhf GNU C compiler ii binutils 2.25-5 armhf GNU assembler, linker and binary utilities }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 03:03:21 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 03:03:21 -0000 Subject: [GHC] #10863: "hello world" produces illegal instruction error In-Reply-To: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> References: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> Message-ID: <061.a1ace6810c92d486e1ce3e2fc8244ce9@haskell.org> #10863: "hello world" produces illegal instruction error ----------------------------------+--------------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------+--------------------------------- Comment (by erikd): I suspect binutils. Is it possible to upgrade just that, possibly to the version that is currently in debian testing? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 03:10:33 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 03:10:33 -0000 Subject: [GHC] #10863: "hello world" produces illegal instruction error In-Reply-To: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> References: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> Message-ID: <061.1ff066e540bd36ede635696d5f429027@haskell.org> #10863: "hello world" produces illegal instruction error ----------------------------------+--------------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------+--------------------------------- Comment (by Ansible): I'll all for it, but I don't spend too much time on debian. Do you know the command sequence for installing just binutils from testing? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 03:22:30 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 03:22:30 -0000 Subject: [GHC] #10478: Shorter import syntax In-Reply-To: <046.5e60b02b9fe497cdf59ecd5b37a450a2@haskell.org> References: <046.5e60b02b9fe497cdf59ecd5b37a450a2@haskell.org> Message-ID: <061.69c2d3be2dad586f44a7c271f12787b3@haskell.org> #10478: Shorter import syntax -------------------------------------+------------------------------------- Reporter: acowley | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1238 -------------------------------------+------------------------------------- Comment (by thomie): Here is an overview for two of the proposals listed on this ticket. Please inform me of any mistakes there might be, and I will edit this comment. I'm using the variant of goldfire's proposal with `(..)` instead of `*`, and where `(..) ` at the end of the line can be omitted. @goldfire: I understand your proposal would (also) be fully backward compatible. Please tell me on which rows you would recommend to use the old syntax. And maybe there's a useful trick only your proposal supports? Suppose the `module A` exports `x` and `y`. * Without a module alias: ||= # =||= Haskell 2010 =||= Proposal acowey || Proposal goldfire =||= Brings into scope =|| || 1 || import A || **import A** || **import A (..) qualified** || x, y, A.x, A.y || || 2 || import A (x) || **import A (x)** || **import A (..) qualified (x)** || x, A.x || || 3 || import qualified A || **import A () as A** || **import A qualified** || A.x, A.y || || 4 || import qualified A (x) || **import A () as A (x)** || **import A qualified (x)** || A.x || * With a module alias: ||= # =||= Haskell 2010 =||= Proposal acowey || Proposal goldfire =||= Brings into scope =|| || 5 || import A as B || **import A as B** || **import A (..) qualified as B** || x, y, B.x, B.y || || 6 || import A as B (x) || **import A as B (x)** || **import A (x) qualified as B (x)** || x, B.x || || 7 || import qualified A as B || **import A () as B** || **import A qualified as B** || B.x, B.y || || 8 || import qualified A as B (x) || **import A () as B (x)** || **import A qualified as B (x)** || B.x || * The real deal: ||= # =||- Haskell 2010 =||= Proposal acowey || Proposal goldfire =||= Brings into scope =|| || 9 || import A (x); || **import A (x) as B** || **import A (x) qualified as B** || x, B.x, B.y || || || import qualified A as B || || 10 || //(impossible)// || **import A (x) as X ()** || **import A (x) qualified ()** || x || Potentially confusing things about these proposals, assuming full backward compatibility: ||= proposal =||= H2010 syntax =||= new syntax =||= Why confusing? =|| ||= acowley =|| **import A as B (x)** || **import A (x) as B** || look similar, do different things || ||= goldfire =|| **import qualified A as B (x)** || **import A (x) qualified as B** || look similar, do different things || ||= goldfire =|| **import qualified A** || **import A qualified** || look different, do the same thing || -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 03:23:23 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 03:23:23 -0000 Subject: [GHC] #10375: arm: ghci hits an illegal instruction In-Reply-To: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> References: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> Message-ID: <059.6d4502db26d07fc27a9512a91397c75d@haskell.org> #10375: arm: ghci hits an illegal instruction -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: Runtime System | Version: 7.10.1 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by erikd): Since I know that this is some problem with the function `hSetBuffering` when it is being loaded by the runtime linker I added a printf to `rts/Linker.c` to print the address of the `hSetBuffering` related functions when they are loaded. Running this now looks like: {{{ $ inplace/bin/ghc-stage2 --interactive GHCi, version 7.11.20150912: http://www.haskell.org/ghc/ :? for help lookupSymbol: value of base_GHCziIOziHandle_hSetBuffering1_entry is 0xb3f3d3cd lookupSymbol: value of base_GHCziIOziHandle_hSetBuffering1_entry is 0xb3f3d3cd lookupSymbol: value of base_GHCziIOziHandle_hSetBuffering1_info is 0xb421f738 lookupSymbol: value of base_GHCziIOziHandle_hSetBuffering1_closure is 0xb421d5b0 lookupSymbol: value of base_GHCziIOziHandle_hSetBuffering_entry is 0xb3f3d471 lookupSymbol: value of base_GHCziIOziHandle_hSetBuffering_info is 0xb421f718 lookupSymbol: value of base_GHCziIOziHandle_hSetBuffering1_entry is 0xb3f3d3cd turnOffBuffering start turnOffBuffering middle Illegal instruction }}} If I now load this into gdb, run it until it crashes I get: {{{ GHCi, version 7.11.20150912: http://www.haskell.org/ghc/ :? for help lookupSymbol: value of base_GHCziIOziHandle_hSetBuffering1_entry is 0xb3f503cd lookupSymbol: value of base_GHCziIOziHandle_hSetBuffering1_entry is 0xb3f503cd lookupSymbol: value of base_GHCziIOziHandle_hSetBuffering1_info is 0xb4232738 lookupSymbol: value of base_GHCziIOziHandle_hSetBuffering1_closure is 0xb42305b0 lookupSymbol: value of base_GHCziIOziHandle_hSetBuffering_entry is 0xb3f50471 lookupSymbol: value of base_GHCziIOziHandle_hSetBuffering_info is 0xb4232718 lookupSymbol: value of base_GHCziIOziHandle_hSetBuffering1_entry is 0xb3f503cd turnOffBuffering start turnOffBuffering middle Program received signal SIGILL, Illegal instruction. 0x04004e5c in stg_ap_v_fast () (gdb) disass base_GHCziIOziHandle_hSetBuffering1_entry Dump of assembler code for function base_GHCziIOziHandle_hSetBuffering1_entry: 0x03d423c4 <+0>: movw r3, #58688 ; 0xe540 0x03d423c8 <+4>: movt r3, #1181 ; 0x49d 0x03d423cc <+8>: ldr.w r2, [r3, #808] ; 0x328 0x03d423d0 <+12>: subs r2, #4 }}} For some reason, the address of `base_GHCziIOziHandle_hSetBuffering1_entry` in GDB is not the address printed by the runtime linker. Even more confusingly, disassembling the address the `0xb3f3d3cd` fails, possibly because its outside the memory map. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 03:30:52 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 03:30:52 -0000 Subject: [GHC] #10863: "hello world" produces illegal instruction error In-Reply-To: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> References: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> Message-ID: <061.04b5d96757d610676fe1d97cc1c51c71@haskell.org> #10863: "hello world" produces illegal instruction error ----------------------------------+--------------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------+--------------------------------- Comment (by erikd): Simple, go to https://www.debian.org/distrib/packages , scroll down to the section titled "Search package directories", enter the name "binutils" and choose the "testing" distribution which will give you a link to https://packages.debian.org/stretch/binutils , then go to the bottom of the page where it says "Download binutils", and click on "armhf" which leads you to https://packages.debian.org/stretch/armhf/binutils/download which gives a number of links to the binary package. See, simple (not) when you know how :-). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 03:37:45 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 03:37:45 -0000 Subject: [GHC] #10863: "hello world" produces illegal instruction error In-Reply-To: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> References: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> Message-ID: <061.b1bc3e88d1eb21f40fef8a93bf1a0884@haskell.org> #10863: "hello world" produces illegal instruction error ----------------------------------+--------------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------+--------------------------------- Comment (by Ansible): Ok I installed the binutils, but no dice it seems... {{{ bburdette at jessie-rpi:~/code/ghcbug$ sudo dpkg -i binutils_2.25.1-1_armhf.deb [sudo] password for bburdette: (Reading database ... 38788 files and directories currently installed.) Preparing to unpack binutils_2.25.1-1_armhf.deb ... Unpacking binutils (2.25.1-1) over (2.25-5) ... Setting up binutils (2.25.1-1) ... Processing triggers for man-db (2.7.0.2-5) ... Processing triggers for libc-bin (2.19-18) ... bburdette at jessie-rpi:~/code/ghcbug$ ls a.out core hello hello.hs install_log binutils_2.25.1-1_armhf.deb frout hello.hi hello.o main.cpp bburdette at jessie-rpi:~/code/ghcbug$ ghc -fforce-recomp hello.hs [1 of 1] Compiling Main ( hello.hs, hello.o ) Linking hello ... bburdette at jessie-rpi:~/code/ghcbug$ ./hello Illegal instruction bburdette at jessie-rpi:~/code/ghcbug$ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 03:48:53 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 03:48:53 -0000 Subject: [GHC] #10863: "hello world" produces illegal instruction error In-Reply-To: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> References: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> Message-ID: <061.1a695b29493107a6a5058b62994d4f78@haskell.org> #10863: "hello world" produces illegal instruction error ----------------------------------+--------------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------+--------------------------------- Comment (by erikd): Sorry, I mis-read the information you had provided. I thought it was the compiler that was crashing, not the compiled executable. Since it is not the compiler and it *is* the executable, I am 100% certain that the version of the llvm tools you have contains a bug (discussed in ticket #9920). The fix for that LLVM bug is to install llvm-3.5.2 from debian testing. You should list all the llvm-3.5 packages you have installed using `dpkg -l | grep llvm-3.5` and then replace them with the relevant replacements here http://ftp.us.debian.org/debian/pool/main/l/llvm-toolchain-3.5/ whose package names match `*3.5.2-2_armhf.deb`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 04:33:27 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 04:33:27 -0000 Subject: [GHC] #10863: "hello world" produces illegal instruction error In-Reply-To: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> References: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> Message-ID: <061.5ea092fc7e1445e02d1af83784c95c0b@haskell.org> #10863: "hello world" produces illegal instruction error ----------------------------------+--------------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------+--------------------------------- Comment (by Ansible): Ok, running into dependency hell trying to install these packages manually. I'm going to try just changing over to debian testing and then see if it works. Will post back with results. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 04:40:45 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 04:40:45 -0000 Subject: [GHC] #10863: "hello world" produces illegal instruction error In-Reply-To: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> References: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> Message-ID: <061.892dadfde5d9711d82c15ca0dc5136cc@haskell.org> #10863: "hello world" produces illegal instruction error ----------------------------------+--------------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------+--------------------------------- Comment (by erikd): Actually, I suspect that those packages along will not trigger dependency hell, but Debian testing may be safer. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 05:47:27 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 05:47:27 -0000 Subject: [GHC] #10863: "hello world" produces illegal instruction error In-Reply-To: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> References: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> Message-ID: <061.a1b4f85a1b4c9f2c4b2d4db57143ad33@haskell.org> #10863: "hello world" produces illegal instruction error ----------------------------------+--------------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------+--------------------------------- Comment (by Ansible): Moved over to testing, but still getting the SIGILL, unfortunately. I did install ghc while it had the 3.5.2-1 llvm on there, but then upgraded to 3.5.2-2 {{{ bburdette at jessie-rpi:~/code/ghcbug$ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.10.2 bburdette at jessie-rpi:~/code/ghcbug$ ghc hello.hs bburdette at jessie-rpi:~/code/ghcbug$ ./hello Illegal instruction bburdette at jessie-rpi:~/code/ghcbug$ ls a.out hello.o binutils_2.25.1-1_armhf.deb install_log core libllvm3.5v5_3.5.2-2_armhf.deb download libstdc++6_5.2.1-16_armhf.deb download.1 libtinfo5_6.0+20150810-1_armhf.deb frout llvm-3.5-dev_3.5.2-2_armhf.deb hello llvm-3.5-runtime_3.5.2-2_armhf.deb hello.hi llvm-3.5_3.5.2-2_armhf.deb hello.hs main.cpp bburdette at jessie-rpi:~/code/ghcbug$ rm hello bburdette at jessie-rpi:~/code/ghcbug$ ghc hello.hs Linking hello ... bburdette at jessie-rpi:~/code/ghcbug$ ./hello Illegal instruction bburdette at jessie-rpi:~/code/ghcbug$ dpkg -l | grep llvm-3.5 ii llvm-3.5 1:3.5.2-2 armhf Modular compiler and toolchain technologies ii llvm-3.5-dev 1:3.5.2-2 armhf Modular compiler and toolchain technologies, libraries and headers ii llvm-3.5-runtime 1:3.5.2-2 armhf Modular compiler and toolchain technologies, IR interpreter bburdette at jessie-rpi:~/code/ghcbug$ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 06:02:04 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 06:02:04 -0000 Subject: [GHC] #10863: "hello world" produces illegal instruction error In-Reply-To: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> References: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> Message-ID: <061.90d6f6090236c4628c7610dc69b52a16@haskell.org> #10863: "hello world" produces illegal instruction error ----------------------------------+--------------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------+--------------------------------- Comment (by erikd): This: {{{ bburdette at jessie-rpi:~/code/ghcbug$ ghc hello.hs Linking hello ... }}} suggests that it the executable wasn't compiled, just linked (because the object file was already there). Use `ghc -fforce-recomp hello.hs -o hello`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 06:19:41 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 06:19:41 -0000 Subject: [GHC] #10863: "hello world" produces illegal instruction error In-Reply-To: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> References: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> Message-ID: <061.55e7af92e8ecd3836aff3a6f8267474f@haskell.org> #10863: "hello world" produces illegal instruction error ----------------------------------+--------------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------+--------------------------------- Comment (by Ansible): that worked! thanks for the help. seems like it would be worth noting that an exact version of llvm is required on the download page, which only mentions llvm 3.5. https://www.haskell.org/ghc/download_ghc_7_10_2#linux_armv7 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 07:44:31 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 07:44:31 -0000 Subject: [GHC] #10871: Implement "buildable" interface files which can be directly compiled without source In-Reply-To: <045.f4306fd46ddf30e7464e9ea8971267bf@haskell.org> References: <045.f4306fd46ddf30e7464e9ea8971267bf@haskell.org> Message-ID: <060.2ab4e793cce324167b927239f4da1835@haskell.org> #10871: Implement "buildable" interface files which can be directly compiled without source -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Tidying does a number of things, listed at the top of `TidyPgm`. I have not thought this through fully, but my guess is that most of them aren't what we want for a fat interface file; e.g. dropping rules; the whole `findExternalIds` thing; injecting implicit bindings, etc. But we probably do need one aspect of tidying, namely to rename things. Consider `\x_12 \x_14. x_12`, where the `_n` part is the unique. When we serialise into an interface file we drop the unique, so it's important that the `OccNames` don't shadow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 07:45:03 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 07:45:03 -0000 Subject: [GHC] #10875: Unexpected defaulting of partial type signatures and inconsistent behaviour when -fdefer-typed-holes is set. In-Reply-To: <047.47e931d5fc4e6515630dc5cf2498378f@haskell.org> References: <047.47e931d5fc4e6515630dc5cf2498378f@haskell.org> Message-ID: <062.536343faaf263e05b409ad6d61bbeb74@haskell.org> #10875: Unexpected defaulting of partial type signatures and inconsistent behaviour when -fdefer-typed-holes is set. -------------------------------------+------------------------------------- Reporter: holzensp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | PartialTypeSignatures TypedHoles Operating System: MacOS X | Architecture: x86_64 Type of failure: Incorrect | (amd64) warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by holzensp): I just realised that the above loss of the `RealFrac` constraint, may well be because GHC has nowhere to put it. I tried `(undefined::_ => _inner)`, but it seems the constraints hole is only used at top-level (i.e. GHC didn't output any message for this `_`). A further attempt using `ImplicitParams` also gave unexpected results. Consider this program: {{{#!hs {-#LANGUAGE NoMonomorphismRestriction #-} {-#LANGUAGE PartialTypeSignatures #-} {-#LANGUAGE NamedWildCards #-} {-#LANGUAGE ImplicitParams #-} foo :: _ => _outer foo x = round (?hole (1 + x)) }}} which yields {{{ Foo.hs:6:8: Warning: Found hole ?_? with inferred constraints: (Integral b, Num a, RealFrac a, ?hole::a -> a) In the type signature for ?foo?: _ => _outer Foo.hs:6:13: Warning: Found hole ?_outer? with type: a1 -> b Where: ?b? is a rigid type variable bound by the inferred type of foo :: (Integral b, Num a1, RealFrac a, ?hole::a1 -> a) => a1 -> b at Foo.hs:7:1 ?a1? is a rigid type variable bound by the inferred type of foo :: (Integral b, Num a1, RealFrac a, ?hole::a1 -> a) => a1 -> b at Foo.hs:7:1 In the type signature for ?foo?: _ => _outer Ok, modules loaded: Main. }}} Notice how the first message, regarding `_` is too restrictive, by demanding that `?hole::a -> a`. However, the second message is more general, stating `?hole::a1 -> a`. Could this just be a pretty printer issue, where the first message discards the subscript of the type variable? Another surprise occurs when I remove the parenthesis and use `$` instead: {{{#!hs foo x = round $ ?hole (1 + x) }}} results in {{{ Foo.hs:6:8: Warning: Found hole ?_? with inferred constraints: (Integral b, Num a, RealFrac r, ?hole::a -> r) In the type signature for ?foo?: _ => _outer Foo.hs:6:13: Warning: Found hole ?_outer? with type: a -> b Where: ?b? is a rigid type variable bound by the inferred type of foo :: (Integral b, Num a, RealFrac r, ?hole::a -> r) => a -> b at Foo.hs:7:1 ?a? is a rigid type variable bound by the inferred type of foo :: (Integral b, Num a, RealFrac r, ?hole::a -> r) => a -> b at Foo.hs:7:1 In the type signature for ?foo?: _ => _outer Ok, modules loaded: Main. }}} This is the result I was looking for! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 07:56:24 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 07:56:24 -0000 Subject: [GHC] #10653: PatternSynonyms should be imported/exported as part of the wildcard notation In-Reply-To: <049.0e5a3c33a167308dc99ecaed5730df14@haskell.org> References: <049.0e5a3c33a167308dc99ecaed5730df14@haskell.org> Message-ID: <064.98c679f1833ae136e94d2001ee944d3b@haskell.org> #10653: PatternSynonyms should be imported/exported as part of the wildcard notation -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: mpickering Type: feature request | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: pattern | synonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Thanks for the wiki page. But before implementing anything, can you make it a proposed ''specification'' rather than a general idea illustrated by an example or two? Notably: * When, precisely, is it OK to export `T( P )`, where `P` is a pattern synonym? * What, precisely, is exported by `T(..)`? To give you the idea, the [https://www.haskell.org/onlinereport/haskell2010/haskellch5.html#x11-1000005.2 current spec is here]. I think it's important that one can answer these questions without doing type checking. (In implementation terms, the renamer has to answer these questions, and typechecking has not happened yet.) I think your answers will say something like this. Given {{{ pattern P xs = C p1 p2 }}} where `C` is a data constructor, then `T( P )` is a valid export item iff (a) `C` is a data constructor from data type `T`, and (b) `P` is in scope. It does not matter whether or not `C` is in scope (correct?). But it gets more complicated if `C` is itself a pattern synonym; or, worse, if it is a view pattern. Maybe it's driven off the pattern signature, if there is one? You might find it helpful first to define the notion of "a pattern synonym `P` ''belongs to'' a data type `T`". Anyway, a specification is badly needed! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 08:05:57 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 08:05:57 -0000 Subject: [GHC] #10863: "hello world" produces illegal instruction error In-Reply-To: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> References: <046.f2bc02c165f3f2f52e6307229002a532@haskell.org> Message-ID: <061.c587ed80594627a01e6fef7fabb94804@haskell.org> #10863: "hello world" produces illegal instruction error ----------------------------------+--------------------------------- Reporter: Ansible | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: invalid | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------+--------------------------------- Changes (by erikd): * status: new => closed * resolution: => invalid Comment: Great. Got this one figured out. I'll close this but I'll also see if I can get that download page updated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 08:07:35 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 08:07:35 -0000 Subject: [GHC] #7253: Top-level bindings in ghci In-Reply-To: <048.88d72a7323b37dac89e81e376b48b907@haskell.org> References: <048.88d72a7323b37dac89e81e376b48b907@haskell.org> Message-ID: <063.698e1daa55b6e9f9bcf45119511a9e4b@haskell.org> #7253: Top-level bindings in ghci -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): > My first instinct was to treat declarations like "a = 1" in GHCI as equivalent to "let a = 1"; this would be a straightforward matter of parsing. On the other hand, as thoughtpolice comments, let-bound variables are treated subtly differently than top-level bindings, so the proper solution may be more involved. Would you like to elaborate on the "subtle difference"? Is it just `MonoLocalBinds`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 08:36:12 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 08:36:12 -0000 Subject: [GHC] #10876: stack overflow regression In-Reply-To: <044.3685b2599dc5dd8fb0cf47784fa834c3@haskell.org> References: <044.3685b2599dc5dd8fb0cf47784fa834c3@haskell.org> Message-ID: <059.9b35f07db2e16251d8b4fde2e2a6303b@haskell.org> #10876: stack overflow regression -------------------------------------+------------------------------------- Reporter: dmwit | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.3 Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * milestone: => 7.10.3 Comment: Doesn't loop in HEAD. Looks like #10806. We don't know which particular commit fixed it, so backporting the fix to 7.10.3 (if we have it) would involve real work by Iavor. Still, since it's come up twice I'll milestone it for 7.10.3 to give people a chance to yell that it's mission-critical. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 08:46:26 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 08:46:26 -0000 Subject: [GHC] #10875: Unexpected defaulting of partial type signatures and inconsistent behaviour when -fdefer-typed-holes is set. In-Reply-To: <047.47e931d5fc4e6515630dc5cf2498378f@haskell.org> References: <047.47e931d5fc4e6515630dc5cf2498378f@haskell.org> Message-ID: <062.180368460e83c5794ccff8cb77c91d30@haskell.org> #10875: Unexpected defaulting of partial type signatures and inconsistent behaviour when -fdefer-typed-holes is set. -------------------------------------+------------------------------------- Reporter: holzensp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | PartialTypeSignatures TypedHoles Operating System: MacOS X | Architecture: x86_64 Type of failure: Incorrect | (amd64) warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Interesting examples, thank you! As it happens I am in mid-flight on a significant refactoring of the wildcard implementation, so I'd like to park these examples and come back to them when I commit. It has turned out to be a much bigger job than I anticipated, I'm afraid. Just on the narrow question of defaulting, I think it's not unreasonable that wildcards don't affect type-class defaulting (i.e. in ambiguous cases, choose a particular type to fix the type, see [https://www.haskell.org/onlinereport/haskell2010/haskellch4.html#x10-750004.3 4.3.4 in the language definition]. Wouldn't people complain if adding wildcards changed the typing rules? Can you specify ''precisely'' what the new defaulting rules would then be? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 09:37:42 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 09:37:42 -0000 Subject: [GHC] #10879: base is not included in the haddock index Message-ID: <048.8713266ddcd63f131d79fa94bba781e8@haskell.org> #10879: base is not included in the haddock index -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.10.2 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- It appears that starting from ghc 7.10 base is no longer present in the haddock html index distributed with ghc. {{{ % grep -c base ~/.stack/programs/x86_64-linux/ghc-7.8.4/share/doc/ghc/html/libraries/index.html 1 % grep -c base ~/.stack/programs/x86_64-linux/ghc-7.10.2/share/doc/ghc/html/libraries/index.html 0 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 09:52:09 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 09:52:09 -0000 Subject: [GHC] #7830: Error: operand out of range In-Reply-To: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> References: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> Message-ID: <059.6a9f3db0ee10b654c5cabb392b33a706@haskell.org> #7830: Error: operand out of range -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Installing GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by erikd): Replying to [comment:29 erikd]: > At @rwbarton's suggestion added `NOINLINE` pragmas to `above_` and `beside_` functions in `compiler/utils/Pretty.hs` and now the assembler file for `compiler/cmm/PprC.hs` is 158390 lines. That worked when building the stage1 compiler using the bootstrap compiler, but it fails again when build the stage2 compiler with the stage1 compiler. The assembler file for `compiler/cmm/PprC.hs` compiled with the stage1 compiler is 220293 lines. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 10:12:54 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 10:12:54 -0000 Subject: [GHC] #10880: The 'impossible' happend Message-ID: <045.17c6a6181944c273e0d7be5fc752b3cf@haskell.org> #10880: The 'impossible' happend -----------------------------------+--------------------------------------- Reporter: drever | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: MacOS X Architecture: ia64 | Type of failure: Compile-time crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -----------------------------------+--------------------------------------- The compiler told me to file this report. I hope this helps! {{{ drever$ cabal build Building xxx-0.0... Preprocessing library xxx-0.0... In-place registering xxx-0.0... Preprocessing executable 'xxx' for xxx-0.0... [21 of 21] Compiling Main ( src/main.hs, dist/build/xxx/xxx- tmp/Main.o ) src/main.hs:107:19: Couldn't match kind `* -> *' with `*' Expected type: FileName -> ReaderT XXXEnvironment IO t0 Actual type: FileName -> ReaderT XXXEnvironment IO t0 Kind incompatibility when matching types: FileName :: * -> * FileName :: * The function `lift'ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-apple-darwin): kindFunResult ghc-prim:GHC.Prim.*{(w) tc 34d} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} {{{#!hs generatecode :: (Entity -> [EntitySample]) -> ReaderT MyEnvironment IO () generatecode sample = do domain_xsd <- lift xsdEntities "test" return () }}} {{{#!hs xsdEntities :: String -> IO [Entity] xsdEntities f = do maybeEntities <- runX ((XS.gettypes f) BaseWrite) return $ catMaybes $ concat maybeEntities }}} {{{#!hs gettypes :: String -> MyType -> IOSLA (XIOState s) a [Maybe S.Entity] gettypes f t = (cris f) >>> (arr $ filterExtends BaseWrite) >>> (arr getComplexTypes) >>> (arr (map complexTypeToEntity)) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 10:29:32 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 10:29:32 -0000 Subject: [GHC] #8901: (very) bad inline heuristics In-Reply-To: <048.b4dd5c7e62c55ef9ac6aee5f6863fb3f@haskell.org> References: <048.b4dd5c7e62c55ef9ac6aee5f6863fb3f@haskell.org> Message-ID: <063.1b7fbb8d9af4f484f857816abab25655@haskell.org> #8901: (very) bad inline heuristics -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by heisenbug): Replying to [comment:2 trommler]: > Replying to [ticket:8901 heisenbug]: > > The problem is so bad that the PowerPC32 assembler cannot resolve cross-routine references. > > (I have no error message at hand, but could try to get one.) > FWIW > The powerpc issue in the time library (#7830) was fixed by @erikd. But that bug (#7830) is not closed yet! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 10:33:10 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 10:33:10 -0000 Subject: [GHC] #7253: Top-level bindings in ghci In-Reply-To: <048.88d72a7323b37dac89e81e376b48b907@haskell.org> References: <048.88d72a7323b37dac89e81e376b48b907@haskell.org> Message-ID: <063.1571328bc9772f0b09584c91dedc7c2f@haskell.org> #7253: Top-level bindings in ghci -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): Reddit user "roshats" is also working on a patch for this: https://www.reddit.com/r/haskell/comments/3ks5mi/function_definition_in_ghci/cv0bjx4 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 10:34:18 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 10:34:18 -0000 Subject: [GHC] #10672: GHCi linker does not understand C++ exception tables on Windows In-Reply-To: <045.04cee7c60b130b0ccc29791ed61c4f5f@haskell.org> References: <045.04cee7c60b130b0ccc29791ed61c4f5f@haskell.org> Message-ID: <060.59358f493a9fe312982af10f1f816140@haskell.org> #10672: GHCi linker does not understand C++ exception tables on Windows -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Phyx- Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: Runtime System | Version: 7.10.1 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #9297 #10563 | Differential Revisions: #8237 #9907 | -------------------------------------+------------------------------------- Comment (by lukexi): Awesome stuff Tamar!! I confirmed your branch works on my test case and also backported the patches to 7.10.2 at https://github.com/lukexi/ghc/tree/ghc-7.10.2 -release-plus-rework-windows-pe-linker (git did 99% of the work, they mostly applied cleanly) and was able to build all of `bullet-mini` flawlessly, hurray! Thanks so much for your hard work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 10:35:11 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 10:35:11 -0000 Subject: [GHC] #7830: Error: operand out of range In-Reply-To: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> References: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> Message-ID: <059.17ca04f17009afaf137ede7a80afe1ab@haskell.org> #7830: Error: operand out of range -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Installing GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by heisenbug): Replying to [comment:29 erikd]: > I noticed that since the above numbers are using the bootstrap compiler with `-O0`. > > As a test, on PowerPC, changed `-O0` to `-O2` which cause the generated assembly file to grow to 302144 lines of code. > > At @rwbarton's suggestion added `NOINLINE` pragmas to `above_` and `beside_` functions in `compiler/utils/Pretty.hs` and now the assembler file for `compiler/cmm/PprC.hs` is 158390 lines. #8901 is a case where adding `NOINLINE` pragmas to the `time` library caused shrinkage in generated `.o` files by a factor ~5. Originally it also busted the 16-bit offsets on PPC32. Not sure whether the `time` maintainer followed my suggestions to add the pragmas or if everybody is just waiting for saner GHC inlining... :-( -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 10:40:25 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 10:40:25 -0000 Subject: [GHC] #8901: (very) bad inline heuristics In-Reply-To: <048.b4dd5c7e62c55ef9ac6aee5f6863fb3f@haskell.org> References: <048.b4dd5c7e62c55ef9ac6aee5f6863fb3f@haskell.org> Message-ID: <063.1b53bb0fc203b600208bafc54412366f@haskell.org> #8901: (very) bad inline heuristics -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by erikd): * cc: erikd (added) Comment: #7830 was closed for some time, but was re-opened just recently. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 10:43:57 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 10:43:57 -0000 Subject: [GHC] #10867: Primop types should not mention () In-Reply-To: <046.c2e6159f1c64c1079ec9b781aa715970@haskell.org> References: <046.c2e6159f1c64c1079ec9b781aa715970@haskell.org> Message-ID: <061.316a440771d96de9e55e64626fd57cf7@haskell.org> #10867: Primop types should not mention () -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * cc: core-libraries-committee (added) Comment: Simon, can you help a little more? I'm also copying the core libraries committee, since I propose an API change for weak-pointer primpops. The type `Weak#` and primop `mkWeak#`, are declared thus: {{{ primtype Weak# b primop MkWeakOp "mkWeak#" GenPrimOp o -> b -> c -> State# RealWorld -> (# State# RealWorld, Weak# b #) }}} I think `c` is the finalizer. This type suggests that you can put any old value in for the finalizer, which seems unlikely. '''In fact it can easily lead to a seg-fault (with no use of `unsafeCoerce` by building a weak pointer whose "finaliser" with the wrong type.''' Then the primop `finalizeWeak#` is declared thus: {{{ primop FinalizeWeakOp "finalizeWeak#" GenPrimOp Weak# a -> State# RealWorld -> (# State# RealWorld , Int# , State# RealWorld -> (# State# RealWorld, () #) #) }}} I believe the following: * The third argument to `mkWeak#` is returned as the third component of the result to `finalizeWeak#`, but is otherwise totally un-examined by the RTS. Is that true? In that case it would be far, far better to declare them like this: {{{ primtype Weak# value finalizer primop MkWeakOp "mkWeak#" GenPrimOp key -> value -> finalizer -> State# RealWorld -> (# State# RealWorld, Weak# payload finalizer #) }}} So `Weak#` gets two type parameters, the second recording the type of the "finaliser". All the RTS promises to do is to cough up the "finalizer" when the `key` dies. Now in `GHC.Weak` we can declare `Weak` thus: {{{ data Weak v = Weak (Weak# v) (IO ()) }}} That is `Weak` specialises the "any only value can be a finaliser" API offered by `Weak#` to "the finaliser is a vlaue of type `IO ()`" API for `Weak`. Doing this would eliminate an unpleasant potential source of seg-faults; and it would eliminate one of the two unpleasant uses of `()` in `primpops.txt.pp`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 10:45:01 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 10:45:01 -0000 Subject: [GHC] #10867: Primop types should not mention () In-Reply-To: <046.c2e6159f1c64c1079ec9b781aa715970@haskell.org> References: <046.c2e6159f1c64c1079ec9b781aa715970@haskell.org> Message-ID: <061.7b7d48a72c3dcf9ebd2439b8b96b2299@haskell.org> #10867: Primop types should not mention () -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): > It looks like `check#` has the wrong type anyway, its implementation returns () (ie. zero return values in Cmm), so its Haskell type should have a return type of `State# RealWorld` Ben: could you do this and validate, pls? Fixes a bug and helps move this ticket along. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 11:17:46 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 11:17:46 -0000 Subject: [GHC] #10878: Near doubling of generated code size for compiler/cmm/PprC.hs with commit 5d57087e31 In-Reply-To: <044.9d94a947d4932234addf1109fa44fa7c@haskell.org> References: <044.9d94a947d4932234addf1109fa44fa7c@haskell.org> Message-ID: <059.e2d9e4c81afcb77553cbc369a89531fd@haskell.org> #10878: Near doubling of generated code size for compiler/cmm/PprC.hs with commit 5d57087e31 -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): I'll have a look. I would like to understand the +30% still. Notice I also applied f903949beee3a4e0a925003b5553066c9f513c11, to mitigate another performance problem with the patch you mentioned (5d57087e314bd484dbe14958f9b422be3ac6641a). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 11:21:19 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 11:21:19 -0000 Subject: [GHC] #10880: The 'impossible' happend In-Reply-To: <045.17c6a6181944c273e0d7be5fc752b3cf@haskell.org> References: <045.17c6a6181944c273e0d7be5fc752b3cf@haskell.org> Message-ID: <060.46216279b96e80953652d27d06e666cb@haskell.org> #10880: The 'impossible' happend ---------------------------------------+-------------------------------- Reporter: drever | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: ia64 Type of failure: Compile-time crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------------+-------------------------------- Description changed by drever: Old description: > The compiler told me to file this report. I hope this helps! > > {{{ > drever$ cabal build > Building xxx-0.0... > Preprocessing library xxx-0.0... > In-place registering xxx-0.0... > Preprocessing executable 'xxx' for xxx-0.0... > [21 of 21] Compiling Main ( src/main.hs, dist/build/xxx/xxx- > tmp/Main.o ) > > src/main.hs:107:19: > Couldn't match kind `* -> *' with `*' > Expected type: FileName -> ReaderT XXXEnvironment IO t0 > Actual type: FileName -> ReaderT XXXEnvironment IO t0 > Kind incompatibility when matching types: > FileName :: * -> * > FileName :: * > The function `lift'ghc: panic! (the 'impossible' happened) > (GHC version 7.6.3 for x86_64-apple-darwin): > kindFunResult ghc-prim:GHC.Prim.*{(w) tc 34d} > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} > > {{{#!hs > generatecode :: (Entity -> [EntitySample]) -> ReaderT MyEnvironment IO () > generatecode sample = do > domain_xsd <- lift xsdEntities "test" > return () > }}} > > {{{#!hs > xsdEntities :: String -> IO [Entity] > xsdEntities f = do > maybeEntities <- runX ((XS.gettypes f) BaseWrite) > return $ catMaybes $ concat maybeEntities > }}} > > {{{#!hs > gettypes :: String -> MyType -> IOSLA (XIOState s) a [Maybe S.Entity] > gettypes f t = (cris f) >>> > (arr $ filterExtends BaseWrite) >>> > (arr getComplexTypes) >>> > (arr (map complexTypeToEntity)) > }}} New description: The compiler told me to file this report. I hope this helps! Edit: Here is a minimal example which reproduces the error {{{#!hs bla :: ReaderT OmahaEnvironment IO () bla = do x <- lift getLine return () }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 11:34:33 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 11:34:33 -0000 Subject: [GHC] #10880: The 'impossible' happend In-Reply-To: <045.17c6a6181944c273e0d7be5fc752b3cf@haskell.org> References: <045.17c6a6181944c273e0d7be5fc752b3cf@haskell.org> Message-ID: <060.74c14239f480572714f62ebe16c4aaea@haskell.org> #10880: The 'impossible' happend ---------------------------------------+-------------------------------- Reporter: drever | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: ia64 Type of failure: Compile-time crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------------+-------------------------------- Description changed by drever: Old description: > The compiler told me to file this report. I hope this helps! > > Edit: Here is a minimal example which reproduces the error > > {{{#!hs > > bla :: ReaderT OmahaEnvironment IO () > bla = do > x <- lift getLine > return () > > }}} New description: The compiler told me to file this report. I hope this helps! {{{ drever$ cabal build Building xxx-0.0... Preprocessing library xxx-0.0... In-place registering xxx-0.0... Preprocessing executable 'xxx' for xxx-0.0... [21 of 21] Compiling Main ( src/main.hs, dist/build/xxx/xxx- tmp/Main.o ) src/main.hs:107:19: Couldn't match kind `* -> *' with `*' Expected type: FileName -> ReaderT XXXEnvironment IO t0 Actual type: FileName -> ReaderT XXXEnvironment IO t0 Kind incompatibility when matching types: FileName :: * -> * FileName :: * The function `lift'ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-apple-darwin): kindFunResult ghc-prim:GHC.Prim.*{(w) tc 34d} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} {{{#!hs generatecode :: (Entity -> [EntitySample]) -> ReaderT MyEnvironment IO () generatecode sample = do domain_xsd <- lift xsdEntities "test" }}} {{{#!hs xsdEntities :: String -> IO [Entity] xsdEntities f = do maybeEntities <- runX ((XS.gettypes f) BaseWrite) return $ catMaybes $ concat maybeEntities }}} {{{#!hs gettypes :: String -> MyType -> IOSLA (XIOState s) a [Maybe S.Entity] gettypes f t = (cris f) >>> (arr $ filterExtends BaseWrite) >>> (arr getComplexTypes) >>> (arr (map complexTypeToEntity)) }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 11:37:54 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 11:37:54 -0000 Subject: [GHC] #10875: Unexpected defaulting of partial type signatures and inconsistent behaviour when -fdefer-typed-holes is set. In-Reply-To: <047.47e931d5fc4e6515630dc5cf2498378f@haskell.org> References: <047.47e931d5fc4e6515630dc5cf2498378f@haskell.org> Message-ID: <062.ce98b402428f2658028fde972855d0d3@haskell.org> #10875: Unexpected defaulting of partial type signatures and inconsistent behaviour when -fdefer-typed-holes is set. -------------------------------------+------------------------------------- Reporter: holzensp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | PartialTypeSignatures TypedHoles Operating System: MacOS X | Architecture: x86_64 Type of failure: Incorrect | (amd64) warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by holzensp): If you're done with the refactoring and want someone to help test, by all means let me know. I see your point with regards to the defaulting rule from the language definition. In light of the typing rules, I'm unsure whether I would consider a typed hole to be like any other term. With a variable-typed term, like `undefined`, I agree that the typing rules should find ''whatever'' type satisfies. My interpretation of a typed hole, however, is that I'm asking GHC: "Please tell me what you expect me to put in here." After typing up my comment, though, I understand that `RealFrac b => a_bound_by_the_type_of_foo -> b` actually is not the correct type, because `round` actually binds `b`. In other words, it's not just that `round` imposes a `RealFrac` constraint on `b`, but the `b` of the hole should be precisely the same `b` as that of `round`. Somehow it should be something like `RealFrac b_bound_by_the_type_of_round => a_bound_by_the_type_of_foo -> b_bound_by_the_type_of_round`. I admit it's complicated, but purely from a TypedHoles user perspective, I think defaulting is... less then intuitive (fully aware of the subjectivity of that term). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 11:39:05 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 11:39:05 -0000 Subject: [GHC] #10880: The 'impossible' happend In-Reply-To: <045.17c6a6181944c273e0d7be5fc752b3cf@haskell.org> References: <045.17c6a6181944c273e0d7be5fc752b3cf@haskell.org> Message-ID: <060.ce9f26b6ae448b38998c38081fb27fff@haskell.org> #10880: The 'impossible' happend ---------------------------------------+--------------------------------- Reporter: drever | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: duplicate | Keywords: Operating System: MacOS X | Architecture: ia64 Type of failure: Compile-time crash | Test Case: Blocked By: | Blocking: Related Tickets: #8135 | Differential Revisions: ---------------------------------------+--------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #8135 Comment: Thanks for the report. This bug has been fixed in later releases of GHC. If you search for 'kindFunResult' you can find several other instances of it. Please upgrade, 7.6 is no longer supported. Sorry about that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 12:23:05 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 12:23:05 -0000 Subject: [GHC] #10653: PatternSynonyms should be imported/exported as part of the wildcard notation In-Reply-To: <049.0e5a3c33a167308dc99ecaed5730df14@haskell.org> References: <049.0e5a3c33a167308dc99ecaed5730df14@haskell.org> Message-ID: <064.681a8169278819c07cf9d86c26a8b312@haskell.org> #10653: PatternSynonyms should be imported/exported as part of the wildcard notation -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: mpickering Type: feature request | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: pattern | synonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by mpickering): Richard, could you please explain more what you mean in this paragraph? How are you imagining the implementation? > But I do think my proposal answers Simon's first point: the programmer says explicitly what should be included by any import of a datatype. This choice is checked in my proposal, but I don't imagine that would be a challenge to implement. The interface file would indicate what pattern synonyms are included with a datatype. It all doesn't seem very complicated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 12:38:24 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 12:38:24 -0000 Subject: [GHC] #10880: The 'impossible' happend In-Reply-To: <045.17c6a6181944c273e0d7be5fc752b3cf@haskell.org> References: <045.17c6a6181944c273e0d7be5fc752b3cf@haskell.org> Message-ID: <060.b111ecebd4599a66c3a24c4c5ab37627@haskell.org> #10880: The 'impossible' happend ---------------------------------------+--------------------------------- Reporter: drever | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: duplicate | Keywords: Operating System: MacOS X | Architecture: ia64 Type of failure: Compile-time crash | Test Case: Blocked By: | Blocking: Related Tickets: #8135 | Differential Revisions: ---------------------------------------+--------------------------------- Comment (by drever): Thanks for the fast response and sorry for the duplicate! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 12:42:48 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 12:42:48 -0000 Subject: [GHC] #7175: Panic when wrongly using a type family as return types for GADTs In-Reply-To: <047.441799c7bbeef8d39b2646811008e078@haskell.org> References: <047.441799c7bbeef8d39b2646811008e078@haskell.org> Message-ID: <062.ed9532a5144938c2543e14b5ab6a34d5@haskell.org> #7175: Panic when wrongly using a type family as return types for GADTs -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.6.1 Component: Compiler | Version: 7.6.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | typecheck/should_fail/T7175 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Hooray! Hooray! Hooray! This fix is quite straightforward, of course, but somehow this dark corner has lurked a long time. Thanks. I no longer don armor and surround myself in a cloud of fear and loathing every time I need to think about editing `rejigConRes`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 12:44:26 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 12:44:26 -0000 Subject: [GHC] #7175: Panic when wrongly using a type family as return types for GADTs In-Reply-To: <047.441799c7bbeef8d39b2646811008e078@haskell.org> References: <047.441799c7bbeef8d39b2646811008e078@haskell.org> Message-ID: <062.c08d25f139c582f9c28cbea2067cb353@haskell.org> #7175: Panic when wrongly using a type family as return types for GADTs -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.6.1 Component: Compiler | Version: 7.6.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | typecheck/should_fail/T7175 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): We try to please :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 13:11:37 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 13:11:37 -0000 Subject: [GHC] #10872: More informative assertion for non-unique TH names In-Reply-To: <048.31528093886b2ab66084097b2ba3a854@haskell.org> References: <048.31528093886b2ab66084097b2ba3a854@haskell.org> Message-ID: <063.712eb6137a7f480e698fe76f44dd1492@haskell.org> #10872: More informative assertion for non-unique TH names -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Your idea of where to put the assertion looks good, but I'm incredulous that the nasty `ASSERT` could kick in first. If there's no way to get at the `templateHaskellNames` without going through an assertion of their sensibility, then how could the contents of that list affect anything? Something is fishy somewhere. If you're stuck, post on Phab. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 13:14:01 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 13:14:01 -0000 Subject: [GHC] #10873: Bad error message for incorrect pattern synonym signature In-Reply-To: <049.1015737e7e3a324fd7db7cc49a97b354@haskell.org> References: <049.1015737e7e3a324fd7db7cc49a97b354@haskell.org> Message-ID: <064.1f085b4591f7202b280d462446417c97@haskell.org> #10873: Bad error message for incorrect pattern synonym signature -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Ich. Agreed that the error message is terrible. Also agreed with your analysis of this (confusing) situation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 13:39:43 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 13:39:43 -0000 Subject: [GHC] #10478: Shorter import syntax In-Reply-To: <046.5e60b02b9fe497cdf59ecd5b37a450a2@haskell.org> References: <046.5e60b02b9fe497cdf59ecd5b37a450a2@haskell.org> Message-ID: <061.10dca5de16fb5ba2f29f7abf9ed383c2@haskell.org> #10478: Shorter import syntax -------------------------------------+------------------------------------- Reporter: acowley | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1238 -------------------------------------+------------------------------------- Comment (by goldfire): Perhaps my proposal was not clearly stated. I have modified the examples below to support my intent. If you see an error in the proposal, please do let me know! My changes affect the first block and the very last line. > > Suppose the `module A` exports `x` and `y`. > > * Without a module alias: > ||= # =||= Haskell 2010 =||= Proposal acowley =||= Proposal goldfire =||= Brings into scope =|| > ||= 1 =|| import A || **import A** || **import A** || x, y, A.x, A.y || > ||= 2 =|| import A (x) || **import A (x)** || **import A (x)** || x, A.x || > ||= 3 =|| import qualified A || **import A () as A** || **import A qualified** || A.x, A.y || > ||= 4 =|| import qualified A (x) || **import A () as A (x)** || **import A qualified (x)** || A.x || > > * With a module alias: > ||= # =||= Haskell 2010 =||= Proposal acowley =||= Proposal goldfire =||= Brings into scope =|| > ||= 5 =|| import A as B || **import A as B** || **import A (..) qualified as B** || x, y, B.x, B.y || > ||= 6 =|| import A as B (x) || **import A as B (x)** || **import A (x) qualified as B (x)** || x, B.x || > ||= 7 =|| import qualified A as B || **import A () as B** || **import A qualified as B** || B.x, B.y || > ||= 8 =|| import qualified A as B (x) || **import A () as B (x)** || **import A qualified as B (x)** || B.x || > > * The real deal: > ||= # =||= Haskell 2010 =||= Proposal acowley =||= Proposal goldfire =||= Brings into scope =|| > ||= 9 =|| import A (x); || **import A (x) as B** || **import A (x) qualified as B** || x, B.x, B.y || > || || import qualified A as B || > ||= 10 =|| //(impossible)// || **import A (x) as X ()** || **import A (x) qualified ()** || x || > > > Potentially confusing things about these proposals, assuming full backward compatibility: > > ||= proposal =||= H2010 syntax =||= new syntax =||= Why confusing? =|| > ||= acowley =|| **import A as B (x)** || **import A (x) as B** || look similar, do different things || > ||= goldfire =|| **import qualified A as B (x)** || **import A (x) qualified as B** || look similar, do different things || > ||= goldfire =|| **import qualified A** || **import A qualified** || look similar, do different things || -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 14:07:06 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 14:07:06 -0000 Subject: [GHC] #10478: Shorter import syntax In-Reply-To: <046.5e60b02b9fe497cdf59ecd5b37a450a2@haskell.org> References: <046.5e60b02b9fe497cdf59ecd5b37a450a2@haskell.org> Message-ID: <061.fa4a519f9486b92277f18211e77de569@haskell.org> #10478: Shorter import syntax -------------------------------------+------------------------------------- Reporter: acowley | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1238 -------------------------------------+------------------------------------- Comment (by thomie): What is the difference between `import qualified A` and `import A qualified` (row 3)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 14:50:34 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 14:50:34 -0000 Subject: [GHC] #10867: Primop types should not mention () In-Reply-To: <046.c2e6159f1c64c1079ec9b781aa715970@haskell.org> References: <046.c2e6159f1c64c1079ec9b781aa715970@haskell.org> Message-ID: <061.4f3fe24457e07abcb156cdaf5168d13f@haskell.org> #10867: Primop types should not mention () -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): OK, talked to Simon. My "I believe the following.." is false. In fact all those finalisers are packed into an array in `Weak.c` (function `scheduleFinalizers`) and handed off to the Haskell function `GHC.Weak.runFinalizerBatch`. So the latter certainly needs to know the type of the finaliser. With that in mind, I think we should not change the `Weak#` type (as I wrongly proposed above) but instead change the type of `mkWeak#` to {{{ primop MkWeakOp "mkWeak#" GenPrimOp key -> value -> (State# RealWorld -> State# RealWorld) -> (# State# RealWorld, Weak# b #) }}} and `GHC.Weak.runFinalizerBatch` to {{{ runFinalizerBatch :: Int -> Array# (State# RealWorld -> State# RealWorld) -> IO () }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 15:05:14 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 15:05:14 -0000 Subject: [GHC] #10653: PatternSynonyms should be imported/exported as part of the wildcard notation In-Reply-To: <049.0e5a3c33a167308dc99ecaed5730df14@haskell.org> References: <049.0e5a3c33a167308dc99ecaed5730df14@haskell.org> Message-ID: <064.a92dabb8774cdbcb038b5d70881ac4a7@haskell.org> #10653: PatternSynonyms should be imported/exported as part of the wildcard notation -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: mpickering Type: feature request | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: pattern | synonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): I think Simon's worry is that there will be some inference of associations between pattern synonyms and datatypes. In the proposals as I see them, this is ''not'' the case. The programmer declares, in an export list, what to export with what. No type-checking needed. If we want (and I'm not sure we do), we can add validity checks after type-checking to make sure that associated pattern synonyms (or arbitrary values) have suitable types (for some yet-to-be-specified meaning of "suitable"). Does that clarify? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 15:30:04 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 15:30:04 -0000 Subject: [GHC] #10478: Shorter import syntax In-Reply-To: <046.5e60b02b9fe497cdf59ecd5b37a450a2@haskell.org> References: <046.5e60b02b9fe497cdf59ecd5b37a450a2@haskell.org> Message-ID: <061.d498bf84bb3b433822441859ddb61872@haskell.org> #10478: Shorter import syntax -------------------------------------+------------------------------------- Reporter: acowley | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1238 -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:14 thomie]: > What is the difference between `import qualified A` and `import A qualified` (row 3)? You're right. Those are the same. I've edited it all to clarify. `import qualified A (..)` brings `A.x` and `A.y` into scope. `import A (..) qualified` brings `x`, `y`, `A.x`, and `A.y` into scope. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 17:28:41 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 17:28:41 -0000 Subject: [GHC] #10478: Shorter import syntax In-Reply-To: <046.5e60b02b9fe497cdf59ecd5b37a450a2@haskell.org> References: <046.5e60b02b9fe497cdf59ecd5b37a450a2@haskell.org> Message-ID: <061.2ada2437dac7b26cfd020124ab867af6@haskell.org> #10478: Shorter import syntax -------------------------------------+------------------------------------- Reporter: acowley | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1238 -------------------------------------+------------------------------------- Comment (by acowley): Replying to [comment:12 thomie]: > Potentially confusing things about these proposals, assuming full backward compatibility: > > ||= proposal =||= H2010 syntax =||= new syntax =||= Why confusing? =|| > ||= acowley =|| **import A as B (x)** || **import A (x) as B** || look similar, do different things || Just to chime in to confirm that this is the most ripe for confusion part of the proposal. No semantics of working code change with the extension enabled, but this point of confusion is introduced. For context, the syntax `import A as B (x)` is used in 0.3% of all `import` statements over all the code in the Stackage package set. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 19:10:26 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 19:10:26 -0000 Subject: [GHC] #10478: Shorter import syntax In-Reply-To: <046.5e60b02b9fe497cdf59ecd5b37a450a2@haskell.org> References: <046.5e60b02b9fe497cdf59ecd5b37a450a2@haskell.org> Message-ID: <061.953594d30c197f4f80d9adab9aab4e8d@haskell.org> #10478: Shorter import syntax -------------------------------------+------------------------------------- Reporter: acowley | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1238 -------------------------------------+------------------------------------- Comment (by thomie): acowley: you could avoid the confusion by saying `import A (x) as B (..)`. But I'm not sure that's worth it. Summary of the previous [https://mail.haskell.org/pipermail/haskell- cafe/2015-June/119942.html mailinglist discussion] and [https://www.reddit.com/r/haskell/comments/38vsef/proposal_shorter_import_syntax/ reddit] thread: * A lot (15?) of people on the mailinglist were in favour of acowley's proposal, or at least for some form of shorter import syntax. * Only [https://mail.haskell.org/pipermail/haskell- cafe/2015-June/119958.html one] person was specifically in favour of goldfire's proposal. I think this low number had more to do with the proposal not being presented very clearly than anything else, given how similar the two proposals are. * A few people were (strongly) against acowley's proposal, all citing [https://mail.haskell.org/pipermail/haskell-cafe/2015-June/119982.html Richard O'Keefe's mail]. * [https://www.reddit.com/r/haskell/comments/38vsef/proposal_shorter_import_syntax/ reddit] seemed firmly against acowley's proposal as well (the top comment has 12 votes and starts with "-1"). This is the reason I think we should proceed carefully here. I don't think this is going to go anywhere without someone writing a [https://ghc.haskell.org/trac/ghc/wiki/Proposal proposal page] on the wiki, with specifications of the 2 options and the above table, and then having another round of discussion on the mailinglist. If one of you could get behind the other person's proposal, that would make things easier as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 20:39:16 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 20:39:16 -0000 Subject: [GHC] #10881: internal error: evacuate: strange closure type 5101248 Message-ID: <045.d8291d7d3474f8067bb2d61da8cd20dc@haskell.org> #10881: internal error: evacuate: strange closure type 5101248 -------------------------------------+------------------------------------- Reporter: burbly | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.10.2 System | Keywords: strange | Operating System: Windows closure type 5101248 | Architecture: x86_64 | Type of failure: Runtime crash (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Running a compiled executable on some complex input is causing this: postparse.exe: internal error: evacuate: strange closure type 5101248 (GHC version 7.10.2 for x86_64_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Running under Cygwin on Windows 8.1, 64. I suspect this may be a memory-related issue, but it's hard to diagnose as postparse.exe is operating in a larger ecosystem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 21:37:57 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 21:37:57 -0000 Subject: [GHC] #9907: "Unknown PEi386 section name `.text$printf'" error in GHCi on Windows In-Reply-To: <051.9bd9875fb01e6198fe81abe3cec3e53a@haskell.org> References: <051.9bd9875fb01e6198fe81abe3cec3e53a@haskell.org> Message-ID: <066.21a7cf2a955f96cccee3398dae4ce0e9@haskell.org> #9907: "Unknown PEi386 section name `.text$printf'" error in GHCi on Windows -------------------------------------+------------------------------------- Reporter: mmikolajczyk | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: 7.10.3 Component: GHCi | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #7103, #10051, | Differential Revisions: Phab:D1244 #7056, #8546 | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => patch * differential: Phab:D671 => Phab:D1244 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 21:39:34 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 21:39:34 -0000 Subject: [GHC] #10672: GHCi linker does not understand C++ exception tables on Windows In-Reply-To: <045.04cee7c60b130b0ccc29791ed61c4f5f@haskell.org> References: <045.04cee7c60b130b0ccc29791ed61c4f5f@haskell.org> Message-ID: <060.db31a8f7c68650f4d28909138ffe4043@haskell.org> #10672: GHCi linker does not understand C++ exception tables on Windows -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Phyx- Type: bug | Status: patch Priority: high | Milestone: 7.10.3 Component: Runtime System | Version: 7.10.1 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #9297 #10563 | Differential Revisions: Phab:D1244 #8237 #9907 | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => patch * differential: => Phab:D1244 Comment: Thanks for verifying @lukexi!. Good to hear that it worked for your test cases as well. Patch has been submitted for review :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 21:52:25 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 21:52:25 -0000 Subject: [GHC] #10653: PatternSynonyms should be imported/exported as part of the wildcard notation In-Reply-To: <049.0e5a3c33a167308dc99ecaed5730df14@haskell.org> References: <049.0e5a3c33a167308dc99ecaed5730df14@haskell.org> Message-ID: <064.303ffb45069291e94b09af4ae96eaf6d@haskell.org> #10653: PatternSynonyms should be imported/exported as part of the wildcard notation -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: mpickering Type: feature request | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: pattern | synonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Replying to [comment:22 goldfire]: > I think Simon's worry is that there will be some inference of associations between pattern synonyms and datatypes. In the proposals as I see them, this is ''not'' the case. ... Does that clarify? Alas, no. I simply don't know what the proposal ''is''! I'd love to see a specification. Then I'd know if I was worried or not :-). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 21:52:26 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 21:52:26 -0000 Subject: [GHC] #10882: Fix target tripe for Arm Message-ID: <044.1d80e9fba68d0b423d46d5881d8a4187@haskell.org> #10882: Fix target tripe for Arm -----------------------------------+--------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Linux Architecture: arm | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -----------------------------------+--------------------------------- LLVM IR code generated by GHC on Arm (Debian) uses a target triple of "arm-linux-gnueabi" which according the LLVM people is something like ARMv4 with software float. Clang on the other hand generates IR code with a target triple of "armv6 -linux-gnueablhf" which is ARMv6 and hardware float so it works on the original Raspberry Pi. GHC should either use the same target triple as Clang or at least make it configurable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 21:52:58 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 21:52:58 -0000 Subject: [GHC] #10882: Fix target triple for Arm (was: Fix target tripe for Arm) In-Reply-To: <044.1d80e9fba68d0b423d46d5881d8a4187@haskell.org> References: <044.1d80e9fba68d0b423d46d5881d8a4187@haskell.org> Message-ID: <059.da535f3c98167b50b3b415259e140573@haskell.org> #10882: Fix target triple for Arm ---------------------------------+--------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------+--------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 21:58:57 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 21:58:57 -0000 Subject: [GHC] #10478: Shorter import syntax In-Reply-To: <046.5e60b02b9fe497cdf59ecd5b37a450a2@haskell.org> References: <046.5e60b02b9fe497cdf59ecd5b37a450a2@haskell.org> Message-ID: <061.e4bf83cf39f17cce22357082ca139a1a@haskell.org> #10478: Shorter import syntax -------------------------------------+------------------------------------- Reporter: acowley | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1238 -------------------------------------+------------------------------------- Comment (by thomie): More explicitly, @acowley: * Could you please start a `Proposal/ShortImports` wiki page with a specification of your language extension? * What is your opinion on goldfire's alternative proposal (see comment:3 and comment:13)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 21:59:04 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 21:59:04 -0000 Subject: [GHC] #10879: base is not included in the haddock index In-Reply-To: <048.8713266ddcd63f131d79fa94bba781e8@haskell.org> References: <048.8713266ddcd63f131d79fa94bba781e8@haskell.org> Message-ID: <063.b1af6073fcfd86d3ccb9b58aa18e9bca@haskell.org> #10879: base is not included in the haddock index -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by hvr): Curiously, it's contained in here: http://downloads.haskell.org/~ghc/7.10.2/docs/html/libraries/index.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 22:26:18 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 22:26:18 -0000 Subject: [GHC] #10428: GHC cannot match representations using Coercible constraint In-Reply-To: <047.fbead4304e2da30bbf57add55471b5d0@haskell.org> References: <047.fbead4304e2da30bbf57add55471b5d0@haskell.org> Message-ID: <062.e0886988e62b075082ab010c9051856f@haskell.org> #10428: GHC cannot match representations using Coercible constraint -------------------------------------+------------------------------------- Reporter: crockeea | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T10428 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by crockeea): * milestone: => 7.10.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 23:00:12 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 23:00:12 -0000 Subject: [GHC] #10478: Shorter import syntax In-Reply-To: <046.5e60b02b9fe497cdf59ecd5b37a450a2@haskell.org> References: <046.5e60b02b9fe497cdf59ecd5b37a450a2@haskell.org> Message-ID: <061.c85777c99182b512cddc93fac9706e31@haskell.org> #10478: Shorter import syntax -------------------------------------+------------------------------------- Reporter: acowley | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1238 -------------------------------------+------------------------------------- Comment (by acowley): No, I need to stop this exercise in futility. I canvassed IRC and received broad support, I canvassed on twitter and received broad support, I canvassed on haskell-cafe and received mixed support. I did the work of analyzing public code to characterize how common the confusing case would be months ago. This is support from nearly a hundred people for a minor language extension that breaks absolutely nothing. I have never seen so much voting for a GHC language extension. The code is now available with tests and documentation updates. Despite the small text of the original ticket above, it has been mis- characterized as breaking existing code time and time again, even today on the Phabricator discussion. You have now linked to a reddit post on what is actually an alternate proposal (`andAs`). When I follow your link, I see a +10 post saying -1 linking to sarcastic posts arguing that syntactic changes are unacceptable from an individual who cheers for (::Type) syntax, I see a +9 post that's +1 for shorter syntax, and a +8 for shorter syntax with my proposal (again, on a thread for an ''alternate'' proposal). I think @goldfire's proposal, though well intentioned, largely misses the point of offering more concise syntax, and includes more confusing cases. The stark lack of support it has received despite being from a regular GHC developer ought to be telling, yet is here dismissed as an odd coincidence. The patch is available. It does what I have written here, in the commit messages, and in the updated GHC documentation. The last time this went through the mailing list I received abusive mails for days, followed by apologies for the community's behavior for even more days. I am not doing that again. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 23:01:59 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 23:01:59 -0000 Subject: [GHC] #10375: arm: ghci hits an illegal instruction In-Reply-To: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> References: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> Message-ID: <059.8a21d2a9b250399926fa6bd40f5e805f@haskell.org> #10375: arm: ghci hits an illegal instruction -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: Runtime System | Version: 7.10.1 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by erikd): Added some debug to `rts/Linker.c` to print anything related to the function `hSetBuffering` and get: {{{ GHCi, version 7.11.20150912: http://www.haskell.org/ghc/ :? for help HSbase-4.8.2.0-FkKrfrxMoa06H6w6uNoJiJ.o, nentires 414047, section 1, symtab 14, strtab 15 base_GHCziIOziHandle_hSetBuffering1_entry is 0xb3eb63cd, is_thumb 1, R_ARM_THM_MOVW_ABS_NC base_GHCziIOziHandle_hSetBuffering1_entry is 0xb3eb63cd, is_thumb 1, R_ARM_THM_MOVT_ABS HSbase-4.8.2.0-FkKrfrxMoa06H6w6uNoJiJ.o, nentires 103794, section 2, symtab 14, strtab 15 base_GHCziIOziHandle_hSetBuffering1_info is 0xb4198738, is_thumb 0, R_ARM_ABS32 base_GHCziIOziHandle_hSetBuffering1_closure is 0xb41965b0, is_thumb 0, R_ARM_ABS32 base_GHCziIOziHandle_hSetBuffering_entry is 0xb3eb6471, is_thumb 1, R_ARM_ABS32 base_GHCziIOziHandle_hSetBuffering_info is 0xb4198718, is_thumb 0, R_ARM_ABS32 base_GHCziIOziHandle_hSetBuffering1_entry is 0xb3eb63cd, is_thumb 1, R_ARM_ABS32 turnOffBuffering start turnOffBuffering middle Illegal instruction }}} Not sure why `base_GHCziIOziHandle_hSetBuffering1_entry` has 3 entries, all with the same address, but with different `ELF_R_TYPE` types, ie `R_ARM_THM_MOVW_ABS_NC`, `R_ARM_THM_MOVT_ABS` and `R_ARM_THM_MOVT_ABS`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 23:04:35 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 23:04:35 -0000 Subject: [GHC] #10375: arm: ghci hits an illegal instruction In-Reply-To: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> References: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> Message-ID: <059.7433484e65d1f1ffc278da2629e2ff69@haskell.org> #10375: arm: ghci hits an illegal instruction -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: Runtime System | Version: 7.10.1 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by erikd): According to `readelf -S` on the object file the sections are: {{{ Section Headers: [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [ 0] NULL 00000000 000000 000000 00 0 0 0 [ 1] .text PROGBITS 00000000 000038 4c7518 00 AX 0 0 8 [ 2] .data PROGBITS 00000000 4c7550 111ab8 00 WA 0 0 8 [ 3] .bss NOBITS 00000000 5d9008 000000 00 WA 0 0 4 [ 4] .init_array INIT_ARRAY 00000000 5d9008 000004 00 WA 0 0 4 [ 5] .rodata.str1.4 PROGBITS 00000000 5d900c 00000e 01 AMS 0 0 4 [ 6] .rodata PROGBITS 00000000 5d901c 00dd40 00 A 0 0 4 [ 7] .comment PROGBITS 00000000 5e6d5c 00001d 01 MS 0 0 1 [ 8] .rel.text REL 00000000 5e6d7c 328af8 08 I 14 1 4 [ 9] .rel.data REL 00000000 90f874 0cab90 08 I 14 2 4 [10] .rel.init_array REL 00000000 9da404 000008 08 I 14 4 4 [11] .rel.rodata REL 00000000 9da40c 008820 08 I 14 6 4 [12] .note.GNU-stack PROGBITS 00000000 9e2c2c 000000 00 0 0 0 [13] .ARM.attributes ARM_ATTRIBUTES 00000000 9e2c2c 000035 00 0 0 1 [14] .symtab SYMTAB 00000000 9e2c64 29dc00 10 15 122623 4 [15] .strtab STRTAB 00000000 c80864 2dd2e5 00 0 0 1 [16] .shstrtab STRTAB 00000000 f5db49 000088 00 0 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings) I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown) O (extra OS processing required) o (OS specific), p (processor specific) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 14 23:41:01 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Sep 2015 23:41:01 -0000 Subject: [GHC] #9636: Function with type error accepted In-Reply-To: <047.40d618ba556abcff453b3e145ac728eb@haskell.org> References: <047.40d618ba556abcff453b3e145ac728eb@haskell.org> Message-ID: <062.5c00b824aa0d20d2f84d00bf0b004170@haskell.org> #9636: Function with type error accepted -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by DerekElkins): This is a fun one. We can look at what some other systems do in similar situations. comment:17 talks about handling unevaluated terms and the discussion has been talking about partial functions. One system that deals in this realm is Computational Type Theory (CTT), the type theory underlying NuPRL (and now JonPRL). In NuPRL you can literally write the equivalent of: {{{#!hs T Int = Bool T x = fix id }}} Obviously NuPRL doesn't loop forever when it encounters T Bool. It will do some computation to see if it can decide the proposition, but if it can't it gives up and makes it a proof obligation that the user must discharge. Since CTT is based on partial equivalence relations, T Bool ~ T Bool presents no problem. Reflexivity is not given, so that's a statement that needs to be proven. Indeed, typing Lennart's f from the bug report, requires, as usual, deriving that T Bool :: * and in CTT this is by definition T Bool ~ T Bool. Clearly GHC has evidence allowing it to automatically show the proof obligation is not achievable in this case. Thus the analogous situation in CTT would be a type error. In comment:19 Lennart mentions that we still have logic programming at the type level. One way of interpreting this is to give (closed) type families Curry's semantics, i.e. narrowing, but restricted to functional relations, so no (truly) overlapping patterns. This would be a language where a function returns at most one result rather than exactly one result as in a functional language. Still, T Bool would narrow the result set to the empty set and thus be a type error. Alternatively, Lennart may have just been referring to working with uninterpreted functions, something commonly done in logic programming, but in no way restricted to logic programming. Of course, T isn't an uninterpreted function, T Int ~ Bool. We could say it's a quotient of a type of uninterpreted functions modulo the relation T Int ~ Bool. We can push this idea a little. If someone wants to play with the current behavior in a more explicit manner all one needs to do is open up Agda and type: {{{#!hs import Level data Unit : Set where U : Unit data Bool : Set where True : Bool; False : Bool data _==_ {l}{A : Set l} (a : A) : A -> Set l where refl : a == a subst : {l : Level.Level}{A B : Set l} -> (A == B) -> A -> B subst refl x = x postulate T : Set -> Set postulate T_Bool_is_Unit : T Bool == Unit f : T Unit -> Bool f _ = True g : T Bool -> Unit g x = subst T_Bool_is_Unit x h : T Bool == T Bool -> Unit h refl = U }}} To handle overlapping, explicit inequality evidence needs to be provided. This suggests that like we can view a data declaration as adding a constructor to (codes for) *. A type family could be viewed into making that data type a higher inductive type (from Homotopy Type Theory). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 15 00:55:24 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Sep 2015 00:55:24 -0000 Subject: [GHC] #10878: Near doubling of generated code size for compiler/cmm/PprC.hs with commit 5d57087e31 In-Reply-To: <044.9d94a947d4932234addf1109fa44fa7c@haskell.org> References: <044.9d94a947d4932234addf1109fa44fa7c@haskell.org> Message-ID: <059.0c1cb7e8b1b51aae96ed0675cfbca166@haskell.org> #10878: Near doubling of generated code size for compiler/cmm/PprC.hs with commit 5d57087e31 -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by erikd): Also, the `NOLINE` suggestion didn't fix the PowerPC build (stage2 still fails) as noted in https://ghc.haskell.org/trac/ghc/ticket/7830#comment:31 . -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 15 01:37:25 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Sep 2015 01:37:25 -0000 Subject: [GHC] #10878: Near doubling of generated code size for compiler/cmm/PprC.hs with commit 5d57087e31 In-Reply-To: <044.9d94a947d4932234addf1109fa44fa7c@haskell.org> References: <044.9d94a947d4932234addf1109fa44fa7c@haskell.org> Message-ID: <059.266d58ffdbf97c6b6b134decd33d02bd@haskell.org> #10878: Near doubling of generated code size for compiler/cmm/PprC.hs with commit 5d57087e31 -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by erikd): Seems #8901 may be related. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 15 08:08:21 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Sep 2015 08:08:21 -0000 Subject: [GHC] #229: Integer overflow in array allocation In-Reply-To: <045.791e3ea8f042e6c7d57ae4cd25dec693@haskell.org> References: <045.791e3ea8f042e6c7d57ae4cd25dec693@haskell.org> Message-ID: <060.5eb1930619b36534169fc6ee06cda82d@haskell.org> #229: Integer overflow in array allocation -------------------------------------+------------------------------------- Reporter: josefs | Owner: rwbarton Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Core Libraries | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by WrenThornton): * priority: normal => high * cc: wrengr (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 15 09:35:19 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Sep 2015 09:35:19 -0000 Subject: [GHC] #3242: ghci: can't load .so/.DLL for: m (addDLL: could not load DLL) In-Reply-To: <045.426dc6319f98492c5b511466045bc0b5@haskell.org> References: <045.426dc6319f98492c5b511466045bc0b5@haskell.org> Message-ID: <060.c7dba8c17e95d85f6862d9667f4811dc@haskell.org> #3242: ghci: can't load .so/.DLL for: m (addDLL: could not load DLL) ---------------------------------+-------------------------------- Reporter: jeffz1 | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.4.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: 3658 | Blocking: Related Tickets: #7097 | Differential Revisions: ---------------------------------+-------------------------------- Changes (by WrenThornton): * priority: normal => high * cc: wrengr (added) Comment: @oerjan Yes, I've long known about and documented this problem in the INSTALL/README file for the logfloat package. It's always been there in the repo and tarball, but hopefully is more visible now that Hackage has links to readme files. There used to be another ticket for this problem, though I lost the ticket number over the years so the readme only gives a short description of the problem (i'll add this ticket number to the readme once I get home). The long description of the situation so far as I'm aware/concerned is: For *compiled* code, everything works perfectly fine? without the need for Cygwin or Mingw/Msys or any of that. The problem is specifically with GHCi. The C functions that logfloat needs live in what posix calls "libm", thus we have "Extra-Libraries: m" in the cabal file. However, as nus mentions, MinGW's so-called "libm" file (which ships with GHC) is just a dummy header with no actual content; therefore the cabal file is useless here. The actual symbols/C-code lives in the libmingwex.a library (which also ships with GHC). When compiling, libmingwex.a is picked up automagically and so everything works; whereas when using the interpreter, libmingwex.a is ignored and the loading error is generated. This bug has been a thorn in my side for years. I don't use Windows, but I have many users who do and who have to work around the problem on a daily basis. The only feasible workaround at present is to compile logfloat without FFI support (thereby eliminating most of the precision which is the entire point of the library) in order to do any sort of interactive debugging or development, and then hopefully remembering to recompile logfloat and everything that depends on it (to get precision) before shipping. I really wish we could just get this fixed already so I don't have to explain the sorry state of things to yet another machine learning / natural language processing person just trying out Haskell. This really makes a terrible impression on folks :( -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 15 10:11:19 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Sep 2015 10:11:19 -0000 Subject: [GHC] #3242: ghci: can't load .so/.DLL for: m (addDLL: could not load DLL) In-Reply-To: <045.426dc6319f98492c5b511466045bc0b5@haskell.org> References: <045.426dc6319f98492c5b511466045bc0b5@haskell.org> Message-ID: <060.207d59d1e6cb0ae3237540b2d394925a@haskell.org> #3242: ghci: can't load .so/.DLL for: m (addDLL: could not load DLL) ---------------------------------+-------------------------------- Reporter: jeffz1 | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.4.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: 3658 | Blocking: Related Tickets: #7097 | Differential Revisions: ---------------------------------+-------------------------------- Changes (by WrenThornton): * cc: wrengr (removed) * cc: winterkoninkje+ghc@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 15 10:11:34 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Sep 2015 10:11:34 -0000 Subject: [GHC] #229: Integer overflow in array allocation In-Reply-To: <045.791e3ea8f042e6c7d57ae4cd25dec693@haskell.org> References: <045.791e3ea8f042e6c7d57ae4cd25dec693@haskell.org> Message-ID: <060.8d8066c6481c6e32db7855b7b3adfee1@haskell.org> #229: Integer overflow in array allocation -------------------------------------+------------------------------------- Reporter: josefs | Owner: rwbarton Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Core Libraries | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by WrenThornton): * cc: wrengr (removed) * cc: winterkoninkje+ghc@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 15 10:14:14 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Sep 2015 10:14:14 -0000 Subject: [GHC] #4937: Remove indirections caused by sum types, such as Maybe In-Reply-To: <044.b23df86df7a378aae0b2791d9692a9ef@haskell.org> References: <044.b23df86df7a378aae0b2791d9692a9ef@haskell.org> Message-ID: <059.bad43e91ac024f6cb65a4fe3ddec402f@haskell.org> #4937: Remove indirections caused by sum types, such as Maybe -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by WrenThornton): * cc: winterkoninkje+ghc@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 15 10:15:38 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Sep 2015 10:15:38 -0000 Subject: [GHC] #229: Integer overflow in array allocation In-Reply-To: <045.791e3ea8f042e6c7d57ae4cd25dec693@haskell.org> References: <045.791e3ea8f042e6c7d57ae4cd25dec693@haskell.org> Message-ID: <060.a82c7eb9afb48000d02fc58ad96d856e@haskell.org> #229: Integer overflow in array allocation -------------------------------------+------------------------------------- Reporter: josefs | Owner: rwbarton Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Core Libraries | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by WrenThornton): * cc: winterkoninkje+ghc@? (removed) * cc: wren@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 15 10:15:56 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Sep 2015 10:15:56 -0000 Subject: [GHC] #3242: ghci: can't load .so/.DLL for: m (addDLL: could not load DLL) In-Reply-To: <045.426dc6319f98492c5b511466045bc0b5@haskell.org> References: <045.426dc6319f98492c5b511466045bc0b5@haskell.org> Message-ID: <060.42f2398aadda7c01bf32476e064fd980@haskell.org> #3242: ghci: can't load .so/.DLL for: m (addDLL: could not load DLL) ---------------------------------+-------------------------------- Reporter: jeffz1 | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.4.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: 3658 | Blocking: Related Tickets: #7097 | Differential Revisions: ---------------------------------+-------------------------------- Changes (by WrenThornton): * cc: winterkoninkje+ghc@? (removed) * cc: wren@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 15 10:16:12 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Sep 2015 10:16:12 -0000 Subject: [GHC] #4937: Remove indirections caused by sum types, such as Maybe In-Reply-To: <044.b23df86df7a378aae0b2791d9692a9ef@haskell.org> References: <044.b23df86df7a378aae0b2791d9692a9ef@haskell.org> Message-ID: <059.16a312814bb92f5f9caf8765f58aa20f@haskell.org> #4937: Remove indirections caused by sum types, such as Maybe -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by WrenThornton): * cc: winterkoninkje+ghc@? (removed) * cc: wren@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 15 10:17:40 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Sep 2015 10:17:40 -0000 Subject: [GHC] #4385: Type-level natural numbers In-Reply-To: <047.cc0a64c6c51b4985aaaaf093ec247386@haskell.org> References: <047.cc0a64c6c51b4985aaaaf093ec247386@haskell.org> Message-ID: <062.d37c0f17c52d64278079894c37b31e18@haskell.org> #4385: Type-level natural numbers -------------------------------------+------------------------------------- Reporter: diatchki | Owner: diatchki Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by WrenThornton): * cc: wren@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 15 10:19:38 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Sep 2015 10:19:38 -0000 Subject: [GHC] #4470: Loop optimization: identical counters In-Reply-To: <048.cb41d64039b8fe820bdccdd94bb5c1a4@haskell.org> References: <048.cb41d64039b8fe820bdccdd94bb5c1a4@haskell.org> Message-ID: <063.d21d1c124019ffe904b603fcb495f1e8@haskell.org> #4470: Loop optimization: identical counters -------------------------------------+------------------------------------- Reporter: choenerzs | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: Resolution: | Keywords: loop | optimization Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by WrenThornton): * cc: wren@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 15 10:24:58 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Sep 2015 10:24:58 -0000 Subject: [GHC] #5615: ghc produces poor code for `div` with constant powers of 2. In-Reply-To: <046.611e1011b849d674524f2ee05d864a89@haskell.org> References: <046.611e1011b849d674524f2ee05d864a89@haskell.org> Message-ID: <061.86243f840bb57440f7b0eeedf2902483@haskell.org> #5615: ghc produces poor code for `div` with constant powers of 2. -------------------------------------+------------------------------------- Reporter: Lennart | Owner: | daniel.is.fischer Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.4.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by WrenThornton): * cc: wren@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 15 10:43:09 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Sep 2015 10:43:09 -0000 Subject: [GHC] #5692: Source code with large floating constants in exponential notation cannot be compiled In-Reply-To: <046.9c0670fdc22c4eddb346525c684e623e@haskell.org> References: <046.9c0670fdc22c4eddb346525c684e623e@haskell.org> Message-ID: <061.0dc6f481cca443ca0a99006c03e58df4@haskell.org> #5692: Source code with large floating constants in exponential notation cannot be compiled -------------------------------------+------------------------------------- Reporter: gracjan | Owner: pcapriotti Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: 5688 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by WrenThornton): * cc: wren@? (added) Comment: FWIW, the [http://hackage.haskell.org/package/bytestring-lexing bytestring-lexing] library has extremely efficient implementations of reading real literals for types which have limited precision (e.g., `Float` and `Double`). The functions in question are `readDecimalLimited` and `readExponentialLimited` in `Data.ByteString.Lex.Fractional`. The repo for the package also includes benchmarks. Surely GHC doesn't need to optimize lexing quite so much as bytestring- lexing has done, but in the interest of minimizing code duplication/maintenance, I would be totally fine having bytestring-lexing become one of the core libraries GHC uses. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 15 10:47:26 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Sep 2015 10:47:26 -0000 Subject: [GHC] #7259: Eta expansion of products in System FC In-Reply-To: <046.eb91fb12bdf35396d79679c78f7a6c38@haskell.org> References: <046.eb91fb12bdf35396d79679c78f7a6c38@haskell.org> Message-ID: <061.243d1993320aa66b6503d9532c046770@haskell.org> #7259: Eta expansion of products in System FC -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by WrenThornton): * cc: wren@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 15 10:51:05 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Sep 2015 10:51:05 -0000 Subject: [GHC] #7542: GHC doesn't optimize (strict) composition with id In-Reply-To: <046.3bbc04071c1dd827d32f98edcf90fd64@haskell.org> References: <046.3bbc04071c1dd827d32f98edcf90fd64@haskell.org> Message-ID: <061.4338bdf212dfc15fb02e57e40bd04516@haskell.org> #7542: GHC doesn't optimize (strict) composition with id -------------------------------------+------------------------------------- Reporter: shachaf | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by WrenThornton): * cc: wren@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 15 10:56:44 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Sep 2015 10:56:44 -0000 Subject: [GHC] #9251: ghc does not expose branchless max/min operations as primops In-Reply-To: <045.e29eb1e7c055c049cd093a2df9caa8db@haskell.org> References: <045.e29eb1e7c055c049cd093a2df9caa8db@haskell.org> Message-ID: <060.32ce8eef62926cb3c00cfe2381e9c534@haskell.org> #9251: ghc does not expose branchless max/min operations as primops -------------------------------------+------------------------------------- Reporter: carter | Owner: osa1 Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9246 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by WrenThornton): * cc: wren@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 15 11:01:18 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Sep 2015 11:01:18 -0000 Subject: [GHC] #4413: (^^) is not correct for Double and Float In-Reply-To: <056.b95b95b9854cc31706fe2ec11ee3d940@haskell.org> References: <056.b95b95b9854cc31706fe2ec11ee3d940@haskell.org> Message-ID: <071.f50c26fc23b167af7d13c833b4c6cf80@haskell.org> #4413: (^^) is not correct for Double and Float -------------------------------------+------------------------------------- Reporter: | Owner: tcsavage daniel.is.fischer | Type: bug | Status: new Priority: low | Milestone: 8.0.1 Component: Core Libraries | Version: 7.1 Resolution: | Keywords: Double, | Float, exponentiation Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by WrenThornton): * cc: wren@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 15 11:04:59 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Sep 2015 11:04:59 -0000 Subject: [GHC] #4823: Loop strength reduction for array indexing In-Reply-To: <044.82dfe985922046910a65f46ae45b716a@haskell.org> References: <044.82dfe985922046910a65f46ae45b716a@haskell.org> Message-ID: <059.7a7ed22fccf7864b0c7fe50b3199b3da@haskell.org> #4823: Loop strength reduction for array indexing -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: feature request | Status: new Priority: low | Milestone: 8.0.1 Component: Compiler | Version: 7.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #7116 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by WrenThornton): * cc: wren@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 15 12:07:42 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Sep 2015 12:07:42 -0000 Subject: [GHC] #10840: Periodic alarm signals can cause a retry loop to get stuck In-Reply-To: <049.c792fb7fbab25e12997f6231b1f3472d@haskell.org> References: <049.c792fb7fbab25e12997f6231b1f3472d@haskell.org> Message-ID: <064.3ed9638d0902eb8f79474237119ba5ba@haskell.org> #10840: Periodic alarm signals can cause a retry loop to get stuck -------------------------------------+------------------------------------- Reporter: Rufflewind | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hsyl20): * cc: hsyl20 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 15 12:28:18 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Sep 2015 12:28:18 -0000 Subject: [GHC] #10883: Error messages referring to arrow operators use wrong symbols when outputting Unicode Message-ID: <045.fe10b10d75462082b7f83c0a1ebc07db@haskell.org> #10883: Error messages referring to arrow operators use wrong symbols when outputting Unicode -------------------------------------+------------------------------------- Reporter: zardoz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.10.2 libraries/pretty | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: 10509 Differential Revisions: | -------------------------------------+------------------------------------- As per #10509, GHC documentation gave the wrong glyphs for Unicode alternatives to the -< and >- arrow operators (the codepoints were correct, but the glyphs were not). The incorrect glyphs have also made it into the error output. So, in GHC error messages, we see something like the following: ? In the command: arr (+ 2) ? x ? Where ? should actually be ?. The alternative to >- is also incorrectly printed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 15 12:30:07 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Sep 2015 12:30:07 -0000 Subject: [GHC] #10883: Error messages referring to arrow operators use wrong symbols when outputting Unicode In-Reply-To: <045.fe10b10d75462082b7f83c0a1ebc07db@haskell.org> References: <045.fe10b10d75462082b7f83c0a1ebc07db@haskell.org> Message-ID: <060.3cd5ce150f7b82061a5f82bb57028c16@haskell.org> #10883: Error messages referring to arrow operators use wrong symbols when outputting Unicode -------------------------------------+------------------------------------- Reporter: zardoz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/pretty | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: 10509 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by zardoz): * Attachment "0001-Pretty-fix-unicode-arrow-operators.patch" added. Trivial patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 15 12:36:23 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Sep 2015 12:36:23 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.d3a81e4630b49683fce6bb622dba1516@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192 -------------------------------------+------------------------------------- Comment (by simonmar): FYI, @niteria posted a good explanation of why the remaining problems with determinism are hard: https://mail.haskell.org/pipermail/ghc- devs/2015-September/009964.html (long, but all relevant). We'd welcome more input on this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 15 13:02:15 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Sep 2015 13:02:15 -0000 Subject: [GHC] #10653: PatternSynonyms should be imported/exported as part of the wildcard notation In-Reply-To: <049.0e5a3c33a167308dc99ecaed5730df14@haskell.org> References: <049.0e5a3c33a167308dc99ecaed5730df14@haskell.org> Message-ID: <064.8620469bfe1b5d53d70d915c7aec06e0@haskell.org> #10653: PatternSynonyms should be imported/exported as part of the wildcard notation -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: mpickering Type: feature request | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: pattern | synonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by mpickering): Simon, is [https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms#Specification this] a suitable specification for you? Richard, does this match with your understanding? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 15 13:21:47 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Sep 2015 13:21:47 -0000 Subject: [GHC] #10478: Shorter import syntax In-Reply-To: <046.5e60b02b9fe497cdf59ecd5b37a450a2@haskell.org> References: <046.5e60b02b9fe497cdf59ecd5b37a450a2@haskell.org> Message-ID: <061.a6b1ccefac8e4bc95427c191be6e5ff2@haskell.org> #10478: Shorter import syntax -------------------------------------+------------------------------------- Reporter: acowley | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1238 -------------------------------------+------------------------------------- Comment (by simonpj): @acowley, is there a ''specification'' somewhere that I can read? I'm sorry if I missed it. To be concrete, what new wording would be needed in the [https://www.haskell.org/onlinereport/haskell2010/haskellch5.html#x11-1000005.2 Export lists] and [https://www.haskell.org/onlinereport/haskell2010/haskellch5.html#x11-1010005.3 Import declarations] sections of the language definition? thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 15 13:35:18 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Sep 2015 13:35:18 -0000 Subject: [GHC] #10884: Indentation requirements for parsing seem inconsistent Message-ID: <044.45fa3fde99558af124e327b4256d2b45@haskell.org> #10884: Indentation requirements for parsing seem inconsistent -------------------------------------+------------------------------------- Reporter: Samvh | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Keywords: parsing, | Operating System: Unknown/Multiple indentation, do-notation | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- The "golden rule of indentation" does not seem to be strictly adhered to in all cases: there is an interaction between let/where clauses and do- notation that makes indentation requirements different in different situations: Example 1, parsed successfully: {{{#!hs f = let y = do Just 1 in y }}} Example 2, causes an error: {{{#!hs f = let y = Just 1 in y }}} Example 3, causes an error: {{{#!hs f = do Just 1 }}} This behavior seems inconsistent to me. See also [http://stackoverflow.com/questions/32531508/haskell-parse-error- from-incorrect-indent]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 15 13:35:25 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Sep 2015 13:35:25 -0000 Subject: [GHC] #10881: internal error: evacuate: strange closure type 5101248 In-Reply-To: <045.d8291d7d3474f8067bb2d61da8cd20dc@haskell.org> References: <045.d8291d7d3474f8067bb2d61da8cd20dc@haskell.org> Message-ID: <060.131bde2a1300a56ce9900c5f779622fc@haskell.org> #10881: internal error: evacuate: strange closure type 5101248 -------------------------------------+------------------------------------- Reporter: burbly | Owner: simonmar Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: strange | closure type 5101248 Operating System: Windows | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonmar): * status: new => infoneeded Comment: Thanks for the bug report. Two suggestions: 1. Try to reproduce the issue on another machine, to exclude the possibility of hardware failure (this does happen!) 2. Please provide instructions and source code so that we can reproduce the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 15 13:49:14 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Sep 2015 13:49:14 -0000 Subject: [GHC] #10885: Crashes on FFI calls to Visual Studio-built C library Message-ID: <042.dac837a6d4f8745b43541375de5246e4@haskell.org> #10885: Crashes on FFI calls to Visual Studio-built C library -------------------------------------+------------------------------------- Reporter: mwu | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Runtime crash (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- I want to call third-party C library using ffi on Windows. Everything works fine with 32-bit GHC distribution, however 64-bit program crashes as soon the ffi call is being made. Interestingly, the same program works when run with {{{runghc}}}. Just the compiled .exe crashes. Consider the following C++ library code: {{{#!c++ // adder.cpp extern "C" { __declspec(dllexport) int _cdecl add(int a, int b) { return a + b; } } }}} and the following Haskell code using the library: {{{#!hs import Foreign.C foreign import ccall unsafe "add" add :: CInt -> CInt -> IO CInt main = (add 5 2) >>= print }}} It does work on 32-bit architecture and in ghci (on all architectures). Why does it not work as 64-bit executable? Notes: * it works if the library is built with MinGW. However, this is not an acceptable workaround for me, since the library I want to call is external and closed-source * the problem seems to be related to the import library file handling ? if I replace the MSVC-generated one with the MinGW-generated .lib import library, it works (even with MSVC-generated .dll) = Repro = I attach archive {{{repro_src.7z}}} with source files (as presented here) and a {{{build.bat}}} script building binaries. It needs to have both GCC/GHC and MSVC compilers in the path. (so it should be called from MSVC's {{{x64 Native Tools Command Prompt}}}) It creates two folder ? in one it builds the library with MinGW, in the another one ? with MSVC. The Haskell program crashes only with MSVC build of library. However, the Haskell source file works fine with runghc/ghci. Run the {{{build.bat}}} and ender the bin-msvc directory. The {{{Caller.exe}}} program crashes. However, {{{runghc -ladder ..\src\Caller.hs}}} gives the expected result. If you don't have MSVC installed, I provide also a package with all the sources built ? {{{repro_bin.7z}}}. I have used Microsoft Visual Studio 2013 and MinGHC 7.10.1, both 64-bit targeting. Same happens with GHC 7.8.4. Please let me know, if you need any further information to investigate this report. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 15 13:50:19 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Sep 2015 13:50:19 -0000 Subject: [GHC] #10885: Crashes on FFI calls to Visual Studio-built C library In-Reply-To: <042.dac837a6d4f8745b43541375de5246e4@haskell.org> References: <042.dac837a6d4f8745b43541375de5246e4@haskell.org> Message-ID: <057.7c761eaf19d6c1d0c25f44979fa69ad7@haskell.org> #10885: Crashes on FFI calls to Visual Studio-built C library -------------------------------------+------------------------------------- Reporter: mwu | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by mwu): * Attachment "repro_src.7z" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 15 14:00:50 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Sep 2015 14:00:50 -0000 Subject: [GHC] #10885: Crashes on FFI calls to Visual Studio-built C library In-Reply-To: <042.dac837a6d4f8745b43541375de5246e4@haskell.org> References: <042.dac837a6d4f8745b43541375de5246e4@haskell.org> Message-ID: <057.8e8e3a357f570912fe402fa88967a45f@haskell.org> #10885: Crashes on FFI calls to Visual Studio-built C library -------------------------------------+------------------------------------- Reporter: mwu | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by mwu): * Attachment "repro_bin.7z" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 15 14:01:30 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Sep 2015 14:01:30 -0000 Subject: [GHC] #10885: Crashes on FFI calls to Visual Studio-built C library In-Reply-To: <042.dac837a6d4f8745b43541375de5246e4@haskell.org> References: <042.dac837a6d4f8745b43541375de5246e4@haskell.org> Message-ID: <057.062e3eb6b7b1e8f0ebd1dad62690c7bd@haskell.org> #10885: Crashes on FFI calls to Visual Studio-built C library -------------------------------------+------------------------------------- Reporter: mwu | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by mwu: Old description: > I want to call third-party C library using ffi on Windows. Everything > works fine with 32-bit GHC distribution, however 64-bit program crashes > as soon the ffi call is being made. Interestingly, the same program works > when run with {{{runghc}}}. Just the compiled .exe crashes. > > Consider the following C++ library code: > {{{#!c++ > // adder.cpp > > extern "C" > { > __declspec(dllexport) int _cdecl add(int a, int b) > { > return a + b; > } > } > }}} > > and the following Haskell code using the library: > {{{#!hs > import Foreign.C > > foreign import ccall unsafe "add" add :: CInt -> CInt -> IO CInt > > main = (add 5 2) >>= print > }}} > > It does work on 32-bit architecture and in ghci (on all architectures). > Why does it not work as 64-bit executable? > > Notes: > * it works if the library is built with MinGW. However, this is not an > acceptable workaround for me, since the library I want to call is > external and closed-source > * the problem seems to be related to the import library file handling ? > if I replace the MSVC-generated one with the MinGW-generated .lib import > library, it works (even with MSVC-generated .dll) > > = Repro = > I attach archive {{{repro_src.7z}}} with source files (as presented here) > and a {{{build.bat}}} script building binaries. It needs to have both > GCC/GHC and MSVC compilers in the path. (so it should be called from > MSVC's {{{x64 Native Tools Command Prompt}}}) > > It creates two folder ? in one it builds the library with MinGW, in the > another one ? with MSVC. The Haskell program crashes only with MSVC build > of library. However, the Haskell source file works fine with runghc/ghci. > Run the {{{build.bat}}} and ender the bin-msvc directory. The > {{{Caller.exe}}} program crashes. However, {{{runghc -ladder > ..\src\Caller.hs}}} gives the expected result. > > If you don't have MSVC installed, I provide also a package with all the > sources built ? {{{repro_bin.7z}}}. I have used Microsoft Visual Studio > 2013 and MinGHC 7.10.1, both 64-bit targeting. Same happens with GHC > 7.8.4. > > Please let me know, if you need any further information to investigate > this report. New description: I want to call third-party C library using ffi on Windows. Everything works fine with 32-bit GHC distribution, however 64-bit program crashes as soon the ffi call is being made. Interestingly, the same program works when run with {{{runghc}}}. Just the compiled .exe crashes. Consider the following C++ library code: {{{#!c++ // adder.cpp extern "C" { __declspec(dllexport) int _cdecl add(int a, int b) { return a + b; } } }}} and the following Haskell code using the library: {{{#!hs import Foreign.C foreign import ccall unsafe "add" add :: CInt -> CInt -> IO CInt main = (add 5 2) >>= print }}} It does work on 32-bit architecture and in ghci (on all architectures). Why does it not work as 64-bit executable? Notes: * it works if the library is built with MinGW. However, this is not an acceptable workaround for me, since the library I want to call is external and closed-source * the problem seems to be related to the import library file handling ? if I replace the MSVC-generated one with the MinGW-generated .lib import library, it works (even with MSVC-generated .dll) = Repro = I attach archive {{{repro_src.7z}}} with source files (as presented here) and a {{{build.bat}}} script building binaries. It needs to have both GCC/GHC and MSVC compilers in the path. (so it should be called from MSVC's {{{x64 Native Tools Command Prompt}}}) It creates two folder ? in one it builds the library with MinGW, in the another one ? with MSVC. The Haskell program crashes only with MSVC build of library. However, the Haskell source file works fine with runghc/ghci. Run the {{{build.bat}}} and ender the bin-msvc directory. The {{{Caller.exe}}} program crashes. However, {{{runghc -ladder ..\src\Caller.hs}}} gives the expected result. If you don't have MSVC installed, I provide also a package with all the C++ sources built ? {{{repro_bin.7z}}}. I have used Microsoft Visual Studio 2013 and MinGHC 7.10.1, both 64-bit targeting. Same happens with GHC 7.8.4. Please let me know, if you need any further information to investigate this report. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 15 14:01:44 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Sep 2015 14:01:44 -0000 Subject: [GHC] #10478: Shorter import syntax In-Reply-To: <046.5e60b02b9fe497cdf59ecd5b37a450a2@haskell.org> References: <046.5e60b02b9fe497cdf59ecd5b37a450a2@haskell.org> Message-ID: <061.1c46d199893ff82404297196a00ef953@haskell.org> #10478: Shorter import syntax -------------------------------------+------------------------------------- Reporter: acowley | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1238 -------------------------------------+------------------------------------- Comment (by acowley): Sure, {{{ import modid maybeImpspec maybeAs }}} Semantics are the same as existing imports unless both an `impspec` (i.e. a parenthesised list of identifiers optionally prefixed with the `hiding` keyword) and an `as` (e.g. `as M`) are present. In such a case, all identifiers exported by `modid` are accessible behind the prefix given by the `as`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 15 14:07:51 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Sep 2015 14:07:51 -0000 Subject: [GHC] #10886: Remove the magic from `Any` Message-ID: <047.f678cbb73069d1c6ee1f63fe7d449257@haskell.org> #10886: Remove the magic from `Any` -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- The `Any` type used to be very highly magical: a poly-kinded type in a mono-kinded world. Then it became only normally magical: a datatype with a return kind of `k` (instead of `*`). Then it became only a bit magical: a closed type family with no equations. Now that we have non-magical empty closed type families, I believe that we can remove the last bit of magic and just define {{{ type family Any :: k where { } }}} somewhere (`GHC.Types`?), wire it in (like, e.g., `Bool`), and be done with it. Objections? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 15 14:23:05 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Sep 2015 14:23:05 -0000 Subject: [GHC] #10885: Crashes on FFI calls to Visual Studio-built C library In-Reply-To: <042.dac837a6d4f8745b43541375de5246e4@haskell.org> References: <042.dac837a6d4f8745b43541375de5246e4@haskell.org> Message-ID: <057.e2f653605221e648a2c0fb4112f735ca@haskell.org> #10885: Crashes on FFI calls to Visual Studio-built C library -------------------------------------+------------------------------------- Reporter: mwu | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by tmcdonell): * cc: tmcdonell (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 15 14:25:38 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Sep 2015 14:25:38 -0000 Subject: [GHC] #10883: Error messages referring to arrow operators use wrong symbols when outputting Unicode In-Reply-To: <045.fe10b10d75462082b7f83c0a1ebc07db@haskell.org> References: <045.fe10b10d75462082b7f83c0a1ebc07db@haskell.org> Message-ID: <060.aed4da389114763dbe8f12b8dde1718b@haskell.org> #10883: Error messages referring to arrow operators use wrong symbols when outputting Unicode -------------------------------------+------------------------------------- Reporter: zardoz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/pretty | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: 10509 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"14c4090e384d9ac5bf434a8a77bbf552bf463023/ghc" 14c4090e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="14c4090e384d9ac5bf434a8a77bbf552bf463023" Pretty: fix unicode arrow operators. As per issue #10509, the documentation gave the wrong glyphs for Unicode alternatives to the -< and >- arrow operators (the codepoints were correct, but the glyphs were not). The incorrect glyphs have also made it into the error output. This replaces those characters with the correct versions. GHC Trac Issues: #10883 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 15 14:25:38 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Sep 2015 14:25:38 -0000 Subject: [GHC] #10509: UnicodeSyntax documentation lists wrong symbols In-Reply-To: <045.99753819878229404545a65d82eb520e@haskell.org> References: <045.99753819878229404545a65d82eb520e@haskell.org> Message-ID: <060.521c15b3256fa23aa15c191befdb9bbe@haskell.org> #10509: UnicodeSyntax documentation lists wrong symbols -------------------------------------+------------------------------------- Reporter: zardoz | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Documentation | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"14c4090e384d9ac5bf434a8a77bbf552bf463023/ghc" 14c4090e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="14c4090e384d9ac5bf434a8a77bbf552bf463023" Pretty: fix unicode arrow operators. As per issue #10509, the documentation gave the wrong glyphs for Unicode alternatives to the -< and >- arrow operators (the codepoints were correct, but the glyphs were not). The incorrect glyphs have also made it into the error output. This replaces those characters with the correct versions. GHC Trac Issues: #10883 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 15 14:26:49 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Sep 2015 14:26:49 -0000 Subject: [GHC] #10883: Error messages referring to arrow operators use wrong symbols when outputting Unicode In-Reply-To: <045.fe10b10d75462082b7f83c0a1ebc07db@haskell.org> References: <045.fe10b10d75462082b7f83c0a1ebc07db@haskell.org> Message-ID: <060.45b5bb1e5143c169b79e35a5e23876b2@haskell.org> #10883: Error messages referring to arrow operators use wrong symbols when outputting Unicode -------------------------------------+------------------------------------- Reporter: zardoz | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: libraries/pretty | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: | ghci/scripts/T8959, | ghci/scripts/T8959b Blocked By: | Blocking: Related Tickets: #10509 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * testcase: => ghci/scripts/T8959, ghci/scripts/T8959b * resolution: => fixed * related: 10509 => #10509 * milestone: => 8.0.1 Comment: Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 15 14:40:35 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Sep 2015 14:40:35 -0000 Subject: [GHC] #10885: Crashes on FFI calls to Visual Studio-built C library In-Reply-To: <042.dac837a6d4f8745b43541375de5246e4@haskell.org> References: <042.dac837a6d4f8745b43541375de5246e4@haskell.org> Message-ID: <057.8d6b71124cc854ef64aa816c87efc8c7@haskell.org> #10885: Crashes on FFI calls to Visual Studio-built C library -------------------------------------+------------------------------------- Reporter: mwu | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): I hardly know anything about Windows and its calling conventions (for example I have no idea how `OSMinGW32` is a possible platform when compiling 64-bit code) but a while ago I noticed at https://en.wikipedia.org/wiki/X86_calling_conventions#Microsoft_x64_calling_convention something about a shadow space which as far as I can see we don't take into account in `genCCall64'`. Could this be the cause? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 15 14:41:54 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Sep 2015 14:41:54 -0000 Subject: [GHC] #9636: Function with type error accepted In-Reply-To: <047.40d618ba556abcff453b3e145ac728eb@haskell.org> References: <047.40d618ba556abcff453b3e145ac728eb@haskell.org> Message-ID: <062.34f5d6427ba125d095dcfc0fd1d29626@haskell.org> #9636: Function with type error accepted -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * cc: sweirich@? (added) Comment: I'm sure Stephanie would be interested to see that last comment. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 15 14:50:09 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Sep 2015 14:50:09 -0000 Subject: [GHC] #10787: Incorrect code example for pattern synonyms In-Reply-To: <049.ebf5abc73106dd0931b303481127fab7@haskell.org> References: <049.ebf5abc73106dd0931b303481127fab7@haskell.org> Message-ID: <064.84b7bd81418c9420702f244ea046b4b7@haskell.org> #10787: Incorrect code example for pattern synonyms -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Documentation | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1191 -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => closed * resolution: => fixed * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 15 14:55:36 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Sep 2015 14:55:36 -0000 Subject: [GHC] #8552: Rename StgArrWords to StgArrBytes In-Reply-To: <047.162074162cf551ca6b1ad3c66a412848@haskell.org> References: <047.162074162cf551ca6b1ad3c66a412848@haskell.org> Message-ID: <062.8fdd33b50704e6dc8e384d5c37cd9603@haskell.org> #8552: Rename StgArrWords to StgArrBytes -------------------------------------+------------------------------------- Reporter: Tarrasch | Owner: | siddhanathan Type: task | Status: closed Priority: lowest | Milestone: 8.0.1 Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1233 -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 15 15:09:25 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Sep 2015 15:09:25 -0000 Subject: [GHC] #10885: Crashes on FFI calls to Visual Studio-built C library In-Reply-To: <042.dac837a6d4f8745b43541375de5246e4@haskell.org> References: <042.dac837a6d4f8745b43541375de5246e4@haskell.org> Message-ID: <057.b40a1da4aa9c9e494bbf443a47ca50bc@haskell.org> #10885: Crashes on FFI calls to Visual Studio-built C library -------------------------------------+------------------------------------- Reporter: mwu | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by mwu): @rwbarton From what I see {{{OSMinGW32}}} is just an OS name (meaning simply "Windows") and has no relation to the 32/64-bit targeting (i.e. targeted architecture). The shadow space you mention is interesting. I know little about GHC inner workings and calling conventions, so take my speculations with a grain of salt. Still, from what I understand, both MinGW and MSVC on x64 Windows use the same calling convention. If it was the problem, it should fail with both. Moreover, Haskell code is able to correctly call x64 MSVC-built dll. The problem seems to be related only to the MSVC-generated import library (the {{{.lib}}} file). You might want to compare MinGW's and MSVC's {{{adder.lib}}} files in the {{{repro_bin.7z}}} package I uploaded. With one, calling {{{addd}}} method works, with another one it crashes. I'd suspect that difference should be somewhere there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 15 15:10:25 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Sep 2015 15:10:25 -0000 Subject: [GHC] #10885: Crashes on FFI calls to Visual Studio-built C library In-Reply-To: <042.dac837a6d4f8745b43541375de5246e4@haskell.org> References: <042.dac837a6d4f8745b43541375de5246e4@haskell.org> Message-ID: <057.3f5bb2cd64a7d9a0342ba38f2fbb43ce@haskell.org> #10885: Crashes on FFI calls to Visual Studio-built C library -------------------------------------+------------------------------------- Reporter: mwu | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): Yuras pointed out that I missed this bit of code {{{ -- On Win64, we also have to leave stack space for the arguments -- that we are passing in registers lss_code <- if platformOS platform == OSMinGW32 then leaveStackSpace (length (allArgRegs platform)) else return nilOL }}} which seems to deal correctly with the shadow space. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 15 15:58:02 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Sep 2015 15:58:02 -0000 Subject: [GHC] #10885: Crashes on FFI calls to Visual Studio-built C library In-Reply-To: <042.dac837a6d4f8745b43541375de5246e4@haskell.org> References: <042.dac837a6d4f8745b43541375de5246e4@haskell.org> Message-ID: <057.847666574dcc75a47a814c5e0f5507f4@haskell.org> #10885: Crashes on FFI calls to Visual Studio-built C library -------------------------------------+------------------------------------- Reporter: mwu | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by awson): This is a bug in binutils. It can't link MS-created 64-bit import libraries properly. The bug was fixed in latest MSys2 binutils distribution: http://repo.msys2.org/mingw/x86_64/mingw-w64-x86_64-binutils-2.25.1-1-any.pkg.tar.xz. Note that the bugfix was not in vanilla 2.25.1. MSys2 maintainers backported it from trunk binutils. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 15 16:18:30 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Sep 2015 16:18:30 -0000 Subject: [GHC] #10653: PatternSynonyms should be imported/exported as part of the wildcard notation In-Reply-To: <049.0e5a3c33a167308dc99ecaed5730df14@haskell.org> References: <049.0e5a3c33a167308dc99ecaed5730df14@haskell.org> Message-ID: <064.c9d246b473e97b35a4592ba414b136ad@haskell.org> #10653: PatternSynonyms should be imported/exported as part of the wildcard notation -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: mpickering Type: feature request | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: pattern | synonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Yes, that's what I meant. I clarified the proposal a bit. Thanks for writing it up! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 15 16:28:45 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Sep 2015 16:28:45 -0000 Subject: [GHC] #8582: Record syntax for pattern synonyms In-Reply-To: <045.711f298e5aa28ce184df85985d614bd2@haskell.org> References: <045.711f298e5aa28ce184df85985d614bd2@haskell.org> Message-ID: <060.28ac9dd5eb7a550fd27d2f058b4a4a63@haskell.org> #8582: Record syntax for pattern synonyms -------------------------------------+------------------------------------- Reporter: cactus | Owner: mpickering Type: feature request | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 5144 | Blocking: Related Tickets: | Differential Revisions: Phab:D1152 -------------------------------------+------------------------------------- Comment (by goldfire): Some idle thought has spurred on some questions about the design of this feature. See [https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms#Trickybits a new section on the wiki page]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 15 16:36:08 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Sep 2015 16:36:08 -0000 Subject: [GHC] #7830: Error: operand out of range In-Reply-To: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> References: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> Message-ID: <059.9f7da85c8678c742f391685a384b3823@haskell.org> #7830: Error: operand out of range -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Installing GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by trommler): Replying to [comment:26 trommler]: > This looks like code spilling registers onto the stack. But why are the offsets so large? Could you attach the entire assembler file? This looks suspicious: {{{ .Lc138b: addi 1, 1, -28336 }}} I wonder why GHC allocates ~3500 spill slots (of size 8 bytes each) on top of the roughly 2000 that are allocated in the RTS before we enter Haskell land in `StgCRun`. > > I tried to reproduce on powerpc64 HEAD but compile failed to typecheck in package uualib. I'll try to reproduce with the commit you mentioned in comment:24. I cannot reproduce the issue on powerpc64 even though it has the same 16-bit displacement restriction. I did a `perf` build, perhaps that makes a difference?! Did you use a `build.mk` file? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 15 16:42:10 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Sep 2015 16:42:10 -0000 Subject: [GHC] #10829: Simplification in the RHS of rules In-Reply-To: <046.7ca7c028ab82ec2d7ad263cb88680067@haskell.org> References: <046.7ca7c028ab82ec2d7ad263cb88680067@haskell.org> Message-ID: <061.ba3f5b4ef7a37f24cfd8e309e4b0fd51@haskell.org> #10829: Simplification in the RHS of rules -------------------------------------+------------------------------------- Reporter: afarmer | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 10528 | Differential Revisions: D1246 -------------------------------------+------------------------------------- Changes (by afarmer): * differential: => D1246 Comment: Alright, I used the 7.10.2 branch and cherry picked bc4b64ca5b99bff6b3d5051b57cb2bc52bd4c841 (SPJ's "Do not inline or apply rules on LHS of rules") as my nofib base. My patch is in D1246. I used the following nofib command: {{{ make clean && make boot && make -k mode=slow 2>&1 NoFibRuns=30 }}} (as an aside, what does the `-k` do? It was recommended without comment on the nofib wiki page) Full nofib results are attached. To summarize, there was more of a change than I expected, but it seems positive, which was also unexpected. See below for Runtime/Elapsed/Total Mem. Binary Sizes and Allocations were unchanged. Average compile time dropped 3.1%, which was also surprising. Given the surprises, I'm going to re-run on another machine just to check. I didn't dig into any of the outliers to see what the Core looked like. Programs with more than 1% change: {{{ -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- ansi 0.0% 0.0% -1.3% -1.3% 0.0% binary-trees 0.0% 0.0% -3.1% -3.2% 0.0% cacheprof 0.0% -0.1% -2.6% -2.7% +2.2% fannkuch-redux 0.0% 0.0% -1.5% -1.5% 0.0% fasta 0.0% 0.0% -2.3% -2.4% 0.0% fibheaps 0.0% 0.0% -2.5% -2.5% 0.0% fulsom 0.0% 0.0% 0.181 -6.2% -0.2% hidden 0.0% 0.0% -2.2% -2.6% 0.0% ida 0.0% 0.0% +2.4% +2.4% 0.0% knights 0.0% 0.0% -6.4% -6.4% 0.0% maillist 0.0% +0.0% 0.050 +1.8% +1.0% multiplier 0.0% 0.0% -1.4% -1.5% 0.0% n-body 0.0% 0.0% -2.9% -3.0% 0.0% pidigits 0.0% 0.0% -3.5% -3.7% 0.0% power 0.0% 0.0% -2.0% -2.1% 0.0% primes 0.0% 0.0% -1.7% -1.6% 0.0% queens 0.0% 0.0% +1.9% +1.8% 0.0% reverse-complem 0.0% 0.0% -2.2% -2.9% 0.0% scs 0.0% 0.0% -5.1% -5.2% 0.0% wang 0.0% 0.0% +1.3% +1.4% 0.0% -------------------------------------------------------------------------------- Min 0.0% -0.1% -6.4% -6.4% -0.2% Max 0.0% +0.0% +2.4% +2.4% +2.2% Geometric Mean -0.0% -0.0% -0.8% -0.8% +0.0% }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 15 16:42:41 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Sep 2015 16:42:41 -0000 Subject: [GHC] #10829: Simplification in the RHS of rules In-Reply-To: <046.7ca7c028ab82ec2d7ad263cb88680067@haskell.org> References: <046.7ca7c028ab82ec2d7ad263cb88680067@haskell.org> Message-ID: <061.512660e3ee307787d492f95e2774c643@haskell.org> #10829: Simplification in the RHS of rules -------------------------------------+------------------------------------- Reporter: afarmer | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 10528 | Differential Revisions: D1246 -------------------------------------+------------------------------------- Changes (by afarmer): * Attachment "nofib-results.txt" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 15 16:44:40 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Sep 2015 16:44:40 -0000 Subject: [GHC] #7830: Error: operand out of range In-Reply-To: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> References: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> Message-ID: <059.a6e7538f4cf99c21b5fc10fd2a0aed6d@haskell.org> #7830: Error: operand out of range -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Installing GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by trommler): Replying to [comment:31 erikd]: > Replying to [comment:29 erikd]: > > At @rwbarton's suggestion added `NOINLINE` pragmas to `above_` and `beside_` functions in `compiler/utils/Pretty.hs` and now the assembler file for `compiler/cmm/PprC.hs` is 158390 lines. > > That worked when building the stage1 compiler using the bootstrap compiler, but it fails again when build the stage2 compiler with the stage1 compiler. The assembler file for `compiler/cmm/PprC.hs` compiled with the stage1 compiler is 220293 lines. It looks like we have to support 32-bit loads from/stores to the stack too. Fortunately, we are looking at constant offset from the C stack pointer (r1) and the offsets are known at compilation time, so performance of the object code produced by GHC is not going to suffer much if at all. I could prepare a patch next week and verify on powerpc64. @erikd could you help out building the patch on your machine? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 15 17:59:16 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Sep 2015 17:59:16 -0000 Subject: [GHC] #10884: Indentation requirements for parsing seem inconsistent In-Reply-To: <044.45fa3fde99558af124e327b4256d2b45@haskell.org> References: <044.45fa3fde99558af124e327b4256d2b45@haskell.org> Message-ID: <059.1abef7980abe93207d2e2c38adba846b@haskell.org> #10884: Indentation requirements for parsing seem inconsistent -------------------------------------+------------------------------------- Reporter: Samvh | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Keywords: parsing, Resolution: invalid | indentation, do-notation Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => invalid Comment: This is due to `NonDecreasingIndentation`, which is not per Haskell98 but useful in cases where you want to open a do-block without increasing indentation. This will parse fail: {{{ {-# LANGUAGE NoNondecreasingIndentation #-} f = let y = do Just 1 in y }}} Non-decreasing indentation doesn't work at the top level, because if you applied it there, there would be no indentation you could drop back in order to get out of a do-block. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 15 18:18:52 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Sep 2015 18:18:52 -0000 Subject: [GHC] #10829: Simplification in the RHS of rules In-Reply-To: <046.7ca7c028ab82ec2d7ad263cb88680067@haskell.org> References: <046.7ca7c028ab82ec2d7ad263cb88680067@haskell.org> Message-ID: <061.ced04d823eb05ac2bd8db88e38361c77@haskell.org> #10829: Simplification in the RHS of rules -------------------------------------+------------------------------------- Reporter: afarmer | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 10528 | Differential Revisions: D1246 -------------------------------------+------------------------------------- Changes (by afarmer): * priority: normal => high -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 15 18:35:45 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Sep 2015 18:35:45 -0000 Subject: [GHC] #10885: Crashes on FFI calls to Visual Studio-built C library In-Reply-To: <042.dac837a6d4f8745b43541375de5246e4@haskell.org> References: <042.dac837a6d4f8745b43541375de5246e4@haskell.org> Message-ID: <057.c43e910a79cd6ccd87dc9e76db092e06@haskell.org> #10885: Crashes on FFI calls to Visual Studio-built C library -------------------------------------+------------------------------------- Reporter: mwu | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by mwu): Thanks for the answer, good to know that the bug is already fixed in the MSYS2. Would it be possible to ship the corrected version of binutils in next GHC Windows releases? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 15 18:46:25 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Sep 2015 18:46:25 -0000 Subject: [GHC] #10885: Crashes on FFI calls to Visual Studio-built C library In-Reply-To: <042.dac837a6d4f8745b43541375de5246e4@haskell.org> References: <042.dac837a6d4f8745b43541375de5246e4@haskell.org> Message-ID: <057.1ab9636b500a636eb415aec9dcd36204@haskell.org> #10885: Crashes on FFI calls to Visual Studio-built C library -------------------------------------+------------------------------------- Reporter: mwu | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by awson): It's [https://ghc.haskell.org/trac/ghc/ticket/10726 done] already. At the moment you can safely replace them manually. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 15 20:01:00 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Sep 2015 20:01:00 -0000 Subject: [GHC] #10879: base is not included in the haddock index In-Reply-To: <048.8713266ddcd63f131d79fa94bba781e8@haskell.org> References: <048.8713266ddcd63f131d79fa94bba781e8@haskell.org> Message-ID: <063.ed27d346ad44ab75770107ce8d56a9d1@haskell.org> #10879: base is not included in the haddock index -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1247 -------------------------------------+------------------------------------- Changes (by thomie): * differential: => Phab:D1247 * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 15 20:07:58 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Sep 2015 20:07:58 -0000 Subject: [GHC] #9636: Function with type error accepted In-Reply-To: <047.40d618ba556abcff453b3e145ac728eb@haskell.org> References: <047.40d618ba556abcff453b3e145ac728eb@haskell.org> Message-ID: <062.e8e810df0b6e12ca684358c4ab213951@haskell.org> #9636: Function with type error accepted -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by jonsterling): Replying to [comment:26 DerekElkins]: > This is a fun one. We can look at what some other systems do in similar situations. > > comment:17 talks about handling unevaluated terms and the discussion has been talking about partial functions. One system that deals in this realm is Computational Type Theory (CTT), the type theory underlying NuPRL (and now JonPRL). In NuPRL you can literally write the equivalent of: > > {{{#!hs > T Int = Bool > T x = fix id > }}} thanks for the shoutout! I just thought I would clarify that, whilst in the past it was considered and perhaps experimented with, Nuprl does not currently have the ability to perform case analysis on types. (However, one of the principle reasons for types having an intensional equality in Nuprl rather than the standard extensional one is to not rule out the option of providing an eliminator to the universe in the future.) Anyway?with regard to partial operations, you are correct that it is not really a problem in Nuprl or JonPRL if a definition is partial; reduction is guided by the user in Nuprl. (By the way, contrary to oft-repeated mythology, it *is* safe to reduce terms in any context in CTT/ETT?this is guaranteed by the fact that computational equivalence is a congruence, a well-known result that comes from Howe.) It is *not* the case that for some function `f` and value `m`, `f(m)` is stuck (or worse, "canonical") if `f` is not defined at `m`; instead, it diverges. So viewing Haskell-style type families (whether open or closed) as functions or operations doesn't really work, though I believe that in many cases where a Haskell programmer reaches for a type family, they are really wanting a function/operation. I like your view of type families as generative in the same sense as data families, but quotiented by further axioms. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 15 20:20:53 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Sep 2015 20:20:53 -0000 Subject: [GHC] #9238: Negative zero broken In-Reply-To: <047.56415c116f5d14a35293c7c7b01ed1ce@haskell.org> References: <047.56415c116f5d14a35293c7c7b01ed1ce@haskell.org> Message-ID: <062.98e9b2b6bc67e4afd8bc0a35b76e5f89@haskell.org> #9238: Negative zero broken -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #7858, #9451, | Differential Revisions: Phab:D1061 #10215 | -------------------------------------+------------------------------------- Changes (by YitzGale): * cc: gale@? (added) * related: #7858, #9451 => #7858, #9451, #10215 * milestone: 8.0.1 => 7.10.3 Comment: As per Austin's request on ghc-dev, changing milestone to 7.10.3 due to: https://github.com/LeventErkok/sbv/issues/138 It appears from the submission that Lennart also needs this. And anyway this looks like a regression that really should be fixed. However, I do note that this issue doesn't have a patch yet. So if this is wrong, I apologize. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 15 22:23:17 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Sep 2015 22:23:17 -0000 Subject: [GHC] #10886: Remove the magic from `Any` In-Reply-To: <047.f678cbb73069d1c6ee1f63fe7d449257@haskell.org> References: <047.f678cbb73069d1c6ee1f63fe7d449257@haskell.org> Message-ID: <062.623ffc41d04f317facd6245b8367d45b@haskell.org> #10886: Remove the magic from `Any` -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): {{{ There is Richard, when needed the most He writes up a patch, and the magic is lost Tells me this built-ins will not stay Tells me poly kindness is now okay And I don?t need to build it in ?Any? stands in the line, it?s the next to go It was changing its kind, but that?s normal now You tell me its life used to be out of line T?was strange to be used every time Now I don?t need to build it in? Cause you had an insight You're taking one down You write a small patch just to turn it around You say you know how You tell me don't sigh You work at a smile and you go for ?Any? You had an insight The testsuite don't lie You're pushing a change and we really don't mind Cause you had an insight Cause you had an insight Well you need a closed type family The point is that it?s definintion is empty Now I don?t need to build it in? Cause you had an insight You're taking one down You write a small patch just to turn it around You say you know how You tell me don't sigh You work at a smile and you go for ?Any? You had an insight The testsuite don't lie You're pushing a change and we really don't mind Sometimes the system goes on the blink And the whole thing turns out wrong You might just take it back and you know That all could be well oh that strong But you?re not wrong (Yeah,yeah,yeah,yeah) So there is the Richard when we need him the most Oh you and types You write up a patch, and the magic is lost Cause you had an insight You're taking one down You write a small patch just to turn it around You say you know how You tell me don't sigh You work at a smile and you go for ?Any? You had an insight The testsuite don't lie You're pushing a change and we really don't mind Cause you had an insight Cause you had an insight Had an insight Had an insight Had an insight Had an insight }}} (With apologies to Daniel Powter.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 15 22:33:43 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Sep 2015 22:33:43 -0000 Subject: [GHC] #8582: Record syntax for pattern synonyms In-Reply-To: <045.711f298e5aa28ce184df85985d614bd2@haskell.org> References: <045.711f298e5aa28ce184df85985d614bd2@haskell.org> Message-ID: <060.86ffbc3b5419f9ac50824abe662dd800@haskell.org> #8582: Record syntax for pattern synonyms -------------------------------------+------------------------------------- Reporter: cactus | Owner: mpickering Type: feature request | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 5144 | Blocking: Related Tickets: | Differential Revisions: Phab:D1152 -------------------------------------+------------------------------------- Comment (by mpickering): The first example is a bit tricky although I don't think the results are unexpected. If instead you write {{{ data D = MkD { foo :: Int } pattern Pat = MkD { foo = 6 } baz = (Pat) { foo = 5 } }}} then everything works as expected. Otherwise there is a type error as `Pat` does not have a field `foo`. This is similar to one of the examples I posted on the original discussion thread. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 00:37:53 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 00:37:53 -0000 Subject: [GHC] #7305: T5975a is broken on Windows In-Reply-To: <047.9f0dc90b5cf8e0afa160ab6e09aa4504@haskell.org> References: <047.9f0dc90b5cf8e0afa160ab6e09aa4504@haskell.org> Message-ID: <062.85532fb17c178b9a9957f3903aa032f2@haskell.org> #7305: T5975a is broken on Windows -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Test Suite | Version: 7.6.1 Resolution: worksforme | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * keywords: newcomer => * status: new => closed * resolution: => worksforme Comment: Doesn't fail for me on Windows msys2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 01:17:50 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 01:17:50 -0000 Subject: [GHC] #5757: zero unexpected failures on all tier 1 platforms In-Reply-To: <047.3b6881d640a4e0fd41999b488e43799d@haskell.org> References: <047.3b6881d640a4e0fd41999b488e43799d@haskell.org> Message-ID: <062.c4987dd1c5837e417d240a48c8ee8fb8@haskell.org> #5757: zero unexpected failures on all tier 1 platforms -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: closed Priority: normal | Milestone: 8.0.1 Component: Test Suite | Version: 7.2.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9389 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate Comment: > zero unexpected failures on all tier 1 platforms at release time. Ideally there would be zero unexpected failures on tier 1 platforms at all times. Validate failures are an annoyance to contributors. I opened https://github.com/haskell-infra/phab-ghc-builder/issues/6 for this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 01:31:00 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 01:31:00 -0000 Subject: [GHC] #9636: Function with type error accepted In-Reply-To: <047.40d618ba556abcff453b3e145ac728eb@haskell.org> References: <047.40d618ba556abcff453b3e145ac728eb@haskell.org> Message-ID: <062.bf69ad1e09bd099326a7f049f71269dd@haskell.org> #9636: Function with type error accepted -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by DerekElkins): Replying to [comment:28 jonsterling]: > Replying to [comment:26 DerekElkins]: > > > comment:17 talks about handling unevaluated terms and the discussion has been talking about partial functions. One system that deals in this realm is Computational Type Theory (CTT), the type theory underlying NuPRL (and now JonPRL). In NuPRL you can literally write the equivalent of: > > > > {{{#!hs > > T Int = Bool > > T x = fix id > > }}} > > thanks for the shoutout! I just thought I would clarify that, whilst in the past it was considered and perhaps experimented with, Nuprl does not currently have the ability to perform case analysis on types. (However, one of the principle reasons for types having an intensional equality in Nuprl rather than the standard extensional one is to not rule out the option of providing an eliminator to the universe in the future.) Yeah, in my reply on Richard Eisenberg's blog post,https://typesandkinds.wordpress.com/2015/09/09/what-are-type- families/, I explicitly introduce codes. I don't ''think'' this really changes the picture. (If this does, I'd like to know. Specifically if viewing (closed) type families as functions on codes of types that get interpreted into functions on types misses something important due to being limited to codes.) > It is *not* the case that for some function `f` and value `m`, `f(m)` is stuck (or worse, "canonical") if `f` is not defined at `m`; instead, it diverges. So viewing Haskell-style type families (whether open or closed) as functions or operations doesn't really work, though I believe that in many cases where a Haskell programmer reaches for a type family, they are really wanting a function/operation. I like your view of type families as generative in the same sense as data families, but quotiented by further axioms. I agree, in CTT `f(m)` is definitely not canonical and nothing like the generative view I suggested. I mainly mentioned CTT as I think it provides an interesting perspective. Frankly, the behavior Lennart is complaining about is the behavior I expected a priori. My suggestion is essentially that codes for * are being quotiented. The mention of HITs was simply because I still really want codes to be "inductive". I go into this further on the above mentioned blog reply where I've also no doubt said at best imprecise things about CTT (though not they are not relevant to this approach.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 01:35:56 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 01:35:56 -0000 Subject: [GHC] #9389: Full Test Suite Failures In-Reply-To: <042.38f06884e0da53a793f9dd734d87a005@haskell.org> References: <042.38f06884e0da53a793f9dd734d87a005@haskell.org> Message-ID: <057.c99eda75b883d7d4a76e209fc234ebd9@haskell.org> #9389: Full Test Suite Failures -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: #9286,#8756,#7876,#7877 | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed Comment: jrp: maybe you could do another ./validate run, and send the result to the mailing list? GHC on Mac OSX is in need of a new maintainer. It would be nice if somebody could restart the OSX builder also: http://haskell.inf.elte.hu/builders/ I'm closing this ticket here, because the information is most likely outdated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 03:43:24 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 03:43:24 -0000 Subject: [GHC] #10829: Simplification in the RHS of rules In-Reply-To: <046.7ca7c028ab82ec2d7ad263cb88680067@haskell.org> References: <046.7ca7c028ab82ec2d7ad263cb88680067@haskell.org> Message-ID: <061.512660e3ee307787d492f95e2774c643@haskell.org> #10829: Simplification in the RHS of rules -------------------------------------+------------------------------------- Reporter: afarmer | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 10528 | Differential Revisions: D1246 -------------------------------------+------------------------------------- Changes (by afarmer): * Attachment "nofib-results.txt" removed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 03:43:24 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 03:43:24 -0000 Subject: [GHC] #10829: Simplification in the RHS of rules In-Reply-To: <046.7ca7c028ab82ec2d7ad263cb88680067@haskell.org> References: <046.7ca7c028ab82ec2d7ad263cb88680067@haskell.org> Message-ID: <061.1d9beae67922ec7423cefb9e9aa9748c@haskell.org> #10829: Simplification in the RHS of rules -------------------------------------+------------------------------------- Reporter: afarmer | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 10528 | Differential Revisions: D1246 -------------------------------------+------------------------------------- Changes (by afarmer): * Attachment "nofib-results.txt" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 03:45:13 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 03:45:13 -0000 Subject: [GHC] #10829: Simplification in the RHS of rules In-Reply-To: <046.7ca7c028ab82ec2d7ad263cb88680067@haskell.org> References: <046.7ca7c028ab82ec2d7ad263cb88680067@haskell.org> Message-ID: <061.75cfa110da34f10ce92d971392dbe193@haskell.org> #10829: Simplification in the RHS of rules -------------------------------------+------------------------------------- Reporter: afarmer | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 10528 | Differential Revisions: D1246 -------------------------------------+------------------------------------- Comment (by afarmer): I reran nofib on a non-laptop machine* and updated the comment above and the attached result output. Let me know what you think. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 07:26:35 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 07:26:35 -0000 Subject: [GHC] #10886: Remove the magic from `Any` In-Reply-To: <047.f678cbb73069d1c6ee1f63fe7d449257@haskell.org> References: <047.f678cbb73069d1c6ee1f63fe7d449257@haskell.org> Message-ID: <062.490463530e8cc4ce874b3ca2ba40af0b@haskell.org> #10886: Remove the magic from `Any` -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): I'm all for it -- go for it. Obviously add some relevant notes etc. You'll still need it in `knownKeyNames`, though, since GHC uses it during zonking and elsewhere. I love the song but I'm missing the soundtrack. You should put it up on Youtube with you singing it to a backing track :-) Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 07:28:58 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 07:28:58 -0000 Subject: [GHC] #10886: Remove the magic from `Any` In-Reply-To: <047.f678cbb73069d1c6ee1f63fe7d449257@haskell.org> References: <047.f678cbb73069d1c6ee1f63fe7d449257@haskell.org> Message-ID: <062.9bcfff99b613e8d6898db5f77c1ebd8f@haskell.org> #10886: Remove the magic from `Any` -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): > You should put it up on Youtube with you singing it to a backing track :-) Pity with humanity prohibits me from singing in public. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 07:39:58 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 07:39:58 -0000 Subject: [GHC] #10829: Simplification in the RHS of rules In-Reply-To: <046.7ca7c028ab82ec2d7ad263cb88680067@haskell.org> References: <046.7ca7c028ab82ec2d7ad263cb88680067@haskell.org> Message-ID: <061.5439e8d44a152872777c70addd9cbe6b@haskell.org> #10829: Simplification in the RHS of rules -------------------------------------+------------------------------------- Reporter: afarmer | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 10528 | Differential Revisions: D1246 -------------------------------------+------------------------------------- Comment (by simonpj): Looks fine to me. I'd be happy to add it to 7.10.3. But what about the RHS (see comment:4)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 07:57:21 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 07:57:21 -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.409e8179d3aa50a08a460377b02e8eab@haskell.org> #5495: simple program fails with -shared on mac -------------------------------------+------------------------------------- Reporter: mwotton | Owner: Type: bug | Status: new Priority: low | Milestone: 8.0.1 Component: Runtime System | Version: 7.2.1 (Linker) | Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * os: Unknown/Multiple => MacOS X * component: Compiler => Runtime System (Linker) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 08:06:59 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 08:06:59 -0000 Subject: [GHC] #10653: PatternSynonyms should be imported/exported as part of the wildcard notation In-Reply-To: <049.0e5a3c33a167308dc99ecaed5730df14@haskell.org> References: <049.0e5a3c33a167308dc99ecaed5730df14@haskell.org> Message-ID: <064.253e7a49705dc5237b6bf6d7c08c6b97@haskell.org> #10653: PatternSynonyms should be imported/exported as part of the wildcard notation -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: mpickering Type: feature request | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: pattern | synonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Excellent thank you! Now we have something to discuss. There is much that I do not understand in the spec. I've added some notes with questions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 08:09:26 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 08:09:26 -0000 Subject: [GHC] #10887: Please export GhcMake.downsweep and make it return a partial module graph in case of errors Message-ID: <046.21b04d6e7ef6c1ed689aa46c2024ef44@haskell.org> #10887: Please export GhcMake.downsweep and make it return a partial module graph in case of errors -------------------------------------+------------------------------------- Reporter: DanielG | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Hi, in ghc-mod we have to essentially run a downsweep before we have any idea what `-package` flags to pass to GHC. We do this in order to figure out which modules belong to each Cabal component. If we use `depanal` to do this it will unfortunately just throw import errors because we haven't actually told GHC which package should be in scope yet. I think depanal/downsweep also abort on some other types of errors, which would also have to be cought since ghc-mod needs to work even when there are modules with parse errors etc (because the user is still editing them). I'm not sure where ghc parses the module headers so I'm not sure if it's going to blow up horribly when a module header doesn't parse or if that's just going to make downsweep return failure too. For the time being we essentially just re-implemented downsweep's functionality .. poorly but I'd really rather use downsweep directly. Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 08:09:51 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 08:09:51 -0000 Subject: [GHC] Batch modify: #5522, #7190, #7437, #8144, #8319, #9646, #4081, ... Message-ID: <20150916080951.CD32D3A2FF@ghc.haskell.org> Batch modification to #5522, #7190, #7437, #8144, #8319, #9646, #4081, #8303, #8313 by thomie: component to Test Suite Action: provideinfo Comment: Bug is fixed. Just needs a test. -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 08:23:51 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 08:23:51 -0000 Subject: [GHC] Batch modify: #8809, #10073, #10179 Message-ID: <20150916082351.DB6D03A2FF@ghc.haskell.org> Batch modification to #8809, #10073, #10179 by thomie: related to #8809,#10073,#10179 -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 08:47:49 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 08:47:49 -0000 Subject: [GHC] #10852: ghc 7.8.4 on arm - panic: Simplifier ticks exhausted In-Reply-To: <051.6de3bb6380bb073196bb38e7623ede92@haskell.org> References: <051.6de3bb6380bb073196bb38e7623ede92@haskell.org> Message-ID: <066.a0181de002e8d5801da18be2f9fbe8a3@haskell.org> #10852: ghc 7.8.4 on arm - panic: Simplifier ticks exhausted -------------------------------------+------------------------------------- Reporter: andrewufrank | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: arm Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #5642, #9675 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * keywords: => arm -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 08:48:06 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 08:48:06 -0000 Subject: [GHC] #10852: ghc 7.8.4 on arm - panic: Simplifier ticks exhausted In-Reply-To: <051.6de3bb6380bb073196bb38e7623ede92@haskell.org> References: <051.6de3bb6380bb073196bb38e7623ede92@haskell.org> Message-ID: <066.3e09452ca371ffc43d9a44e9a19fb06f@haskell.org> #10852: ghc 7.8.4 on arm - panic: Simplifier ticks exhausted ---------------------------------------+--------------------------------- Reporter: andrewufrank | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: arm Operating System: Linux | Architecture: arm Type of failure: Compile-time crash | Test Case: Blocked By: | Blocking: Related Tickets: #5642, #9675 | Differential Revisions: ---------------------------------------+--------------------------------- Changes (by thomie): * architecture: Unknown/Multiple => arm -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 09:16:18 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 09:16:18 -0000 Subject: [GHC] #8689: confusing comment in compiler/main/SysTools.lhs In-Reply-To: <045.cb716bf4926e5132d3b596b76f597be0@haskell.org> References: <045.cb716bf4926e5132d3b596b76f597be0@haskell.org> Message-ID: <060.5b67e0db279b83426146db4dd517f573@haskell.org> #8689: confusing comment in compiler/main/SysTools.lhs -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"e66daecafd83216f076a55e3313799f0834dc599/ghc" e66daeca/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e66daecafd83216f076a55e3313799f0834dc599" DynFlags: remove unused sPgm_sysman (#8689) Something about a long deleted 'system manager' for the 'parallel system'. Also remove confusing comment in SysTools, that supposedly referred to sPgm_sysman. See commit 16d5d1c75c999677783c9c1bda519540fa9a6e58. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 09:17:03 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 09:17:03 -0000 Subject: [GHC] #8689: confusing comment in compiler/main/SysTools.lhs In-Reply-To: <045.cb716bf4926e5132d3b596b76f597be0@haskell.org> References: <045.cb716bf4926e5132d3b596b76f597be0@haskell.org> Message-ID: <060.7ec05dbb27fd0c1b87b4b34c5b9050e4@haskell.org> #8689: confusing comment in compiler/main/SysTools.lhs -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 09:28:31 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 09:28:31 -0000 Subject: [GHC] #10105: ghc panic Simplifier ticks exhausted when trying UnfoldingDone x_alB In-Reply-To: <050.e25d389a8920cf1d1cafbe416375e037@haskell.org> References: <050.e25d389a8920cf1d1cafbe416375e037@haskell.org> Message-ID: <065.c023a1b4449cd2d0d3a36a08f7c0adbb@haskell.org> #10105: ghc panic Simplifier ticks exhausted when trying UnfoldingDone x_alB -------------------------------------+------------------------------------- Reporter: dramforever | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10372 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #10372 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 09:28:52 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 09:28:52 -0000 Subject: [GHC] #8168: ghc "Simplifier ticks exhausted" "When trying UnfoldingDone" In-Reply-To: <045.ae6d7c8dc2cac763fcfd91e8b07b080d@haskell.org> References: <045.ae6d7c8dc2cac763fcfd91e8b07b080d@haskell.org> Message-ID: <060.bcd535e150870452016dacd1ac2cf277@haskell.org> #8168: ghc "Simplifier ticks exhausted" "When trying UnfoldingDone" -------------------------------------+------------------------------------- Reporter: sp55aa | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: duplicate | Keywords: | Simplifier, UnfoldingDone, simpl- | tick-factor Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10372 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #10372 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 09:50:42 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 09:50:42 -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.776b9a83811fd7d645901f83958d5651@haskell.org> #9925: ghc internal error while installing hakyll -------------------------------------+------------------------------------- Reporter: fvictorio | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: worksforme | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => worksforme Comment: Thanks for the report. Unfortunately GHC 7.6.3 is no longer supported. Please reopen if you run into this problem again, with whatever is the latest release of GHC at the time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 10:19:26 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 10:19:26 -0000 Subject: [GHC] #5959: Top level splice in Template Haskell has over-ambitious lexical scope? In-Reply-To: <049.b189c654ed32eab20a9c7cf55774e825@haskell.org> References: <049.b189c654ed32eab20a9c7cf55774e825@haskell.org> Message-ID: <064.9dbfc132edbec5406d9ec6170c37bf58@haskell.org> #5959: Top level splice in Template Haskell has over-ambitious lexical scope? -------------------------------------+------------------------------------- Reporter: mightybyte | Owner: Type: bug | Status: new Priority: low | Milestone: 8.0.1 Component: Template Haskell | Version: 7.5 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect | (amd64) warning at compile-time | Test Case: th/T5971 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * component: Compiler => Template Haskell Comment: To reproduce: download Lens.hs from comment:3, then run `ghc Main.hs`, with `Main.hs` containing: {{{ {-# LANGUAGE ExistentialQuantification, TemplateHaskell #-} import Lens data App = forall b . App { _auth :: b } makeLens ''App main = return () }}} The error message should be improved, see comment:7. With ghc-7.11.20150909 I get: {{{ The exact Name ?b_a65q? is not in scope Probable cause: you used a unique Template Haskell name (NameU), perhaps via newName, but did not bind it If that's it, then -ddump-splices might be useful }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 10:20:51 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 10:20:51 -0000 Subject: [GHC] #10885: Crashes on FFI calls to Visual Studio-built C library In-Reply-To: <042.dac837a6d4f8745b43541375de5246e4@haskell.org> References: <042.dac837a6d4f8745b43541375de5246e4@haskell.org> Message-ID: <057.d5892ca336f891f2acefcd267e2877c8@haskell.org> #10885: Crashes on FFI calls to Visual Studio-built C library -------------------------------------+------------------------------------- Reporter: mwu | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by mwu): That's great. I can confirm that replacing binutils binaries with the ones from the MSys2 distribution you linked does solve the issue. :-) Looking forward to see a build with updated MinGW distribution, the dated GCC 4.5/4.6 gave us some other headaches as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 10:21:40 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 10:21:40 -0000 Subject: [GHC] #6047: GHC retains unnecessary binding In-Reply-To: <047.98f370c065e854d8094b0d33184ffbfc@haskell.org> References: <047.98f370c065e854d8094b0d33184ffbfc@haskell.org> Message-ID: <062.1894408a77f875f4b554b2559b33ec9d@haskell.org> #6047: GHC retains unnecessary binding -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * failure: None/Unknown => Compile-time performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 10:34:07 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 10:34:07 -0000 Subject: [GHC] #10888: ghci crashes Message-ID: <048.cd08c1c66af702cf9c35bbada74b978c@haskell.org> #10888: ghci crashes ------------------------------------+------------------------------- Reporter: parsifal9 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Linux Architecture: arm | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ------------------------------------+------------------------------- Hi all, the compiler was installed from the file ghc_7.10.2-2_armhf.deb localhost: arch armv7l {{{#!hs localhost: ghci GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help Prelude> :l Course/List.hs [1 of 2] Compiling Course.Core ( Course/Core.hs, interpreted ) [2 of 2] Compiling Course.List ( Course/List.hs, interpreted ) Ok, modules loaded: Course.List, Course.Core. *Course.List> (1:. 2:. Nil) ++ (1:. 2:. Nil) [1,2,1,2Segmentation fault (core dumped) }}} The files Core.hs and List.hs are attached. I dont know how to cut the example down any smaller. Sorry. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 10:34:25 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 10:34:25 -0000 Subject: [GHC] #7057: Simplifier infinite loop regression In-Reply-To: <046.685ac3090b076c0d32d3cf6f99b2bd25@haskell.org> References: <046.685ac3090b076c0d32d3cf6f99b2bd25@haskell.org> Message-ID: <061.0454e0d21b18d3b503f85201217696ed@haskell.org> #7057: Simplifier infinite loop regression -------------------------------------+------------------------------------- Reporter: ronwalf | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: 7.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * milestone: 8.0.1 => ? Comment: Other instances of this bug: #8833, #3872, #5400, #5448, #5722, #7057, #7369, #9235. All marked with Milestone bottom. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 10:34:42 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 10:34:42 -0000 Subject: [GHC] #9235: Simplifier ticks exhausted on recursive class method In-Reply-To: <043.df7f9b9ba092e09a71bb6cbbadc19ff7@haskell.org> References: <043.df7f9b9ba092e09a71bb6cbbadc19ff7@haskell.org> Message-ID: <058.3245d0ff46180473f31b73a0a12a85ee@haskell.org> #9235: Simplifier ticks exhausted on recursive class method -------------------------------------+------------------------------------- Reporter: klao | Owner: Type: bug | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * milestone: => ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 10:34:53 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 10:34:53 -0000 Subject: [GHC] #10888: ghci crashes In-Reply-To: <048.cd08c1c66af702cf9c35bbada74b978c@haskell.org> References: <048.cd08c1c66af702cf9c35bbada74b978c@haskell.org> Message-ID: <063.2d8c004c9a36f497a50c87331084972f@haskell.org> #10888: ghci crashes -------------------------------+--------------------------------- Reporter: parsifal9 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+--------------------------------- Changes (by parsifal9): * Attachment "course2.tgz" added. two files to reproduce the error -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 11:03:33 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 11:03:33 -0000 Subject: [GHC] #8746: Crosscompiling In-Reply-To: <049.1228fc07cede4b1619c6ff70ac264add@haskell.org> References: <049.1228fc07cede4b1619c6ff70ac264add@haskell.org> Message-ID: <064.c9964d67ac78f4829846b18d194f7a8a@haskell.org> #8746: Crosscompiling -------------------------------------+------------------------------------- Reporter: Visionstar | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 7.8.1-rc1 Resolution: | Keywords: | Crosscompile cross compile failed | ncurses setupterm not found Operating System: Linux | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * component: Compiler => Build System -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 11:21:11 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 11:21:11 -0000 Subject: [GHC] #10044: Wrong line number reported with CPP and line beginning with # In-Reply-To: <047.a0bfc7b37bebfe567d7611d66867f0e2@haskell.org> References: <047.a0bfc7b37bebfe567d7611d66867f0e2@haskell.org> Message-ID: <062.f394ba5dbe8775427df7f215b6888d2a@haskell.org> #10044: Wrong line number reported with CPP and line beginning with # -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.1-rc2 Resolution: | Keywords: cpp, clang Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * keywords: cpp => cpp, clang * os: Unknown/Multiple => MacOS X -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 11:25:37 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 11:25:37 -0000 Subject: [GHC] #10305: Windows validate failures In-Reply-To: <046.6f027390a175b610e7a005fd1512d5c4@haskell.org> References: <046.6f027390a175b610e7a005fd1512d5c4@haskell.org> Message-ID: <061.c6ace506fb10473ecac2e1e0a49f535e@haskell.org> #10305: Windows validate failures -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8981 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed * milestone: => 8.0.1 Comment: See #8981 for the haddock warnings. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 11:32:17 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 11:32:17 -0000 Subject: [GHC] #10887: Please export GhcMake.downsweep and make it return a partial module graph in case of errors In-Reply-To: <046.21b04d6e7ef6c1ed689aa46c2024ef44@haskell.org> References: <046.21b04d6e7ef6c1ed689aa46c2024ef44@haskell.org> Message-ID: <061.8e88e74789ea3cae277bc293f7a722b6@haskell.org> #10887: Please export GhcMake.downsweep and make it return a partial module graph in case of errors -------------------------------------+------------------------------------- Reporter: DanielG | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): If you are just asking that module `GHC` in package `ghc` should export a particular existing function, then that seems easy and uncontroversial: please submit a patch. If you want a different function that might be harder; perhaps you can specify and implement it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 11:34:27 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 11:34:27 -0000 Subject: [GHC] #10640: Document prim-ops In-Reply-To: <046.4e817e7df8d2c783e102d23f1eac2c40@haskell.org> References: <046.4e817e7df8d2c783e102d23f1eac2c40@haskell.org> Message-ID: <061.68a920d48b78745be895b31c245e4d7e@haskell.org> #10640: Document prim-ops -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Documentation | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1082 -------------------------------------+------------------------------------- Changes (by thomie): * component: Compiler => Documentation -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 11:35:57 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 11:35:57 -0000 Subject: [GHC] #10653: PatternSynonyms should be imported/exported as part of the wildcard notation In-Reply-To: <049.0e5a3c33a167308dc99ecaed5730df14@haskell.org> References: <049.0e5a3c33a167308dc99ecaed5730df14@haskell.org> Message-ID: <064.4b5635ce6946dc8e27b2df26a20b37a0@haskell.org> #10653: PatternSynonyms should be imported/exported as part of the wildcard notation -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: mpickering Type: feature request | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: pattern | synonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by mpickering): I have added some comments and examples to the page. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 11:36:32 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 11:36:32 -0000 Subject: [GHC] Batch modify: #8618, #9074, #10531 Message-ID: <20150916113632.BF5683A2FF@ghc.haskell.org> Batch modification to #8618, #9074, #10531 by thomie: component to Compiler (Linking) -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 11:37:50 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 11:37:50 -0000 Subject: [GHC] Batch modify: #6132, #7650, #4176, #8556 Message-ID: <20150916113750.6EC813A2FF@ghc.haskell.org> Batch modification to #6132, #7650, #4176, #8556 by thomie: component to Compiler (Parser) -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 11:39:32 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 11:39:32 -0000 Subject: [GHC] #7428: GHC compile times are seriously non-linear in program size In-Reply-To: <045.85e9797ebea1d66b1db34330e9f6ecce@haskell.org> References: <045.85e9797ebea1d66b1db34330e9f6ecce@haskell.org> Message-ID: <060.50cd5c27cb3e1177dfce14b2d6a481d7@haskell.org> #7428: GHC compile times are seriously non-linear in program size -------------------------------------+------------------------------------- Reporter: nudded | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * failure: Compile-time crash => Compile-time performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 11:40:10 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 11:40:10 -0000 Subject: [GHC] Batch modify: #1544, #5945, #6092, #7114, #7596, #9157, #9655, ... Message-ID: <20150916114010.4626B3A2FF@ghc.haskell.org> Batch modification to #1544, #5945, #6092, #7114, #7596, #9157, #9655, #10371, #10421, #10434, #5262 by thomie: failure to Runtime performance bug -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 12:01:47 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 12:01:47 -0000 Subject: [GHC] #8582: Record syntax for pattern synonyms In-Reply-To: <045.711f298e5aa28ce184df85985d614bd2@haskell.org> References: <045.711f298e5aa28ce184df85985d614bd2@haskell.org> Message-ID: <060.5fdd03a765c801e8b1a051d3dd543112@haskell.org> #8582: Record syntax for pattern synonyms -------------------------------------+------------------------------------- Reporter: cactus | Owner: mpickering Type: feature request | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 5144 | Blocking: Related Tickets: | Differential Revisions: Phab:D1152 -------------------------------------+------------------------------------- Comment (by simonpj): I'm sorry but I'm honestly not sure what the specification of the new feature is. The [wiki:PatternSynonyms#Design design subsection] is helpful, but it uses only one example, and I can't tell what is supposed to happen in general. Let's try this. In general, a pattern synonym should behave exactly like its expansion. So given {{{ pattern P x = (x, True) }}} these two functions should behave the same: {{{ f1 (P False) = "yes" f2 (P True) = "no" f2 (False,True) = "yes" -- Replace (P pat) by its expansion f2 (True, True) = "no" }}} (Actually they are not quite the same; see [wiki:PatternSynonyms#DynamicSemantics dynamic semantics subsection]. But close enough for now.) But for your proposal, given {{{ pattern Foo{bar, baz} = (bar, baz) }}} how, exactly should pattern matches on `Foo` expand? I can't tell. Another way to get at this question would be to look at [https://www.haskell.org/onlinereport/haskell2010/haskellch3.html#x8-580003.17 Section 3.17 of the langauge definition]. What changes, precisely, are required to accommodate pattern synonyms? (It's a deficiency in the current user manual that it does not say.) To give the idea, here is my first stab at extending 3.17.2. Add an extra item to the list, saying * To match a pattern `P p1 .. pn` against a value, where `P` is a pattern synonym defined by `pattern P x1 .. xn = prhs`, * first match the pattern `prhs` against the value, thereby binding `x1`..`xn`. * and then match `p1` agianst `x1`, `p2` against `x2`, and so on in sequence. A similar modification to 3.17.3 would be needed. Now, how would you change those words if your proposal was adopted? Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 12:14:39 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 12:14:39 -0000 Subject: [GHC] #10494: Representational equalities over AppTys are not hard failures In-Reply-To: <047.6c55cf81fc9e307934dd2710cdafc698@haskell.org> References: <047.6c55cf81fc9e307934dd2710cdafc698@haskell.org> Message-ID: <062.bee881dbaad9258e3be70bf2877ef6f8@haskell.org> #10494: Representational equalities over AppTys are not hard failures -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T10494 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * owner: goldfire => * status: merge => new * resolution: fixed => * priority: normal => high Comment: So far as I can tell, this (and it's dup #10428) are * Fixed in HEAD * But not merged to 7.10.3 And @crockeea would like it in 7.10.3 if poss. I have no idea how hard or easy it will be to merge. I suggest giving it a go, but not losing sleep if it's not easy. Hence 'high'. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 12:43:29 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 12:43:29 -0000 Subject: [GHC] #10478: Shorter import syntax In-Reply-To: <046.5e60b02b9fe497cdf59ecd5b37a450a2@haskell.org> References: <046.5e60b02b9fe497cdf59ecd5b37a450a2@haskell.org> Message-ID: <061.a581244182ec52e8ba732d9d523541bb@haskell.org> #10478: Shorter import syntax -------------------------------------+------------------------------------- Reporter: acowley | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1238 -------------------------------------+------------------------------------- Comment (by simonpj): Thanks. I have started a wiki page for you, [wiki:ShorterImportSyntax]. Omitting package imports and source imports, the [https://www.haskell.org/onlinereport/haskell2010/haskellch5.html#x11-1010005.3 import declaration grammar] is {{{ impdecl ? import [qualified] modid [as modid] [impspec] }}} What I can't figure out from the above is whether you propose any ''change'' in grammar. Are you saying that switching the order of `as modid` and `impspec` makes the difference? If so could you perhaps just give the new grammar on the wiki page? > In such a case, all identifiers exported by modid are accessible behind the prefix given by the as How does that differ from this: {{{ import M as N }}} I'm not being picky; I'm just genuinely trying to understand what you propose but (like all future GHC users) without reading the long discussion that led up to it. Rather than replying to me inline here, it'd be great to update the wiki page to be as precise as you possibly can, add some examples, add links to the discussion and analysis you have done. That way the wiki becomes a standalone description of the proposed feature. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 13:32:28 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 13:32:28 -0000 Subject: [GHC] #8582: Record syntax for pattern synonyms In-Reply-To: <045.711f298e5aa28ce184df85985d614bd2@haskell.org> References: <045.711f298e5aa28ce184df85985d614bd2@haskell.org> Message-ID: <060.55d09106ba353ce2ec0d945084b27324@haskell.org> #8582: Record syntax for pattern synonyms -------------------------------------+------------------------------------- Reporter: cactus | Owner: mpickering Type: feature request | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 5144 | Blocking: Related Tickets: | Differential Revisions: Phab:D1152 -------------------------------------+------------------------------------- Comment (by mpickering): I think the confusion here is that pattern synonyms is an undescriptive name for the feature. I prefer to think of (bidirectional) pattern synonyms as data constructors which are not (yet) associated with a particular type. It is better then to say that instead of "In general, a pattern synonym should behave exactly like its expansion." that "In general, a pattern synonym should behave exactly like the relevant data constructor". For example, a bidirectional prefix pattern synonym should behave like a prefix data constructor, an infix pattern synonym should behave like an infix data constructor and a record pattern synonym should behave like a record data constructor. When we introduce records the expansion idea falls apart a bit. For normal prefix pattern synonyms there is one way to pattern match and one way to construct (which matches the expansion). With records there are a few ways to pattern match, a few ways to construct and also the possibility to update. This means the syntax has to diverge from the expansion idea as which expansion do we choose? If we define a synonym `P` and datatype `Q` as follows, {{{#!hs pattern MkP :: Int -> Int -> Q pattern MkP{x, y} = MkQ x1 y1 data Q = MkQ { x1 :: Int, y1 :: Int } }}} then we expect `MkP` to behave precisely as `MkQ` modulo field naming. To be clear these situations are as follows. * Construction (`MkP 0 0`) * Construction with record syntax (`MkP { x = 0, y = 1 }`) * Matching (`foo (MkP c l) = ...`) * Matching with normal record syntax (`foo (MkP {x = l, y = c}) = ...`) * Matching with field puns (`foo (MkP {x, y}) = ...`) * Updating with record syntax (`(MkP 0 0) { x = 1 }`) * Using record selectors (`x (MkP 0 0)`) For a unidirectional synonym, we define selectors and the matching part but not updates or construction. Is that clearer? I think the best specification for this feature is in terms of ordinary records as the goal is to get as close as possible to normal record data constructors. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 14:10:10 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 14:10:10 -0000 Subject: [GHC] #4438: Rename and register the "PArr" language extension when it is judged to be ready In-Reply-To: <045.48275531def43b588399da909236ad81@haskell.org> References: <045.48275531def43b588399da909236ad81@haskell.org> Message-ID: <060.461089f21b974619921e693f8e65d0d2@haskell.org> #4438: Rename and register the "PArr" language extension when it is judged to be ready -------------------------------------+------------------------------------- Reporter: duncan | Owner: benl Type: task | Status: closed Priority: normal | Milestone: ? Component: Data Parallel | Version: Haskell | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed * blockedby: 7330 => Comment: {{{ $ git grep ParallelArrays Cabal/Language/Haskell/Extension.hs: | ParallelArrays }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 14:19:25 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 14:19:25 -0000 Subject: [GHC] #9710: Clean up Trac versions In-Reply-To: <047.e9e7ccfe79be5260af9a1e1e7a3f431d@haskell.org> References: <047.e9e7ccfe79be5260af9a1e1e7a3f431d@haskell.org> Message-ID: <062.edae8aa34ce9e3ca68e9571fcdf32cf4@haskell.org> #9710: Clean up Trac versions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: hvr Type: task | Status: closed Priority: normal | Milestone: Component: Trac & Git | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed Comment: Versions are sorted currently. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 14:36:21 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 14:36:21 -0000 Subject: [GHC] #10829: Simplification in the RHS of rules In-Reply-To: <046.7ca7c028ab82ec2d7ad263cb88680067@haskell.org> References: <046.7ca7c028ab82ec2d7ad263cb88680067@haskell.org> Message-ID: <061.e8b7c51c9355561ff65b0647dd77758c@haskell.org> #10829: Simplification in the RHS of rules -------------------------------------+------------------------------------- Reporter: afarmer | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 10528 | Differential Revisions: D1246 -------------------------------------+------------------------------------- Comment (by afarmer): Ah, sorry I wasn't clear above. These results are for the changes you suggested in comment:4 (which are in D1426). The comparison is between 7.10.2+the LHS patch and 7.10.2+the LHS patch+D1426. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 14:38:24 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 14:38:24 -0000 Subject: [GHC] #10829: Simplification in the RHS of rules In-Reply-To: <046.7ca7c028ab82ec2d7ad263cb88680067@haskell.org> References: <046.7ca7c028ab82ec2d7ad263cb88680067@haskell.org> Message-ID: <061.cbfc726bf875bb3c966cbf55eaf6b21a@haskell.org> #10829: Simplification in the RHS of rules -------------------------------------+------------------------------------- Reporter: afarmer | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 10528 | Differential Revisions: D1246 -------------------------------------+------------------------------------- Comment (by afarmer): (Edit: I originally wrote D1426, I meant D1246.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 14:47:43 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 14:47:43 -0000 Subject: [GHC] #10829: Simplification in the RHS of rules In-Reply-To: <046.7ca7c028ab82ec2d7ad263cb88680067@haskell.org> References: <046.7ca7c028ab82ec2d7ad263cb88680067@haskell.org> Message-ID: <061.c1654167dee35cb7739edf5964c56fc7@haskell.org> #10829: Simplification in the RHS of rules -------------------------------------+------------------------------------- Reporter: afarmer | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 10528 | Differential Revisions: D1246 -------------------------------------+------------------------------------- Changes (by afarmer): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 14:50:00 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 14:50:00 -0000 Subject: [GHC] #10829: Simplification in the RHS of rules In-Reply-To: <046.7ca7c028ab82ec2d7ad263cb88680067@haskell.org> References: <046.7ca7c028ab82ec2d7ad263cb88680067@haskell.org> Message-ID: <061.2ce636cd6303dbbc082a88b3b40d5819@haskell.org> #10829: Simplification in the RHS of rules -------------------------------------+------------------------------------- Reporter: afarmer | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10528 | Differential Revisions: Phab:D1246 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * differential: D1246 => Phab:D1246 * related: 10528 => #10528 Comment: Changed the Diff and ticket information so that they'll auto-hyperlink. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 15:15:18 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 15:15:18 -0000 Subject: [GHC] #10494: Representational equalities over AppTys are not hard failures In-Reply-To: <047.6c55cf81fc9e307934dd2710cdafc698@haskell.org> References: <047.6c55cf81fc9e307934dd2710cdafc698@haskell.org> Message-ID: <062.0c8cd1808997d18b0357fc7150446ef8@haskell.org> #10494: Representational equalities over AppTys are not hard failures -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: merge Priority: high | Milestone: 7.10.3 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T10494 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => merge Comment: Shouldn't this be "merge" then? Changed accordingly. Do let me know if I can be of help sorting this out for the merge. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 15:21:29 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 15:21:29 -0000 Subject: [GHC] #8582: Record syntax for pattern synonyms In-Reply-To: <045.711f298e5aa28ce184df85985d614bd2@haskell.org> References: <045.711f298e5aa28ce184df85985d614bd2@haskell.org> Message-ID: <060.00100a9dfb292ecbd296aca4e124e092@haskell.org> #8582: Record syntax for pattern synonyms -------------------------------------+------------------------------------- Reporter: cactus | Owner: mpickering Type: feature request | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 5144 | Blocking: Related Tickets: | Differential Revisions: Phab:D1152 -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:12 mpickering]: > {{{#!hs > > pattern MkP :: Int -> Int -> Q > pattern MkP{x, y} = MkQ x1 y1 > > data Q = MkQ { x1 :: Int, y1 :: Int } > }}} I imagine you meant {{{#!hs pattern MkP{x, y} = MkQ x y }}} Otherwise, I agree with what you've said above. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 15:43:34 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 15:43:34 -0000 Subject: [GHC] #10889: Compiled software can not read UTF-8 characters using readFile when run via Upstart Message-ID: <044.c1f9696cf8cc34bce3042bcd13173a92@haskell.org> #10889: Compiled software can not read UTF-8 characters using readFile when run via Upstart -------------------------------------+------------------------------------- Reporter: SiXoS | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Linux Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Honestly I dont know if this is a problem with Upstart or ghc. I'm Using Ubuntu 14 Create a software that reads from a file containing UTF-8 characters. Compile the program. Running the program from the terminal works but not if you run it via Upstart. It will crash with the following error: "hGetContents: invalid argument (invalid byte sequence)" Minimal Example: Main.hs: {{{#!hs module Main where main :: IO () main = readFile "ex.txt" >>= putStr }}} ex.txt: {{{ ? }}} Place ex.txt and the compiled program "Comp" in the same directory "/the/path/" /etc/init/bug-test.conf: {{{ start on runlevel [2345] stop on runlevel [^2345] chdir /the/path/ exec ./Comp }}} If you run ./Comp from the terminal it works. But if you run "sudo service bug-test start" and then check "/var/log/upstart/bug-test.log" you will see that it has crashed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 15:52:45 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 15:52:45 -0000 Subject: [GHC] #8990: Performance tests behave differently depending on presence of .hi file (even with -fforce-recomp) In-Reply-To: <045.abd2027873a2b9d9a2bc9aa2b4b749ea@haskell.org> References: <045.abd2027873a2b9d9a2bc9aa2b4b749ea@haskell.org> Message-ID: <060.3d511d16d3af8634603c67780de96751@haskell.org> #8990: Performance tests behave differently depending on presence of .hi file (even with -fforce-recomp) -------------------------------------+------------------------------------- Reporter: ezyang | Owner: przembot Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.9 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by przembot): * owner: => przembot -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 16:17:26 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 16:17:26 -0000 Subject: [GHC] #10889: Compiled software can not read UTF-8 characters using readFile when run via Upstart In-Reply-To: <044.c1f9696cf8cc34bce3042bcd13173a92@haskell.org> References: <044.c1f9696cf8cc34bce3042bcd13173a92@haskell.org> Message-ID: <059.caff83388facb45e6117cf03f337c257@haskell.org> #10889: Compiled software can not read UTF-8 characters using readFile when run via Upstart -------------------------------------+------------------------------------- Reporter: SiXoS | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: invalid | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => closed * resolution: => invalid Comment: This is expected. I assume that under upstart, programs are run without a locale being set, so your Haskell program does not know what encoding to use when reading that file, defaults to (I believe) `ascii` and fails to decode your file. There are basically two solution: * Change the upstart script to set a locale (e.g. `LANG=C.utf-8`). * Change the program to explicitly set the encoding you want it to use (see `hSetEncoding` in `System.IO`) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 16:52:19 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 16:52:19 -0000 Subject: [GHC] #10478: Shorter import syntax In-Reply-To: <046.5e60b02b9fe497cdf59ecd5b37a450a2@haskell.org> References: <046.5e60b02b9fe497cdf59ecd5b37a450a2@haskell.org> Message-ID: <061.51cfce663a6914d620fa3a19a908bcf9@haskell.org> #10478: Shorter import syntax -------------------------------------+------------------------------------- Reporter: acowley | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1238 -------------------------------------+------------------------------------- Comment (by acowley): I'm probably missing something here: we both pasted the exact same line from the spec, and I offered the changed version, {{{ impdecl -> import modid impspec as modid }}} This is different from the spec in that `qualified` does not appear, and the `impspec` has moved. Further, neither the `impspec` nor the `as modid` are optional if you want to trigger the new behavior. They both must appear to invoke `ShortImports` behavior. The proposed syntax is syntactically invalid in Haskell2010. I've included on the wiki several ways of writing the grammar in an attempt to find one that can communicate. The patch itself already works and is smaller than any of these posts, so perhaps the code would be clearer if one is used to happy syntax. I've updated the wiki page to come at these issues from every angle I could think of. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 17:19:10 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 17:19:10 -0000 Subject: [GHC] #10872: More informative assertion for non-unique TH names In-Reply-To: <048.31528093886b2ab66084097b2ba3a854@haskell.org> References: <048.31528093886b2ab66084097b2ba3a854@haskell.org> Message-ID: <063.cbf976e16357cdb65fd737602afbeebd@haskell.org> #10872: More informative assertion for non-unique TH names -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by jstolarek): * owner: => jstolarek -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 19:31:32 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 19:31:32 -0000 Subject: [GHC] #10885: Crashes on FFI calls to Visual Studio-built C library In-Reply-To: <042.dac837a6d4f8745b43541375de5246e4@haskell.org> References: <042.dac837a6d4f8745b43541375de5246e4@haskell.org> Message-ID: <057.4d6c3144f0405c2d50f356376419c7ed@haskell.org> #10885: Crashes on FFI calls to Visual Studio-built C library -------------------------------------+------------------------------------- Reporter: mwu | Owner: Type: bug | Status: closed Priority: high | Milestone: Component: Compiler | Version: 7.10.1 Resolution: duplicate | Keywords: Operating System: Windows | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #10726 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #10726 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 19:49:13 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 19:49:13 -0000 Subject: [GHC] #10882: Fix target triple for Arm In-Reply-To: <044.1d80e9fba68d0b423d46d5881d8a4187@haskell.org> References: <044.1d80e9fba68d0b423d46d5881d8a4187@haskell.org> Message-ID: <059.fff722f894c24ab092538960c5642330@haskell.org> #10882: Fix target triple for Arm ---------------------------------+--------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7608 | Differential Revisions: ---------------------------------+--------------------------------- Changes (by thomie): * related: => #7608 Comment: #7608 is related. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 20:01:37 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 20:01:37 -0000 Subject: [GHC] #10877: x86_64: dll-split: out of memory (requested 1099512676352 bytes) In-Reply-To: <050.ab3ee9d3ff60499476bc10d829ff13d9@haskell.org> References: <050.ab3ee9d3ff60499476bc10d829ff13d9@haskell.org> Message-ID: <065.f955687071adccd9d9ca45568a4e109c@haskell.org> #10877: x86_64: dll-split: out of memory (requested 1099512676352 bytes) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: #10682 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): That's odd. Works fine for me, and Phabricator is also x86_64. * Did you try 'make maintainer-clean && ./boot && ./configure && make'? * Maybe it is something specific to dll-split. You could try to apply the patch from Phab:D677. I don't think the patch will apply cleanly, but it's a small patch, so just try to fix the merge conflict. Only applying the change in DynFlags might also be enough. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 20:05:46 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 20:05:46 -0000 Subject: [GHC] #10869: Option to dump preprocessed source In-Reply-To: <046.34bba2c2c1e4ccec0498d1f1e04c25f9@haskell.org> References: <046.34bba2c2c1e4ccec0498d1f1e04c25f9@haskell.org> Message-ID: <061.820f1ae15a3806a467e4afd74f16feea@haskell.org> #10869: Option to dump preprocessed source -------------------------------------+------------------------------------- Reporter: phischu | Owner: Type: feature request | Status: closed Priority: low | Milestone: Component: Driver | Version: 7.10.2 Resolution: invalid | Keywords: easy Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): Or maybe you want `--make` and `-E` to work together? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 20:57:33 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 20:57:33 -0000 Subject: [GHC] #10877: x86_64: dll-split: out of memory (requested 1099512676352 bytes) In-Reply-To: <050.ab3ee9d3ff60499476bc10d829ff13d9@haskell.org> References: <050.ab3ee9d3ff60499476bc10d829ff13d9@haskell.org> Message-ID: <065.2413a9734aa844765c3c2fa009367dca@haskell.org> #10877: x86_64: dll-split: out of memory (requested 1099512676352 bytes) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: #10682 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by RyanGlScott): I agree that this is odd, since the build does work for me on other x86_64 machines. I'm not sure what's different about this one. `make maintainer-clean && ./boot && ./configure && make` doesn't work. I tried manually applying the changes from Phab:D677 and running that, but unfortunately, a similar issue creeps up: {{{ [rgscott at tank ghc]$ make ===--- building phase 0 make --no-print-directory -f ghc.mk phase=0 phase_0_builds make[1]: Nothing to be done for `phase_0_builds'. ===--- building phase 1 make --no-print-directory -f ghc.mk phase=1 phase_1_builds make[1]: Nothing to be done for `phase_1_builds'. ===--- building final phase make --no-print-directory -f ghc.mk phase=final all "inplace/bin/ghc-stage2" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -O0 -H64m -hide-all-packages -i -iutils/ghctags/. -iutils/ghctags/dist-install/build -iutils/ghctags/dist- install/build/autogen -Iutils/ghctags/dist-install/build -Iutils/ghctags /dist-install/build/autogen -optP-include -optPutils/ghctags/dist- install/build/autogen/cabal_macros.h -package-id Cabal-1.23.0.0-inplace -package-id base-4.8.2.0-inplace -package-id containers-0.5.6.2-inplace -package-id ghc-7.11.20150916-inplace -XHaskell2010 -no-user-package-db -rtsopts -odir utils/ghctags/dist-install/build -hidir utils/ghctags /dist-install/build -stubdir utils/ghctags/dist-install/build -c utils/ghctags/./Main.hs -o utils/ghctags/dist-install/build/Main.dyn_o ghc-stage2: out of memory (requested 1099512676352 bytes) make[1]: *** [utils/ghctags/dist-install/build/Main.dyn_o] Error 1 make: *** [all] Error 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 21:05:53 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 21:05:53 -0000 Subject: [GHC] #10877: x86_64: dll-split: out of memory (requested 1099512676352 bytes) In-Reply-To: <050.ab3ee9d3ff60499476bc10d829ff13d9@haskell.org> References: <050.ab3ee9d3ff60499476bc10d829ff13d9@haskell.org> Message-ID: <065.d64fc254e8f42547d9cc14a4c412c592@haskell.org> #10877: x86_64: dll-split: out of memory (requested 1099512676352 bytes) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: #10682 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): Well it made it to ghc-stage2 at least. Could you try running the testsuite (run 'make test'). Do all tests fail, or just a few? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 21:22:55 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 21:22:55 -0000 Subject: [GHC] #10877: x86_64: dll-split: out of memory (requested 1099512676352 bytes) In-Reply-To: <050.ab3ee9d3ff60499476bc10d829ff13d9@haskell.org> References: <050.ab3ee9d3ff60499476bc10d829ff13d9@haskell.org> Message-ID: <065.0646bc9b7e83c1b9151220403dbcd533@haskell.org> #10877: x86_64: dll-split: out of memory (requested 1099512676352 bytes) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: #10682 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by RyanGlScott): All tests fail?I get the same out of memory error from `ghc-stage2`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 21:56:32 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 21:56:32 -0000 Subject: [GHC] #10877: x86_64: dll-split: out of memory (requested 1099512676352 bytes) In-Reply-To: <050.ab3ee9d3ff60499476bc10d829ff13d9@haskell.org> References: <050.ab3ee9d3ff60499476bc10d829ff13d9@haskell.org> Message-ID: <065.dd8ce480994c78ac951c7f45cf0fec50@haskell.org> #10877: x86_64: dll-split: out of memory (requested 1099512676352 bytes) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: #10682 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * priority: normal => highest * cc: gcampax (added) * milestone: => 8.0.1 Comment: Well I have no idea, but that's a release blocker. Maybe @gcampax can debug this, as the co-author of 0d1a8d09f452977aadef7897aa12a8d41c7a4af0. You can use `./configure --disable-large-address-space` in the meantime. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 22:00:25 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 22:00:25 -0000 Subject: [GHC] #7830: Error: operand out of range In-Reply-To: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> References: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> Message-ID: <059.24e0abd3ae38cbce9c549e07fa2b3e19@haskell.org> #7830: Error: operand out of range -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Installing GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by erikd): Replying to [comment:34 trommler]: > I could prepare a patch next week and verify on powerpc64. @erikd could you help out building the patch on your machine? Certainly! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 22:02:50 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 22:02:50 -0000 Subject: [GHC] #10877: x86_64: dll-split: out of memory (requested 1099512676352 bytes) In-Reply-To: <050.ab3ee9d3ff60499476bc10d829ff13d9@haskell.org> References: <050.ab3ee9d3ff60499476bc10d829ff13d9@haskell.org> Message-ID: <065.57860f75b1583e6a0af3f4d3ca7282e1@haskell.org> #10877: x86_64: dll-split: out of memory (requested 1099512676352 bytes) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: #10682 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): Presumably it is something special about the reporter's system. Something like overcommit being disabled (though in my preliminary tests this did not cause reserving large memory areas to fail). What distro is it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 22:06:39 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 22:06:39 -0000 Subject: [GHC] #10862: No way to exclude current directory from search path In-Reply-To: <046.896446a44757716ea085cdf95c0a86ea@haskell.org> References: <046.896446a44757716ea085cdf95c0a86ea@haskell.org> Message-ID: <061.f731cf3cbdbfa55dd74eaf26742f1e52@haskell.org> #10862: No way to exclude current directory from search path -------------------------------------+------------------------------------- Reporter: literon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * component: Compiler => Driver Comment: `-i` does reset the searchpath. {{{ $ ghci -i GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help Prelude> :show paths current working directory: /tmp/test module import search paths: none }}} But the searchpath isn't consulted for filenames you give as arguments on the command line. So if you have the following setup: A.hs: {{{ module A where import B }}} B.hs: {{{ module B where }}} * `ghc A.hs` will work, because the default searchpath is ".", so B.hs can be found. * `ghc -i A.hs B.hs` will work, because B.hs is given on the command line. * `ghc -i A.hs` will fail with `Could not find module ?B?`. That seems to work as expected. But you are giving a module name on the command line. Is that relevant? Do you think something different should happen when you say `ghc -i Main` vs `ghc -i Main.hs`? I'm trying to figure out what the bug is. Please help. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 22:25:48 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 22:25:48 -0000 Subject: [GHC] #10843: Allow do blocks without dollar signs as arguments In-Reply-To: <049.979a39a09d7a881598f53a6a6ce9bbe3@haskell.org> References: <049.979a39a09d7a881598f53a6a6ce9bbe3@haskell.org> Message-ID: <064.a4e98532c9ff05fff64a690b3a271c82@haskell.org> #10843: Allow do blocks without dollar signs as arguments -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: agibiansky Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1219 -------------------------------------+------------------------------------- Comment (by thomie): There was a giant (>75 email) discussion about this ticket here: https://mail.haskell.org/pipermail/haskell-cafe/2015-September/121217.html Is there a summary/conclusion somewhere? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 22:27:46 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 22:27:46 -0000 Subject: [GHC] #10842: "Reactive" Template Haskell In-Reply-To: <050.6f7bb562017372f9e5bba0241a40c1a7@haskell.org> References: <050.6f7bb562017372f9e5bba0241a40c1a7@haskell.org> Message-ID: <065.192c1ad829a842c993d3250d04e8444a@haskell.org> #10842: "Reactive" Template Haskell -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9699, #10391 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * related: 9699 => #9699, #10391 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 22:28:17 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 22:28:17 -0000 Subject: [GHC] #10391: Ability to get export list of TH reified module In-Reply-To: <047.4433cd04132dabf0d7e1565467e79715@haskell.org> References: <047.4433cd04132dabf0d7e1565467e79715@haskell.org> Message-ID: <062.67c0212219cba2873c1080b8e163c953@haskell.org> #10391: Ability to get export list of TH reified module -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Template Haskell | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10842 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * related: => #10842 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 23:03:59 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 23:03:59 -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.3320692f09e219fe987f5186efa5108a@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: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | nofib/spectral/calendar Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): See #10825 for another example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 23:04:39 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 23:04:39 -0000 Subject: [GHC] #10825: Poor performance of optimized code. In-Reply-To: <047.7261042eeb6a92f89b4e63b1da792373@haskell.org> References: <047.7261042eeb6a92f89b4e63b1da792373@haskell.org> Message-ID: <062.65712cd93780c79b77d304377b45e0b2@haskell.org> #10825: Poor performance of optimized code. -------------------------------------+------------------------------------- Reporter: AndriusS | Owner: bgamari Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #1168 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: #8814, #8835 => #1168 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 23:10:34 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 23:10:34 -0000 Subject: [GHC] #10375: arm: ghci hits an illegal instruction In-Reply-To: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> References: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> Message-ID: <059.35ecc81fb450c23c576e7db58578dde4@haskell.org> #10375: arm: ghci hits an illegal instruction -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: Runtime System | Version: 7.10.1 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by erikd): Bingo! I was building the compiler comfigured with `--enable-unregisterised` so that GDB be actually be useful. Noticed that loading `inplace/bin/ghc- stage2 --interactve` into GDB and running it caused a SIGILL here: {{{ (gdb) disassemble Dump of assembler code for function stg_ap_v_fast: 0x03ff9db4 <+0>: push {r7, lr} 0x03ff9db6 <+2>: sub sp, #32 0x03ff9db8 <+4>: add r7, sp, #0 0x03ff9dba <+6>: ldr r3, [pc, #508] ; (0x3ff9fb8 ) => 0x03ff9dbc <+8>: ldr r3, [r3, #0] 0x03ff9dbe <+10>: and.w r3, r3, # }}} I also found that if I reloaded the debug target and set a break point in `stg_ap_v_fast` I could step though the code of that function without a crash. The `SIGILL` crash was only happening after executing a function that was loaded by the GHCi run time linker. The other clue in the assembly code for the `stg_ap_v_fast` funtcion was that it shows Thumb instructions (all Thumb instructions are encoded in two bytes whereas all Arm instructions are encoded in 4 bytes), and elsewhere I learned that `SIGILL` can occur when executng Arm instructions in Thumb mode and vice versa. In a monolithic executable, jumps from Arm code to Thumb code are correctly handled by the linker so the compiler itself was correctly linked. However, object code loaded at run time by GHCi is loaded by GHCi's run time linker which may not be getting the Arm/Thumb interop correct. Then I figured out that all Haskell code compiled via the LLVM backend generates pure Arm code but the C code compiler with GCC was Thumb code. Fortunately GCC can be forced to generate pure Arm code with the `-marm` option. With the `-marm` GHCi works when compiled `Unregisterised`. In `Registerised` mode there are still some problems: {{{ Prelude> data X = X | Y deriving Eq Prelude> X == Y False Prelude> X == X Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb59ff460 (LWP 20022)] 0xb6ff0024 in ?? () (gdb) disass 0xb6ff0024 No function contains specified address. (gdb) disass 0xb6ff0020,+10 Dump of assembler code from 0xb6ff0020 to 0xb6ff002a: 0xb6ff0020: ldrbvs r6, [r4, #-3689]! ; 0xe69 => 0xb6ff0024: strbtvc r6, [r3], #-370 ; 0x172 0xb6ff0028: bcc 0xb894d9d4 End of assembler dump. (gdb) info regs Undefined info command: "regs". Try "help info". (gdb) info registers r0 0xb6ff0018 3070165016 r1 0x28 40 r2 0x1 1 r3 0x70000000 1879048192 r4 0x234db90 37018512 r5 0xb6cd451c 3066905884 r6 0xb6c1a33c 3066143548 r7 0xb6cddbec 3066944492 r8 0xb3a550fc 3013955836 r9 0x7fffffff 2147483647 r10 0x1e6d24c 31904332 r11 0xb6cd4254 3066905172 r12 0x234d37c 37016444 sp 0x1316abc0 0x1316abc0 lr 0x70000000 1879048192 pc 0xb6ff0024 0xb6ff0024 cpsr 0x400f0010 1074724880 }}} The value of `r3`, 0x70000000 seems to be a strange address to be loading data from. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 23:11:23 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 23:11:23 -0000 Subject: [GHC] #10821: Add a flag to avoid generation of .hi, .o, .dyn_* files In-Reply-To: <045.f0f41ad07a5d71b217261fb2fd5616e4@haskell.org> References: <045.f0f41ad07a5d71b217261fb2fd5616e4@haskell.org> Message-ID: <060.6bd6725c4ec8e8a5bd4b924358484435@haskell.org> #10821: Add a flag to avoid generation of .hi, .o, .dyn_* files -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => invalid Comment: What ezyang said. We don't need any new flag though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 23:14:51 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 23:14:51 -0000 Subject: [GHC] #10817: Looping default associated type family without UndecidableInstances In-Reply-To: <047.64ffaf6cb4d5ab1829ed952b25df0d19@haskell.org> References: <047.64ffaf6cb4d5ab1829ed952b25df0d19@haskell.org> Message-ID: <062.617d4aa9f779e7fe74fad31907862ce9@haskell.org> #10817: Looping default associated type family without UndecidableInstances -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * component: Compiler => Compiler (Type checker) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 16 23:22:52 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Sep 2015 23:22:52 -0000 Subject: [GHC] #10751: Implement Phase 1 of MonadFail Proposal (MFP) In-Reply-To: <042.af0b8689bcfac4a130648c64d759a4c0@haskell.org> References: <042.af0b8689bcfac4a130648c64d759a4c0@haskell.org> Message-ID: <057.66c6365038fd157bf5890c08817fd3fe@haskell.org> #10751: Implement Phase 1 of MonadFail Proposal (MFP) -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: report- | impact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by quchen): Draft submitted to Phab: https://phabricator.haskell.org/D1248 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 17 00:10:43 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Sep 2015 00:10:43 -0000 Subject: [GHC] Batch modify: #9137, #9601, #10804 Message-ID: <20150917001043.2F9B53A2FF@ghc.haskell.org> Batch modification to #9137, #9601, #10804 by thomie: failure to Runtime performance bug Comment: These tickets are related to runtime performance. -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 17 00:37:13 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Sep 2015 00:37:13 -0000 Subject: [GHC] #10790: amd64/solaris 11: dll-split: out of memory (requested 1099512676352 bytes) In-Reply-To: <046.47e31a9b6a306f95c5ab473eb166ad84@haskell.org> References: <046.47e31a9b6a306f95c5ab473eb166ad84@haskell.org> Message-ID: <061.554d7f6ec456ce3ba3352a8645e1912e@haskell.org> #10790: amd64/solaris 11: dll-split: out of memory (requested 1099512676352 bytes) -------------------------------------+------------------------------------- Reporter: kgardas | Owner: kgardas Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Runtime System | Version: 7.11 Resolution: fixed | Keywords: Operating System: Solaris | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1169 -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => closed * differential: => Phab:D1169 * resolution: => fixed * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 17 00:56:06 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Sep 2015 00:56:06 -0000 Subject: [GHC] #10383: AArch64: get GHC Calling convention working In-Reply-To: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> References: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> Message-ID: <059.112b8f7bb8fd3136b46ba9f26d352dd0@haskell.org> #10383: AArch64: get GHC Calling convention working ----------------------------------------+---------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------------+---------------------------------- Comment (by erikd): With the un-reasonable effectiveness of wolf-fence debugging on #10375 I decided to apply it to this one as well and quickly found that the stage2 compiler was crashing in the function `SysTools.initSysTools`. With my added debug that function currently looks like: {{{ initSysTools :: Maybe String -- Maybe TopDir path (without the '-B' prefix) -> IO Settings -- Set all the mutable variables above, holding -- (a) the system programs -- (b) the package-config file -- (c) the GHC usage message initSysTools mbMinusB = do top_dir <- findTopDir mbMinusB -- see [Note topdir] -- NB: top_dir is assumed to be in standard Unix -- format, '/' separated let settingsFile = top_dir "settings" platformConstantsFile = top_dir "platformConstants" installed :: FilePath -> FilePath installed file = top_dir file putStrLn "initSysTools: About to read settingsFile" settingsStr <- readFile settingsFile putStrLn $ "initSysTools: settingsStr = \n" ++ settingsStr ++ "\n" mySettings <- case maybeReadFuzzy settingsStr of Just s -> do putStrLn "initSysTools: mySettings is Just" return s Nothing -> do putStrLn $ "initSysTools mySettings is Nothing" pgmError ("Can't parse " ++ show settingsFile) putStrLn $ "initSysTools " ++ show (__LINE__ :: Int) ... }}} and it crashes with: {{{ initSysTools: About to read settingsFile initSysTools: settingsStr = [("GCC extra via C opts", " -fwrapv"), ("C compiler command", "/usr/bin/gcc"), ("C compiler flags", " -fno-stack-protector"), ("C compiler link flags", " -fuse-ld=gold -Wl,-z,noexecstack"), ("Haskell CPP command","/usr/bin/gcc"), ("Haskell CPP flags","-E -undef -traditional"), ("ld command", "/usr/bin/ld.gold"), ("ld flags", " -z noexecstack"), ("ld supports compact unwind", "YES"), ("ld supports build-id", "YES"), ("ld supports filelist", "NO"), ("ld is GNU ld", "YES"), ("ar command", "/usr/bin/ar"), ("ar flags", "q"), ("ar supports at file", "YES"), ("touch command", "touch"), ("dllwrap command", "/bin/false"), ("windres command", "/bin/false"), ("libtool command", "libtool"), ("perl command", "/usr/bin/perl"), ("cross compiling", "NO"), ("target os", "OSLinux"), ("target arch", "ArchARM64"), ("target word size", "8"), ("target has GNU nonexec stack", "True"), ("target has .ident directive", "True"), ("target has subsections via symbols", "False"), ("Unregisterised", "NO"), ("LLVM llc command", "/usr/bin/llc-3.6"), ("LLVM opt command", "/usr/bin/opt-3.6") ] ghc-stage2: internal error: invalid closure, info=(nil) (GHC version 7.11.20150916 for aarch64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} It reads the `String` from `settingsFile` and prints it and then crashes in the pure function `maybeReadFuzzy`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 17 01:24:09 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Sep 2015 01:24:09 -0000 Subject: [GHC] #10781: Qualified use of undefined name starting with underscore considered a hole In-Reply-To: <048.05d55f91f7c6a759b2d92132b817f2bc@haskell.org> References: <048.05d55f91f7c6a759b2d92132b817f2bc@haskell.org> Message-ID: <063.3e4e85cba01560846e40fdd533e8fb58@haskell.org> #10781: Qualified use of undefined name starting with underscore considered a hole -------------------------------------+------------------------------------- Reporter: EyalLotem | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: holes | qualified Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"8d89d80d907a7df1d455e87a382b41dc65c42140/ghc" 8d89d80/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8d89d80d907a7df1d455e87a382b41dc65c42140" Testsuite: add test for #10781 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 17 01:25:09 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Sep 2015 01:25:09 -0000 Subject: [GHC] #10781: Qualified use of undefined name starting with underscore considered a hole In-Reply-To: <048.05d55f91f7c6a759b2d92132b817f2bc@haskell.org> References: <048.05d55f91f7c6a759b2d92132b817f2bc@haskell.org> Message-ID: <063.b738f608df8d5e99d114f0bf421ce4c4@haskell.org> #10781: Qualified use of undefined name starting with underscore considered a hole -------------------------------------+------------------------------------- Reporter: EyalLotem | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: holes | qualified Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | rename/should_fail/T10781.hs Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * testcase: => rename/should_fail/T10781.hs * status: new => closed * resolution: => fixed * milestone: => 8.0.1 Comment: Thanks for the report. Fixed in HEAD already. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 17 01:49:32 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Sep 2015 01:49:32 -0000 Subject: [GHC] #10878: Near doubling of generated code size for compiler/cmm/PprC.hs with commit 5d57087e31 In-Reply-To: <044.9d94a947d4932234addf1109fa44fa7c@haskell.org> References: <044.9d94a947d4932234addf1109fa44fa7c@haskell.org> Message-ID: <059.81a4fa834f5739bd340c8b4d29972bfc@haskell.org> #10878: Near doubling of generated code size for compiler/cmm/PprC.hs with commit 5d57087e31 -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): If you need this fixed quickly, you can revert 5d57087e314bd484dbe14958f9b422be3ac6641a and f903949beee3a4e0a925003b5553066c9f513c11. They're not terrible vital. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 17 06:49:12 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Sep 2015 06:49:12 -0000 Subject: [GHC] #10168: generalize filterM, mapAndUnzipM, zipWithM, zipWithM_, replicateM, replicateM_ In-Reply-To: <048.86721c518b657437564df331356981ea@haskell.org> References: <048.86721c518b657437564df331356981ea@haskell.org> Message-ID: <063.90c7e27a757f60ea3f07e143907e15cd@haskell.org> #10168: generalize filterM, mapAndUnzipM, zipWithM, zipWithM_, replicateM, replicateM_ -------------------------------------+------------------------------------- Reporter: strake888 | Owner: ekmett Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by strake888): * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 17 06:52:33 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Sep 2015 06:52:33 -0000 Subject: [GHC] #10375: arm: ghci hits an illegal instruction In-Reply-To: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> References: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> Message-ID: <059.ef2b36871ccb2deb14c9898b5d5f43ef@haskell.org> #10375: arm: ghci hits an illegal instruction -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: Runtime System | Version: 7.10.1 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by erikd): Tried re-producing this segfault with `--enable-unregisterised` mainly because the Unregisterised mode can be debugged in GDB. Unfortunately, the segfault doesn't happen in Unregisterised mode. Going back to registerised mode. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 17 06:53:15 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Sep 2015 06:53:15 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMDIxNjogQWxsb3cgYXJyIOKIpyAoZmlyc3Qg?= =?utf-8?q?=E2=88=A8_=28***=29=29_as_minimal_definition_of_Arrow_?= =?utf-8?q?instance?= In-Reply-To: <048.64b271a00a46843da0df000240882f80@haskell.org> References: <048.64b271a00a46843da0df000240882f80@haskell.org> Message-ID: <063.44e1d6ca96a5b8804313babc8cfbeca5@haskell.org> #10216: Allow arr ? (first ? (***)) as minimal definition of Arrow instance -------------------------------------+------------------------------------- Reporter: strake888 | Owner: ekmett Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by strake888): * status: infoneeded => patch Comment: I sent a proposal to libraries at haskell.org and no one complained so I'm setting the status back to patch ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 17 07:25:52 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Sep 2015 07:25:52 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMDIxNjogQWxsb3cgYXJyIOKIpyAoZmlyc3Qg?= =?utf-8?q?=E2=88=A8_=28***=29=29_as_minimal_definition_of_Arrow_?= =?utf-8?q?instance?= In-Reply-To: <048.64b271a00a46843da0df000240882f80@haskell.org> References: <048.64b271a00a46843da0df000240882f80@haskell.org> Message-ID: <063.6507ee7d7618b01046d264f4b3105ce9@haskell.org> #10216: Allow arr ? (first ? (***)) as minimal definition of Arrow instance -------------------------------------+------------------------------------- Reporter: strake888 | Owner: ekmett Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Edward, can we have your ok? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 17 08:38:05 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Sep 2015 08:38:05 -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.f21bd742455cd312c6cfcf0a32ba2199@haskell.org> #9855: Harbormaster uses the wrong code sometimes -------------------------------------+------------------------------------- Reporter: goldfire | Owner: | thoughtpolice Type: bug | Status: closed Priority: normal | Milestone: Component: Trac & Git | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed Comment: I think this is fixed now. You should now get a 'patch doesn't apply' error, which you can resolve by pulling master and rebasing your patch onto it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 17 08:43:58 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Sep 2015 08:43:58 -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.aa07d78497d624882bd2c043e1ad6f4a@haskell.org> #9912: Allow access to full logs in Harbormaster builds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: | thoughtpolice Type: bug | Status: closed Priority: normal | Milestone: Component: Trac & Git | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed Comment: Phabricator now show 1000 lines of log on failed builds. Ping thoughtpolice or open a ticket here if that's still not good enough: https://github.com/haskell-infra/phab-ghc-builder. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 17 08:45:25 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Sep 2015 08:45:25 -0000 Subject: [GHC] #10033: Can't push to `wip/...` branches because of pre-commit check In-Reply-To: <047.b5a5fb2b14296aa7dfc2b8e58a6a2c93@haskell.org> References: <047.b5a5fb2b14296aa7dfc2b8e58a6a2c93@haskell.org> Message-ID: <062.c3c71854105cacd0cd385c257dbda762@haskell.org> #10033: Can't push to `wip/...` branches because of pre-commit check -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Trac & Git | Version: 7.8.4 Resolution: worksforme | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => worksforme Comment: I'm going to assume this is fixed, or there would be many more reports of it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 17 08:46:16 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Sep 2015 08:46:16 -0000 Subject: [GHC] #10035: Harbormaster doesn't post to Differential on success In-Reply-To: <047.651e63f29ee488b1428e2fffc73c9399@haskell.org> References: <047.651e63f29ee488b1428e2fffc73c9399@haskell.org> Message-ID: <062.34ab37b290ee2482225f0ea819f5b416@haskell.org> #10035: Harbormaster doesn't post to Differential on success -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * cc: thoughtpolice (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 17 09:07:35 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Sep 2015 09:07:35 -0000 Subject: [GHC] #10817: Looping default associated type family without UndecidableInstances In-Reply-To: <047.64ffaf6cb4d5ab1829ed952b25df0d19@haskell.org> References: <047.64ffaf6cb4d5ab1829ed952b25df0d19@haskell.org> Message-ID: <062.d0aa8986a3626da493c39c2a196f006c@haskell.org> #10817: Looping default associated type family without UndecidableInstances -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by jstolarek): * cc: jstolarek (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 17 09:11:42 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Sep 2015 09:11:42 -0000 Subject: [GHC] #9782: Do not by default set ekmett as owner for 'Core libraries' In-Reply-To: <045.9a4eaf64f0d6b763bc80d89ea22b10c3@haskell.org> References: <045.9a4eaf64f0d6b763bc80d89ea22b10c3@haskell.org> Message-ID: <060.8da655c20668eeb8fdab337b112df071@haskell.org> #9782: Do not by default set ekmett as owner for 'Core libraries' -------------------------------------+------------------------------------- Reporter: thomie | Owner: hvr Type: bug | Status: closed Priority: normal | Milestone: Component: Trac & Git | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 17 09:19:49 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Sep 2015 09:19:49 -0000 Subject: [GHC] Batch modify: #4442, #2200, #3628, #3676, #4102, #5466, #5797, ... Message-ID: <20150917091949.ECEEE3A2FF@ghc.haskell.org> Batch modification to #4442, #2200, #3628, #3676, #4102, #5466, #5797, #5966, #6101, #7045, #7161, #7285, #7309, #7353, #7634, #8354, #8627, #8666, #8767, #8772, #8850, #8859, #9079, #9120, #9292, #9306, #9539, #9542, #9638, #9674, #9716, #9724, #9792, #9865, #9908, #10014, #10022, #10039, #10168, #10216, #10328, #10444, #10465, #10512, #10514, #10773, #10792, #10865, #3980, #4329, #4861, #5251, #8532, #8730, #9283, #9631, #9864, #10063, #10604, #1487, #2140, #3606, #8293, #9505, #10365, #10448 by thomie: Action: unassign -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 17 09:35:24 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Sep 2015 09:35:24 -0000 Subject: [GHC] #10375: arm: ghci hits an illegal instruction In-Reply-To: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> References: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> Message-ID: <059.6bb4521e13aef2df6432ecb8d143d766@haskell.org> #10375: arm: ghci hits an illegal instruction -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: Runtime System | Version: 7.10.1 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by erikd): When compiler in Registerised mode, `inplace/bin/ghc-stage2 --interactive` basically works. I can import modules, I can print things etc. Everything works fine until: {{{ Prelude> data X = X | Y deriving Eq Prelude> X == X Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb59ff460 (LWP 29599)] 0xb6ff0024 in ?? () (gdb) bt #0 0xb6ff0024 in ?? () #1 0x70000000 in ?? () Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb) disass 0xb6ff0020,+0x30 Dump of assembler code from 0xb6ff0020 to 0xb6ff0050: 0xb6ff0020: ldrbvs r6, [r4, #-3689]! ; 0xe69 => 0xb6ff0024: strbtvc r6, [r3], #-370 ; 0x172 0xb6ff0028: bcc 0xb894d9d4 0xb6ff002c: stmdbvs r3!, {r0, r1, r2, r6, r11, sp, lr}^ 0xb6ff0030: subseq r2, r8, r1, lsr lr 0xb6ff0034: andeq r0, r0, r3, lsr r0 0xb6ff0038: ; instruction: 0xb6ff0038 0xb6ff003c: andeq r0, r0, r8 0xb6ff0040: andeq r0, r1, r0 0xb6ff0044: andeq r0, r1, r1 0xb6ff0048: stmdaeq r7, {r0, r3, r6}^ 0xb6ff004c: strdeq r12, [r6, #208]! ; 0xd0 End of assembler dump. (gdb) info registers r0 0xb6ff0018 3070165016 r1 0x28 40 r2 0x1 1 r3 0x70000000 1879048192 r4 0x2350b50 37030736 r5 0xb38c4a0c 3012315660 r6 0xb5187d24 3038280996 r7 0xb38c4b30 3012315952 r8 0xb2ad2c38 2997693496 r9 0x7fffffff 2147483647 r10 0x1e6cef4 31903476 r11 0xb38c4750 3012314960 r12 0x235036c 37028716 sp 0xb59fcd70 0xb59fcd70 lr 0x70000000 1879048192 pc 0xb6ff0024 0xb6ff0024 cpsr 0x400f0010 1074724880 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 17 09:41:26 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Sep 2015 09:41:26 -0000 Subject: [GHC] #10320: -ddump-to-file should create empty dump files when there was nothing to dump In-Reply-To: <047.561f277130457f34a85813c7ce1004aa@haskell.org> References: <047.561f277130457f34a85813c7ce1004aa@haskell.org> Message-ID: <062.fe5bf626d62c9dd3533051db78520ebb@haskell.org> #10320: -ddump-to-file should create empty dump files when there was nothing to dump -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: MarceColl Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): MarceColl: any progress? Pleas unassign yourself if you don't plan to work on this anymore. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 17 09:45:19 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Sep 2015 09:45:19 -0000 Subject: [GHC] #8109: Type family patterns should support as-patterns. In-Reply-To: <050.c933323dc7b27f878df54b935f73c14c@haskell.org> References: <050.c933323dc7b27f878df54b935f73c14c@haskell.org> Message-ID: <065.2212d04b4ca7e4edcea178dc5378f652@haskell.org> #8109: Type family patterns should support as-patterns. -------------------------------------+------------------------------------- Reporter: carlhowells | Owner: qnikst Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): qnikst: any progress? Please ask if you need help with anything, or unassign yourself if you don't plan to work on this ticket anymore. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 17 09:47:17 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Sep 2015 09:47:17 -0000 Subject: [GHC] #4931: hsc2hs emits invalid OPTIONS_GHC pragmas In-Reply-To: <044.1c25c557108c2107caf9aec19c931e7c@haskell.org> References: <044.1c25c557108c2107caf9aec19c931e7c@haskell.org> Message-ID: <059.d325b623f11427b550348c2ae5f82700@haskell.org> #4931: hsc2hs emits invalid OPTIONS_GHC pragmas -------------------------------------+------------------------------------- Reporter: awson | Owner: terrelln Type: bug | Status: new Priority: low | Milestone: 8.0.1 Component: hsc2hs | Version: 7.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): terrelin: did you make any progress with this ticket? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 17 09:51:59 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Sep 2015 09:51:59 -0000 Subject: [GHC] #9022: TH pretty printer and GHC parser semicolon placement mismatch In-Reply-To: <047.5de523bade6a019122fff089f11b671b@haskell.org> References: <047.5de523bade6a019122fff089f11b671b@haskell.org> Message-ID: <062.be43565ed3e6addcb9ce0968abdb5ec2@haskell.org> #9022: TH pretty printer and GHC parser semicolon placement mismatch -------------------------------------+------------------------------------- Reporter: roldugin | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.8.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * owner: roldugin => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 17 10:32:54 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Sep 2015 10:32:54 -0000 Subject: [GHC] #10821: Add a flag to avoid generation of .hi, .o, .dyn_* files In-Reply-To: <045.f0f41ad07a5d71b217261fb2fd5616e4@haskell.org> References: <045.f0f41ad07a5d71b217261fb2fd5616e4@haskell.org> Message-ID: <060.fcfeb9a7d85c23451f879271e208c242@haskell.org> #10821: Add a flag to avoid generation of .hi, .o, .dyn_* files -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #2258, #4114 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * related: => #2258, #4114 Comment: #2258 and #4114 are related. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 17 12:14:18 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Sep 2015 12:14:18 -0000 Subject: [GHC] #8109: Type family patterns should support as-patterns. In-Reply-To: <050.c933323dc7b27f878df54b935f73c14c@haskell.org> References: <050.c933323dc7b27f878df54b935f73c14c@haskell.org> Message-ID: <065.72af939fdaf088957774139e70cb933b@haskell.org> #8109: Type family patterns should support as-patterns. -------------------------------------+------------------------------------- Reporter: carlhowells | Owner: qnikst Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by qnikst): @thomie, still working I'm planning to invest more time into this ticket after this weekend. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 17 13:05:34 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Sep 2015 13:05:34 -0000 Subject: [GHC] #10751: Implement Phase 1 of MonadFail Proposal (MFP) In-Reply-To: <042.af0b8689bcfac4a130648c64d759a4c0@haskell.org> References: <042.af0b8689bcfac4a130648c64d759a4c0@haskell.org> Message-ID: <057.90ff5ee81807653b120e7cdbd289a689@haskell.org> #10751: Implement Phase 1 of MonadFail Proposal (MFP) -------------------------------------+------------------------------------- Reporter: hvr | Owner: quchen Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: report- | impact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * owner: => quchen -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 17 13:05:41 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Sep 2015 13:05:41 -0000 Subject: [GHC] #10751: Implement Phase 1 of MonadFail Proposal (MFP) In-Reply-To: <042.af0b8689bcfac4a130648c64d759a4c0@haskell.org> References: <042.af0b8689bcfac4a130648c64d759a4c0@haskell.org> Message-ID: <057.4e7c7d3a859ee348c3fe853e92c30bfc@haskell.org> #10751: Implement Phase 1 of MonadFail Proposal (MFP) -------------------------------------+------------------------------------- Reporter: hvr | Owner: quchen Type: task | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: report- | impact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 17 13:06:19 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Sep 2015 13:06:19 -0000 Subject: [GHC] #10751: Implement Phase 1 of MonadFail Proposal (MFP) In-Reply-To: <042.af0b8689bcfac4a130648c64d759a4c0@haskell.org> References: <042.af0b8689bcfac4a130648c64d759a4c0@haskell.org> Message-ID: <057.95d88c3ad8c26739ed44d58ff3438fc8@haskell.org> #10751: Implement Phase 1 of MonadFail Proposal (MFP) -------------------------------------+------------------------------------- Reporter: hvr | Owner: quchen Type: task | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: report- | impact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1248 -------------------------------------+------------------------------------- Changes (by hvr): * priority: normal => highest * differential: => Phab:D1248 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 17 13:37:18 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Sep 2015 13:37:18 -0000 Subject: [GHC] #10035: Harbormaster doesn't post to Differential on success In-Reply-To: <047.651e63f29ee488b1428e2fffc73c9399@haskell.org> References: <047.651e63f29ee488b1428e2fffc73c9399@haskell.org> Message-ID: <062.276b7ead47700908a152473d0cee2c37@haskell.org> #10035: Harbormaster doesn't post to Differential on success -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Trac & Git | Version: Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate Comment: Migrating to https://phabricator.haskell.org/project/view/2/, specifically https://phabricator.haskell.org/T289. This is the Phabricator issue tracker. Hopefully it gets more attention there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 17 13:42:08 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Sep 2015 13:42:08 -0000 Subject: [GHC] #9976: Ignore newlines in code diffs on Phab In-Reply-To: <047.8a70901b5a5669f0afb215416c9a9006@haskell.org> References: <047.8a70901b5a5669f0afb215416c9a9006@haskell.org> Message-ID: <062.7631ef6833293fe20b0529b0829e9683@haskell.org> #9976: Ignore newlines in code diffs on Phab -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature request | Status: closed Priority: low | Milestone: Component: Trac & Git | Version: 7.8.4 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate Comment: Migrated to https://phabricator.haskell.org/T290. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 17 14:00:33 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Sep 2015 14:00:33 -0000 Subject: [GHC] #10847: :info should print minimal definition In-Reply-To: <043.c6e083f7f51bc9197fc9d4b0280ca574@haskell.org> References: <043.c6e083f7f51bc9197fc9d4b0280ca574@haskell.org> Message-ID: <058.190033231728c60ec1e1df492cb3a2b0@haskell.org> #10847: :info should print minimal definition -------------------------------------+------------------------------------- Reporter: osa1 | Owner: cocreature Type: feature request | Status: new Priority: lowest | Milestone: 8.0.1 Component: GHCi | Version: 7.11 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1241 -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"43eb1dc52a4d3cbba9617f5a26177b8251d84b6a/ghc" 43eb1dc5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="43eb1dc52a4d3cbba9617f5a26177b8251d84b6a" Show minimal complete definitions in ghci (#10847) Show the minimal complete definition on :info in ghci. They are shown like MINIMAL pragmas in code. If the minimal complete definition is empty or only a specific method from a class is requested, nothing is shown. Reviewed By: simonpj, austin, thomie Differential Revision: https://phabricator.haskell.org/D1241 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 17 14:02:37 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Sep 2015 14:02:37 -0000 Subject: [GHC] #10847: :info should print minimal definition In-Reply-To: <043.c6e083f7f51bc9197fc9d4b0280ca574@haskell.org> References: <043.c6e083f7f51bc9197fc9d4b0280ca574@haskell.org> Message-ID: <058.ef7ff5c6b2480120e05b5068d12724d4@haskell.org> #10847: :info should print minimal definition -------------------------------------+------------------------------------- Reporter: osa1 | Owner: cocreature Type: feature request | Status: closed Priority: lowest | Milestone: 8.0.1 Component: GHCi | Version: 7.11 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1241 -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 17 15:01:15 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Sep 2015 15:01:15 -0000 Subject: [GHC] #10890: Incorrect redundant import warning for type classes Message-ID: <045.1d7793ff19c595f6fc025366df90cb33@haskell.org> #10890: Incorrect redundant import warning for type classes -------------------------------------+------------------------------------- Reporter: quchen | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Given the three files below, the import marked with (!!!) is reported as redundant. Upon deleting it, GHC reports that "has" is not a visible class method of BClass. This came up in the context of the MFP (#10751), with the correspondences Base<->Control.Monad, Extends<->Control.Monad.Fail. We would like to have Control.Monad re-export Control.Monad.Fail.MonadFail without its (clashing) member "fail" for the time being. For future compatibility, some modules should implement MonadFail right now, requiring us to import Control.Monad.Fail explicitly in order to write an instance. Said procedure leads to the described import warning, which breaks the validation script for example. {{{#!hs -- Base.hs module Base (AClass(..), BClass()) where import Extends (BClass()) class AClass a where has :: a }}} {{{#!hs -- Extends.hs module Extends where class BClass b where has :: b }}} {{{#!hs -- UseSite.hs module UseSite where import Base import Extends -- (!!!) data Bar = Bar instance AClass Bar where has = Bar instance BClass Bar where has = Bar }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 17 15:40:41 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Sep 2015 15:40:41 -0000 Subject: [GHC] #10890: Incorrect redundant import warning for type classes In-Reply-To: <045.1d7793ff19c595f6fc025366df90cb33@haskell.org> References: <045.1d7793ff19c595f6fc025366df90cb33@haskell.org> Message-ID: <060.12deacb9b36f75175e58b06cd7fab808@haskell.org> #10890: Incorrect redundant import warning for type classes -------------------------------------+------------------------------------- Reporter: quchen | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by quchen): * cc: hvr (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 17 15:43:19 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Sep 2015 15:43:19 -0000 Subject: [GHC] #10890: Incorrect redundant import warning for type classes In-Reply-To: <045.1d7793ff19c595f6fc025366df90cb33@haskell.org> References: <045.1d7793ff19c595f6fc025366df90cb33@haskell.org> Message-ID: <060.dfbd7190853ef4ff7030a3f7c3f63f96@haskell.org> #10890: Incorrect redundant import warning for type classes -------------------------------------+------------------------------------- Reporter: quchen | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by quchen: Old description: > Given the three files below, the import marked with (!!!) is reported as > redundant. Upon deleting it, GHC reports that "has" is not a visible > class method of BClass. > > This came up in the context of the MFP (#10751), with the correspondences > Base<->Control.Monad, Extends<->Control.Monad.Fail. We would like to have > Control.Monad re-export Control.Monad.Fail.MonadFail without its > (clashing) member "fail" for the time being. For future compatibility, > some modules should implement MonadFail right now, requiring us to import > Control.Monad.Fail explicitly in order to write an instance. Said > procedure leads to the described import warning, which breaks the > validation script for example. > > {{{#!hs > -- Base.hs > module Base (AClass(..), BClass()) where > > import Extends (BClass()) > > class AClass a where > has :: a > }}} > > {{{#!hs > -- Extends.hs > module Extends where > > class BClass b where > has :: b > }}} > > {{{#!hs > -- UseSite.hs > module UseSite where > > import Base > import Extends -- (!!!) > > data Bar = Bar > > instance AClass Bar where > has = Bar > > instance BClass Bar where > has = Bar > }}} New description: Given the three files below, the import marked with (!!!) is reported as redundant. Upon deleting it, GHC reports that "has" is not a visible class method of BClass. This came up in the context of the MFP (#10751), with the correspondences Base<->Control.Monad, Extends<->Control.Monad.Fail. We would like to have Control.Monad re-export Control.Monad.Fail.MonadFail without its (clashing) member "fail" for the time being. For future compatibility, some modules should implement MonadFail right now, requiring us to import Control.Monad.Fail explicitly in order to write an instance. Said procedure leads to the described import warning, which breaks the validation script for example. {{{#!hs -- Base.hs module Base (AClass(..), BClass()) where import Extends (BClass()) class AClass a where has :: a }}} {{{#!hs -- Extends.hs module Extends where class BClass b where has :: b }}} {{{#!hs -- UseSite.hs module UseSite where import Base import Extends -- (!!!) data Bar = Bar instance AClass Bar where has = Bar instance BClass Bar where has = Bar }}} We either get {{{ UseSite.hs:12:5: error: ?has? is not a (visible) method of class ?BClass? }}} or {{{ UseSite.hs:4:1: warning: The import of ?Extends? is redundant except perhaps to import instances from ?Extends? To import instances alone, use: import Extends() }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 17 17:24:23 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Sep 2015 17:24:23 -0000 Subject: [GHC] #10865: Poly-kinded Const In-Reply-To: <048.9e286d630268edb801227c2f20a8ad8a@haskell.org> References: <048.9e286d630268edb801227c2f20a8ad8a@haskell.org> Message-ID: <063.189448d283fbbd3091bc5da074d45ddb@haskell.org> #10865: Poly-kinded Const -------------------------------------+------------------------------------- Reporter: int-index | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.2 Resolution: | Keywords: poly- | kinded, Const Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott, ekmett (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 17 17:25:25 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Sep 2015 17:25:25 -0000 Subject: [GHC] Batch modify: #7181, #7644, #7917, #8992, #9076, #9149, #9248, ... Message-ID: <20150917172525.0ACBD3A2FF@ghc.haskell.org> Batch modification to #7181, #7644, #7917, #8992, #9076, #9149, #9248, #9348, #9737, #10262, #10342, #10353, #10416, #10509, #10640, #10766, #10772, #9247, #9249, #9917, #10475, #1574, #2776, #3351 by thomie: failure to Documentation bug -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 17 17:25:38 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Sep 2015 17:25:38 -0000 Subject: [GHC] #10604: Make Generic1 kind polymorphic In-Reply-To: <050.900476330e5007bcb132f742a5f2d072@haskell.org> References: <050.900476330e5007bcb132f742a5f2d072@haskell.org> Message-ID: <065.1a60e42782ded6d0008e24f81ddd31f2@haskell.org> #10604: Make Generic1 kind polymorphic -------------------------------------+------------------------------------- Reporter: DerekElkins | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott, ekmett (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 17 17:28:11 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Sep 2015 17:28:11 -0000 Subject: [GHC] #10514: Generic for existential types In-Reply-To: <051.d185121bcf194fc1021cab90b66f9d08@haskell.org> References: <051.d185121bcf194fc1021cab90b66f9d08@haskell.org> Message-ID: <066.04dec60b9ed38b42d5f7bf088abaedb6@haskell.org> #10514: Generic for existential types -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott, ekmett (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 17 17:29:19 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Sep 2015 17:29:19 -0000 Subject: [GHC] #10865: Poly-kinded Const In-Reply-To: <048.9e286d630268edb801227c2f20a8ad8a@haskell.org> References: <048.9e286d630268edb801227c2f20a8ad8a@haskell.org> Message-ID: <063.6a885db62c5aae2bd11eeb19a68c3045@haskell.org> #10865: Poly-kinded Const -------------------------------------+------------------------------------- Reporter: int-index | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.2 Resolution: | Keywords: poly- | kinded, Const Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by RyanGlScott): This is a duplicate of #10039, no? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 17 17:33:54 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Sep 2015 17:33:54 -0000 Subject: [GHC] #10865: Poly-kinded Const In-Reply-To: <048.9e286d630268edb801227c2f20a8ad8a@haskell.org> References: <048.9e286d630268edb801227c2f20a8ad8a@haskell.org> Message-ID: <063.5a6bd4cd2d9252a52f67eb9f14eca9ee@haskell.org> #10865: Poly-kinded Const -------------------------------------+------------------------------------- Reporter: int-index | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.2 Resolution: | Keywords: poly- | kinded, Const Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by int-index): Replying to [comment:4 RyanGlScott]: > This is a duplicate of #10039, no? Oops, it is. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 17 17:36:08 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Sep 2015 17:36:08 -0000 Subject: [GHC] #10865: Poly-kinded Const In-Reply-To: <048.9e286d630268edb801227c2f20a8ad8a@haskell.org> References: <048.9e286d630268edb801227c2f20a8ad8a@haskell.org> Message-ID: <063.801c4cc853fd04682160142503ad7233@haskell.org> #10865: Poly-kinded Const -------------------------------------+------------------------------------- Reporter: int-index | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.2 Resolution: duplicate | Keywords: poly- | kinded, Const Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by int-index): * status: new => closed * resolution: => duplicate -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 17 17:36:20 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Sep 2015 17:36:20 -0000 Subject: [GHC] #10877: x86_64: dll-split: out of memory (requested 1099512676352 bytes) In-Reply-To: <050.ab3ee9d3ff60499476bc10d829ff13d9@haskell.org> References: <050.ab3ee9d3ff60499476bc10d829ff13d9@haskell.org> Message-ID: <065.f2de868674d8b5d484c4d3761ff18f3b@haskell.org> #10877: x86_64: dll-split: out of memory (requested 1099512676352 bytes) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: #10682 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by RyanGlScott): Tell me if you want more specific distro info than this: {{{ $ uname -a Linux tank.soic.indiana.edu 3.10.0-229.11.1.el7.x86_64 #1 SMP Wed Jul 22 12:06:11 EDT 2015 x86_64 x86_64 x86_64 GNU/Linux $ cat /etc/redhat-release Red Hat Enterprise Linux Server release 7.1 (Maipo) $ cat /proc/meminfo MemTotal: 263928412 kB MemFree: 52989964 kB MemAvailable: 167374740 kB Buffers: 3540 kB Cached: 109364396 kB SwapCached: 52700 kB Active: 143228364 kB Inactive: 59588436 kB Active(anon): 87890144 kB Inactive(anon): 5694784 kB Active(file): 55338220 kB Inactive(file): 53893652 kB Unevictable: 32 kB Mlocked: 32 kB SwapTotal: 134217724 kB SwapFree: 134030536 kB Dirty: 28 kB Writeback: 0 kB AnonPages: 93435332 kB Mapped: 203232 kB Shmem: 136064 kB Slab: 5871708 kB SReclaimable: 5490788 kB SUnreclaim: 380920 kB KernelStack: 18336 kB PageTables: 230584 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 266181928 kB Committed_AS: 101990088 kB VmallocTotal: 34359738367 kB VmallocUsed: 720588 kB VmallocChunk: 34224804536 kB HardwareCorrupted: 0 kB AnonHugePages: 92712960 kB HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 2048 kB DirectMap4k: 310208 kB DirectMap2M: 59412480 kB DirectMap1G: 210763776 kB }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 17 17:53:41 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Sep 2015 17:53:41 -0000 Subject: [GHC] #10891: `reify` doesn't find associated type families Message-ID: <046.9e704f075dee9514291b5d5766834bf9@haskell.org> #10891: `reify` doesn't find associated type families -------------------------------------+------------------------------------- Reporter: antalsz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.10.2 Haskell | Keywords: template | Operating System: Unknown/Multiple haskell; type families | Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Template Haskell's `reify` doesn't find the the associated type families of a type class. Consider the following two classes: {{{#!hs class C a where f :: a -> Int class C' a where type F a :: * f' :: a -> Int }}} These produce identical, up to renaming, output when passed to `reify`: {{{#!hs -- putStrLn $(stringE . show =<< reify ''C) ClassI (ClassD [] Ghci1.C [PlainTV a_1627398388] [] [SigD Ghci1.f (ForallT [PlainTV a_1627398388] [ClassP Ghci1.C [VarT a_1627398388]] (AppT (AppT ArrowT (VarT a_1627398388)) (ConT GHC.Types.Int)))]) [] -- putStrLn $(stringE . show =<< reify ''C') ClassI (ClassD [] Ghci3.C' [PlainTV a_1627405973] [] [SigD Ghci3.f' (ForallT [PlainTV a_1627405973] [ClassP Ghci3.C' [VarT a_1627405973]] (AppT (AppT ArrowT (VarT a_1627405973)) (ConT GHC.Types.Int)))]) [] }}} If I know the name of `F`, I can look up information about it: {{{!#hs -- putStrLn $(stringE . show =<< reify ''F) FamilyI (FamilyD TypeFam Ghci3.F [PlainTV a_1627405973] (Just StarT)) [] }}} But I can't find the name of `F` in the first place. Even if I add an instance of the type class, the `InstanceD` has none of the information about the definition. Given {{{#!hs instance C' [a] where type F [a] = a f' = length }}} we get {{{#!hs -- putStrLn $(stringE . show =<< reify ''C') ClassI (ClassD [] Ghci3.C' [PlainTV a_1627405973] [] [SigD Ghci3.f' (ForallT [PlainTV a_1627405973] [ClassP Ghci3.C' [VarT a_1627405973]] (AppT (AppT ArrowT (VarT a_1627405973)) (ConT GHC.Types.Int)))]) [InstanceD [] (AppT (ConT Ghci3.C') (AppT ListT (VarT a_1627406161))) []] }}} This problem was confirmed to exist in the following configurations: * GHC 7.10.2 with version 2.10.0.0 of the template-haskell package. * GHC 7.8.3 with version 2.9.0.0 of the template-haskell package. * GHC 7.4.2 with version 2.7.0.0 of the template-haskell package. (I also posted this on Stack Overflow in //2013//, where it has been languishing ever since: http://stackoverflow.com/q/17247880/237428.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 17 18:03:56 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Sep 2015 18:03:56 -0000 Subject: [GHC] #10514: Generic for existential types In-Reply-To: <051.d185121bcf194fc1021cab90b66f9d08@haskell.org> References: <051.d185121bcf194fc1021cab90b66f9d08@haskell.org> Message-ID: <066.1a2b1729db397aa3ad5d1ea9c9c52494@haskell.org> #10514: Generic for existential types -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by dreixel): I might be wrong, but I don't think there's any hope for supporting existentials with the current approach of `GHC.Generics` (especially when their kind is `*` and they show up as arguments to constructors). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 17 18:06:56 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Sep 2015 18:06:56 -0000 Subject: [GHC] #10891: `reify` doesn't find associated type families In-Reply-To: <046.9e704f075dee9514291b5d5766834bf9@haskell.org> References: <046.9e704f075dee9514291b5d5766834bf9@haskell.org> Message-ID: <061.aac86c422c1c0f8a01e6cdc7b9fdd434@haskell.org> #10891: `reify` doesn't find associated type families -------------------------------------+------------------------------------- Reporter: antalsz | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: type | families; newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * keywords: template haskell; type families => type families; newcomer * milestone: => 8.0.1 Comment: Well, that's silly. My guess, without looking at the code, that this could be fixed in 2-3 lines. Newcomers? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 17 18:08:32 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Sep 2015 18:08:32 -0000 Subject: [GHC] #10872: More informative assertion for non-unique TH names In-Reply-To: <048.31528093886b2ab66084097b2ba3a854@haskell.org> References: <048.31528093886b2ab66084097b2ba3a854@haskell.org> Message-ID: <063.17b09a348ec24c2d69c1afdac2db3ac0@haskell.org> #10872: More informative assertion for non-unique TH names -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: task | Status: new Priority: low | Milestone: 8.0.1 Component: Template Haskell | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * component: Compiler => Template Haskell * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 17 18:19:42 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Sep 2015 18:19:42 -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.df0d264febab1f54f408b9ec5a10fc27@haskell.org> #9912: Allow access to full logs in Harbormaster builds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: | thoughtpolice Type: bug | Status: closed Priority: normal | Milestone: Component: Trac & Git | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Why can't we just have no limit? Or an option to download the original log? Though I don't have a concrete example, I think 1000 is way too small, given that there are almost 5000 test cases. If an early one fails, we won't be able to see the failure output. (This is //not// to suggest that 5000 would be a good limit, a priori. Does each test case use only one line of output?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 17 18:23:10 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Sep 2015 18:23:10 -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.47cda0c607ece84caebc8ff18aae3e77@haskell.org> #9912: Allow access to full logs in Harbormaster builds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: | thoughtpolice Type: bug | Status: closed Priority: normal | Milestone: Component: Trac & Git | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): Ask thoughtpolice. Something about Phabricator putting the logfile in a database record. But only tests that fail produce output (Phabricator calls `make test VERBOSE=1`), so unless you have 5000 failing test cases, you should be ok. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 17 18:37:38 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Sep 2015 18:37:38 -0000 Subject: [GHC] #10751: Implement Phase 1 of MonadFail Proposal (MFP) In-Reply-To: <042.af0b8689bcfac4a130648c64d759a4c0@haskell.org> References: <042.af0b8689bcfac4a130648c64d759a4c0@haskell.org> Message-ID: <057.9da7e0d494b86aba7295cdb18f480cae@haskell.org> #10751: Implement Phase 1 of MonadFail Proposal (MFP) -------------------------------------+------------------------------------- Reporter: hvr | Owner: quchen Type: task | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: report- | impact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1248 -------------------------------------+------------------------------------- Comment (by goldfire): Sorry for coming to the party late, but is there an up-to-date proposal I could read here? The link in the original post goes to a reddit page, which has links to an "original propsal" and an "update 1", both of which seem to have open questions, and neither of which are editable. I don't have any objections -- just trying to stay informed. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 17 18:39:45 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Sep 2015 18:39:45 -0000 Subject: [GHC] #10514: Generic for existential types In-Reply-To: <051.d185121bcf194fc1021cab90b66f9d08@haskell.org> References: <051.d185121bcf194fc1021cab90b66f9d08@haskell.org> Message-ID: <066.9027ed102a43d7bda463e91723416073@haskell.org> #10514: Generic for existential types -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Something tells me this is an open research problem... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 17 18:40:34 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Sep 2015 18:40:34 -0000 Subject: [GHC] #10514: Generic for existential types In-Reply-To: <051.d185121bcf194fc1021cab90b66f9d08@haskell.org> References: <051.d185121bcf194fc1021cab90b66f9d08@haskell.org> Message-ID: <066.b6b27a0763367c7c4577a1bf031ab15d@haskell.org> #10514: Generic for existential types -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8560 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * related: => #8560 Comment: See also #8560 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 17 18:43:21 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Sep 2015 18:43:21 -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.2c3b479d1ccd8a6d056a00ccdb80dc41@haskell.org> #9912: Allow access to full logs in Harbormaster builds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: | thoughtpolice Type: bug | Status: closed Priority: normal | Milestone: Component: Trac & Git | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Ah. That's a bit better than. 1000 might indeed be enough. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 17 18:54:49 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Sep 2015 18:54:49 -0000 Subject: [GHC] #10751: Implement Phase 1 of MonadFail Proposal (MFP) In-Reply-To: <042.af0b8689bcfac4a130648c64d759a4c0@haskell.org> References: <042.af0b8689bcfac4a130648c64d759a4c0@haskell.org> Message-ID: <057.d313d994365bd8c1961ef4470f159b8c@haskell.org> #10751: Implement Phase 1 of MonadFail Proposal (MFP) -------------------------------------+------------------------------------- Reporter: hvr | Owner: quchen Type: task | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: report- | impact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1248 -------------------------------------+------------------------------------- Comment (by quchen): Discussion of the initial proposal went pretty dead soon, and there was close to no response for the update, so we left it at that (considering the few suggestions we got and that people actually cared about) and fleshed it out on IRC. We modified the transitional strategy based on what we had a bit, and it's in https://github.com/quchen/articles/blob/master/monad_fail.md#transitional- strategy, which is what I'm implementing right now. Objections like the purpose of failure - such exception vs. error state - are orthogonal to the proposal, whose main goal by a huge margin is getting fail out of Monad. We can revisit such issues when MonadFail is established, e.g. by adding a new function to the MonadFail class that is called by the compiler, and one that's supposed to be used by the users explicitly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 17 21:55:39 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Sep 2015 21:55:39 -0000 Subject: [GHC] #10891: `reify` doesn't find associated type families In-Reply-To: <046.9e704f075dee9514291b5d5766834bf9@haskell.org> References: <046.9e704f075dee9514291b5d5766834bf9@haskell.org> Message-ID: <061.a58cb74aa45382bf578079e1cdfdef8c@haskell.org> #10891: `reify` doesn't find associated type families -------------------------------------+------------------------------------- Reporter: antalsz | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: type | families; newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by osa1: Old description: > Template Haskell's `reify` doesn't find the the associated type families > of a type class. Consider the following two classes: > > {{{#!hs > class C a where > f :: a -> Int > > class C' a where > type F a :: * > f' :: a -> Int > }}} > > These produce identical, up to renaming, output when passed to `reify`: > > {{{#!hs > -- putStrLn $(stringE . show =<< reify ''C) > ClassI (ClassD [] Ghci1.C [PlainTV a_1627398388] [] > [SigD Ghci1.f > (ForallT [PlainTV a_1627398388] > [ClassP Ghci1.C [VarT a_1627398388]] > (AppT (AppT ArrowT (VarT a_1627398388)) > (ConT GHC.Types.Int)))]) > [] > > -- putStrLn $(stringE . show =<< reify ''C') > ClassI (ClassD [] Ghci3.C' [PlainTV a_1627405973] [] > [SigD Ghci3.f' > (ForallT [PlainTV a_1627405973] > [ClassP Ghci3.C' [VarT a_1627405973]] > (AppT (AppT ArrowT (VarT a_1627405973)) > (ConT GHC.Types.Int)))]) > [] > }}} > > If I know the name of `F`, I can look up information about it: > > {{{!#hs > -- putStrLn $(stringE . show =<< reify ''F) > FamilyI (FamilyD TypeFam > Ghci3.F > [PlainTV a_1627405973] > (Just StarT)) > [] > }}} > > But I can't find the name of `F` in the first place. Even if I add an > instance of the type class, the `InstanceD` has none of the information > about the definition. Given > > {{{#!hs > instance C' [a] where > type F [a] = a > f' = length > }}} > > we get > > {{{#!hs > -- putStrLn $(stringE . show =<< reify ''C') > ClassI (ClassD [] Ghci3.C' [PlainTV a_1627405973] [] > [SigD Ghci3.f' > (ForallT [PlainTV a_1627405973] > [ClassP Ghci3.C' [VarT a_1627405973]] > (AppT (AppT ArrowT (VarT a_1627405973)) > (ConT GHC.Types.Int)))]) > [InstanceD [] > (AppT (ConT Ghci3.C') > (AppT ListT (VarT a_1627406161))) > []] > }}} > > This problem was confirmed to exist in the following configurations: > > * GHC 7.10.2 with version 2.10.0.0 of the template-haskell package. > * GHC 7.8.3 with version 2.9.0.0 of the template-haskell package. > * GHC 7.4.2 with version 2.7.0.0 of the template-haskell package. > > (I also posted this on Stack Overflow in //2013//, where it has been > languishing ever since: http://stackoverflow.com/q/17247880/237428.) New description: Template Haskell's `reify` doesn't find the the associated type families of a type class. Consider the following two classes: {{{#!hs class C a where f :: a -> Int class C' a where type F a :: * f' :: a -> Int }}} These produce identical, up to renaming, output when passed to `reify`: {{{#!hs -- putStrLn $(stringE . show =<< reify ''C) ClassI (ClassD [] Ghci1.C [PlainTV a_1627398388] [] [SigD Ghci1.f (ForallT [PlainTV a_1627398388] [ClassP Ghci1.C [VarT a_1627398388]] (AppT (AppT ArrowT (VarT a_1627398388)) (ConT GHC.Types.Int)))]) [] -- putStrLn $(stringE . show =<< reify ''C') ClassI (ClassD [] Ghci3.C' [PlainTV a_1627405973] [] [SigD Ghci3.f' (ForallT [PlainTV a_1627405973] [ClassP Ghci3.C' [VarT a_1627405973]] (AppT (AppT ArrowT (VarT a_1627405973)) (ConT GHC.Types.Int)))]) [] }}} If I know the name of `F`, I can look up information about it: {{{#!hs -- putStrLn $(stringE . show =<< reify ''F) FamilyI (FamilyD TypeFam Ghci3.F [PlainTV a_1627405973] (Just StarT)) [] }}} But I can't find the name of `F` in the first place. Even if I add an instance of the type class, the `InstanceD` has none of the information about the definition. Given {{{#!hs instance C' [a] where type F [a] = a f' = length }}} we get {{{#!hs -- putStrLn $(stringE . show =<< reify ''C') ClassI (ClassD [] Ghci3.C' [PlainTV a_1627405973] [] [SigD Ghci3.f' (ForallT [PlainTV a_1627405973] [ClassP Ghci3.C' [VarT a_1627405973]] (AppT (AppT ArrowT (VarT a_1627405973)) (ConT GHC.Types.Int)))]) [InstanceD [] (AppT (ConT Ghci3.C') (AppT ListT (VarT a_1627406161))) []] }}} This problem was confirmed to exist in the following configurations: * GHC 7.10.2 with version 2.10.0.0 of the template-haskell package. * GHC 7.8.3 with version 2.9.0.0 of the template-haskell package. * GHC 7.4.2 with version 2.7.0.0 of the template-haskell package. (I also posted this on Stack Overflow in //2013//, where it has been languishing ever since: http://stackoverflow.com/q/17247880/237428.) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 17 22:07:27 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Sep 2015 22:07:27 -0000 Subject: [GHC] #10890: Incorrect redundant import warning for type classes In-Reply-To: <045.1d7793ff19c595f6fc025366df90cb33@haskell.org> References: <045.1d7793ff19c595f6fc025366df90cb33@haskell.org> Message-ID: <060.62989cc52655c579e35061debd3da962@haskell.org> #10890: Incorrect redundant import warning for type classes -------------------------------------+------------------------------------- Reporter: quchen | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by osa1): * cc: osa1 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 17 22:07:59 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Sep 2015 22:07:59 -0000 Subject: [GHC] #10751: Implement Phase 1 of MonadFail Proposal (MFP) In-Reply-To: <042.af0b8689bcfac4a130648c64d759a4c0@haskell.org> References: <042.af0b8689bcfac4a130648c64d759a4c0@haskell.org> Message-ID: <057.204a1db212cb5e98d77311b2d81c69ec@haskell.org> #10751: Implement Phase 1 of MonadFail Proposal (MFP) -------------------------------------+------------------------------------- Reporter: hvr | Owner: quchen Type: task | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: report- | impact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1248 -------------------------------------+------------------------------------- Changes (by simonpj): * cc: core-libraries-committee, ekmett (added) Comment: Just to be clear, this is a Core Libraries Committee matter, so whatever the proposal is, it should be signed off by them. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 17 22:37:57 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Sep 2015 22:37:57 -0000 Subject: [GHC] #10375: arm: ghci hits an illegal instruction In-Reply-To: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> References: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> Message-ID: <059.27382429eac5f4bfffce643b6a0ce641@haskell.org> #10375: arm: ghci hits an illegal instruction -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: Runtime System | Version: 7.10.1 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by erikd): Turns out the memory region its trying to execute is not actually code. Hex dump is: {{{ b6ff0000: 0000 0000 3300 0000 0800 ffb6 0800 0000 ....3........... b6ff0010: 0000 0100 0100 0000 4900 4708 f0cd e601 ........I.G..... b6ff0020: 696e 7465 7261 6374 6976 653a 4768 6369 interactive:Ghci b6ff0030: 312e 5800 3300 0000 3800 ffb6 0800 0000 1.X.3...8....... b6ff0040: 0000 0100 0100 0100 4900 4708 f0cd e601 ........I.G..... b6ff0050: 696e 7465 7261 6374 6976 653a 4768 6369 interactive:Ghci b6ff0060: 312e 5900 790f 0000 6800 ffb6 0f00 2de9 1.Y.y...h.....-. b6ff0070: 0000 9fe5 00f0 9fe5 6c00 ffb6 cceb e801 ........l....... }}} and the instruction that segfaults is at 0xb6ff0024. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 17 23:00:39 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Sep 2015 23:00:39 -0000 Subject: [GHC] #10890: Incorrect redundant import warning for type classes In-Reply-To: <045.1d7793ff19c595f6fc025366df90cb33@haskell.org> References: <045.1d7793ff19c595f6fc025366df90cb33@haskell.org> Message-ID: <060.ace0d2273613fbaf928929e5cbc43175@haskell.org> #10890: Incorrect redundant import warning for type classes -------------------------------------+------------------------------------- Reporter: quchen | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by osa1): Not sure how much this helps with debugging this, but I found out that when compiling this slightly modified program: {{{#!haskell module Main where import Base (AClass (has)) import Extends (BClass (has)) data Bar = Bar instance AClass Bar where has = Bar instance BClass Bar where has = Bar }}} GHC prints this: {{{ Main.hs:3:1: warning: The import of ?Base.has? from module ?Base? is redundant Main.hs:4:1: warning: The import of ?Extends.has? from module ?Extends? is redundant Linking Main ... }}} This is a test case I generated while trying to figure out if GHC thinks both `has` are coming from the same module. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 17 23:16:01 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Sep 2015 23:16:01 -0000 Subject: [GHC] #10879: base is not included in the haddock index In-Reply-To: <048.8713266ddcd63f131d79fa94bba781e8@haskell.org> References: <048.8713266ddcd63f131d79fa94bba781e8@haskell.org> Message-ID: <063.27dd32e0ff473022dd7b65042185d481@haskell.org> #10879: base is not included in the haddock index -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1247 -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"48746fff87f79a3c7cc128816f9e84bf4e578445/ghc" 48746ff/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="48746fff87f79a3c7cc128816f9e84bf4e578445" Docs: make sure all libs are included in index.html (#10879) During the build, when HADDOCK_DOCS=YES, the command 'cd libraries && sh gen_contents_index --intree' is run, which calls haddock to generate the haddock index at 'libraries/dist-haddock/index.html'. What it did before was check the ./packages file for all libraries. The problem is that 'base' and 'ghc-prim' were folded into the main repo some time ago, hence don't have an entry in the ./packages file anymore. As a result, 'base' and 'ghc-prim' were missing from the index.html file. It now simply runs haddock on all the all the `.haddock` files in the libraries directory. The only risk is that this could include the extra libraries in the index.html, if you ever built them in the past (with BUILD_EXTRA_PKGS=YES), even though now you want to exclude them (with BUILD_EXTRA_PKGS=NO). gen_contents_index doesn't have access to build system variables though (PACKAGES_STAGE1+PACKAGES_STAGE2), so fixing this would be a little bit fiddly. Test Plan: 'make libraries/dist-haddock/index.html && grep -q base libraries/dist-haddock/index.html && echo ok' Reviewed by: austin Differential Revision: https://phabricator.haskell.org/D1247 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 17 23:18:15 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Sep 2015 23:18:15 -0000 Subject: [GHC] #10879: base is not included in the haddock index In-Reply-To: <048.8713266ddcd63f131d79fa94bba781e8@haskell.org> References: <048.8713266ddcd63f131d79fa94bba781e8@haskell.org> Message-ID: <063.a472eaff351825ab1ddeb3ba5215fd33@haskell.org> #10879: base is not included in the haddock index -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.3 Component: Build System | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1247 -------------------------------------+------------------------------------- Changes (by thomie): * status: new => merge * milestone: 8.0.1 => 7.10.3 Comment: Should be fixed in the next release. Thanks for the report. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 18 00:23:28 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Sep 2015 00:23:28 -0000 Subject: [GHC] #10890: Incorrect redundant import warning for type classes In-Reply-To: <045.1d7793ff19c595f6fc025366df90cb33@haskell.org> References: <045.1d7793ff19c595f6fc025366df90cb33@haskell.org> Message-ID: <060.5edbeb789e132c9eccca24ebb3b95fb5@haskell.org> #10890: Incorrect redundant import warning for type classes -------------------------------------+------------------------------------- Reporter: quchen | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by osa1): This is awesome, just re-order imports like this: {{{#!haskell import Extends import Base }}} and GHC doesn't print the warning anymore :) I'm about to solve this case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 18 00:33:55 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Sep 2015 00:33:55 -0000 Subject: [GHC] #10375: arm: ghci hits an illegal instruction In-Reply-To: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> References: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> Message-ID: <059.6095e60e4e79a5b9e6c3f7dbb9b19097@haskell.org> #10375: arm: ghci hits an illegal instruction -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: Runtime System | Version: 7.10.1 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by erikd): Now back to same situation as comment:8 and comment:11. I have a statically built `ghc-stage2` binary that segfaults. Going to try two things: * Port previous fix that disables Thumb instructions back to ghc-7.10 branch. * Try disabling SMP on master branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 18 02:46:24 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Sep 2015 02:46:24 -0000 Subject: [GHC] #10890: Incorrect redundant import warning for type classes In-Reply-To: <045.1d7793ff19c595f6fc025366df90cb33@haskell.org> References: <045.1d7793ff19c595f6fc025366df90cb33@haskell.org> Message-ID: <060.bf7d86e327ebe1fab86908ee639d1d68@haskell.org> #10890: Incorrect redundant import warning for type classes -------------------------------------+------------------------------------- Reporter: quchen | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by osa1): Here's more stuff: GHC actually doesn't even consider `has` as an used symbol(i.e. internally it doesn't add it to the set of symbols used in a module, `tcg_used_rdrnames` of `TcGblEnv`), so in this case it only considers importing `AClass` and `BClass`. (that why in my second example it prints warnings about both `has`) `BClass` is exported by both `Base` and `Extends`. Now let's say we have this: {{{#!haskell import Base import Extends }}} Which one should be used for importing `BClass`? GHC makes the choice based on their locations in the source file. That is, it imports it from `Base` and not from `Extends`. But if I change imports like this: {{{#!haskell import Extends import Base }}} Now GHC imports `BClass` from `Extends` because it comes first in the source code, so no warnings here. Long story short, I think the problem is that GHC doesn't consider `has` a used symbol. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 18 03:35:41 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Sep 2015 03:35:41 -0000 Subject: [GHC] #10890: Incorrect redundant import warning for type classes In-Reply-To: <045.1d7793ff19c595f6fc025366df90cb33@haskell.org> References: <045.1d7793ff19c595f6fc025366df90cb33@haskell.org> Message-ID: <060.f3eaa5008cbf3facd1563acf7f77b9de@haskell.org> #10890: Incorrect redundant import warning for type classes -------------------------------------+------------------------------------- Reporter: quchen | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by osa1): Not sure how to proceed here but I have an experimental patch https://github.com/osa1/ghc/commit/d8647e1ae28be98554b4976ab1c4bc275b3c280b. Does anyone have any ideas? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 18 04:45:58 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Sep 2015 04:45:58 -0000 Subject: [GHC] #10580: rejected emails for Trac registrations from https://ghc.haskell.org/trac/haskell-prime In-Reply-To: <042.fca6bf75ceadc97246c14a092e17cda4@haskell.org> References: <042.fca6bf75ceadc97246c14a092e17cda4@haskell.org> Message-ID: <057.f81b09bd1dd82ec7f95c27caa6ecd789@haskell.org> #10580: rejected emails for Trac registrations from https://ghc.haskell.org/trac /haskell-prime -------------------------------------+------------------------------------- Reporter: imz | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by gershomb): Callback verification is somewhat controversial: https://en.wikipedia.org/wiki/Callback_verification In any case, what I suspect is happening is just that the mail is not sent from a "real account name" and if we added a real account recipient with the name that the mail is sent from, then this would work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 18 05:22:06 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Sep 2015 05:22:06 -0000 Subject: [GHC] #10375: arm: ghci hits an illegal instruction In-Reply-To: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> References: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> Message-ID: <059.f28ee8e65cda58fdee45f7c36ed9250c@haskell.org> #10375: arm: ghci hits an illegal instruction -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: Runtime System | Version: 7.10.1 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by erikd): Results of previous experiments: * On ghc-7.20 branch, GHCi with Thumb code disabled still crashes. * On master branch, with SMP disabled, GHCi still crashes. Should probably continue working on master branch with SMP disabled. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 18 07:59:37 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Sep 2015 07:59:37 -0000 Subject: [GHC] #10829: Simplification in the RHS of rules In-Reply-To: <046.7ca7c028ab82ec2d7ad263cb88680067@haskell.org> References: <046.7ca7c028ab82ec2d7ad263cb88680067@haskell.org> Message-ID: <061.73fd1358d4ddc75a14da52922ce7c516@haskell.org> #10829: Simplification in the RHS of rules -------------------------------------+------------------------------------- Reporter: afarmer | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10528 | Differential Revisions: Phab:D1246 -------------------------------------+------------------------------------- Comment (by bgamari): Someone correct me if I'm wrong but it seems like this change carries a bit of risk: Could this not result in a failure in optimization in a library with incorrect phasing annotations? We should definitely check this against Stackage or some similar smoke-test to ensure that libraries with incorrect phasing aren't adversely affected by this change as I don't have much confidence that such a regression would appear in nofib (as we've already seen in the case of `text`). Also, have we looked for Core changes that might explain the regressions seen in comment:6? The runtime regressions shown look as though they may be real; it would be nice to have at least some idea of what is happening here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 18 08:25:45 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Sep 2015 08:25:45 -0000 Subject: [GHC] #10892: ApplicativeDo should use *> and <* Message-ID: <047.75544cc852e1b71af89f5571354ace9a@haskell.org> #10892: ApplicativeDo should use *> and <* -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- From @ekmett: Would it be possible to tweak the generation to use `(<*)` or `(*>)` where appropriate when the result isn't being used? For many Applicatives this can be a massive asymptotic win in terms of sharing and/or computational cost. When desugaring using (<*) you'd just omit any handling of the unused result instead. {{{ (\x y -> ...) <$> foo <* bar <*> baz }}} corresponds to {{{ do x <- foo bar y <- baz return ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 18 08:47:18 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Sep 2015 08:47:18 -0000 Subject: [GHC] #7259: Eta expansion of products in System FC In-Reply-To: <046.eb91fb12bdf35396d79679c78f7a6c38@haskell.org> References: <046.eb91fb12bdf35396d79679c78f7a6c38@haskell.org> Message-ID: <061.322fbb47ba93fde56e076e30d32ecc51@haskell.org> #7259: Eta expansion of products in System FC -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by jstolarek): * cc: jstolarek (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 18 08:48:50 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Sep 2015 08:48:50 -0000 Subject: [GHC] #8832: Constant-folding regression wrt `clearBit (bit 0) 0 ` In-Reply-To: <042.89bb0eec284b44a45a7b0586c22bb7a4@haskell.org> References: <042.89bb0eec284b44a45a7b0586c22bb7a4@haskell.org> Message-ID: <057.357cad612cd6671aaa1785794acf52f3@haskell.org> #8832: Constant-folding regression wrt `clearBit (bit 0) 0 ` -------------------------------------+------------------------------------- Reporter: hvr | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Core Libraries | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | simplCore/should_compile/T8832 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by jstolarek): * cc: jstolarek (removed) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 18 08:54:03 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Sep 2015 08:54:03 -0000 Subject: [GHC] #849: Offer control over branch prediction In-Reply-To: <046.9c1a3dec0191543ee72b98b43c5f5f89@haskell.org> References: <046.9c1a3dec0191543ee72b98b43c5f5f89@haskell.org> Message-ID: <061.f81de39e30f71840e58ed7beba375ad7@haskell.org> #849: Offer control over branch prediction -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 6.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by jstolarek): * cc: jan.stolarek@? (removed) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 18 08:55:31 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Sep 2015 08:55:31 -0000 Subject: [GHC] #10893: Consistent error message suggestions for using language extensions Message-ID: <042.d717259da71a4197660845c46c0800a9@haskell.org> #10893: Consistent error message suggestions for using language extensions -------------------------------------+------------------------------------- Reporter: spl | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- I saw this error today in 7.10.2: {{{ Parse error: naked expression at top level Perhaps you intended to use TemplateHaskell }}} I'm glad it suggests using !TemplateHaskell; however, the suggestion seems incomplete. I did in fact intend to use Template Haskell, but I think this suggestion implies the ''language extension'' though it doesn't explicitly say so. I believe other error message suggestions are more explicit about mentioning language extension, e.g. {{{use -XFlexibleContexts}}}, which refers to the flag. I'm just bringing this issue up to request a consistent error message suggestion format for language extensions that explicitly mentions ?language extension??or {{{-X}}}. (It may be that the above message is the only one not doing that; I haven't checked.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 18 08:57:04 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Sep 2015 08:57:04 -0000 Subject: [GHC] #10893: Consistent error message suggestions for using language extensions In-Reply-To: <042.d717259da71a4197660845c46c0800a9@haskell.org> References: <042.d717259da71a4197660845c46c0800a9@haskell.org> Message-ID: <057.ab9a8dc9bc96849028d8498805b40fbd@haskell.org> #10893: Consistent error message suggestions for using language extensions -------------------------------------+------------------------------------- Reporter: spl | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by spl): * version: 7.10.2 => 7.11 Old description: > I saw this error today in 7.10.2: > > {{{ > Parse error: naked expression at top level > Perhaps you intended to use TemplateHaskell > }}} > > I'm glad it suggests using !TemplateHaskell; however, the suggestion > seems incomplete. I did in fact intend to use Template Haskell, but I > think this suggestion implies the ''language extension'' though it > doesn't explicitly say so. > > I believe other error message suggestions are more explicit about > mentioning language extension, e.g. {{{use -XFlexibleContexts}}}, which > refers to the flag. > > I'm just bringing this issue up to request a consistent error message > suggestion format for language extensions that explicitly mentions > ?language extension??or {{{-X}}}. (It may be that the above message is > the only one not doing that; I haven't checked.) New description: I saw this error today in 7.10.1: {{{ Parse error: naked expression at top level Perhaps you intended to use TemplateHaskell }}} I'm glad it suggests using !TemplateHaskell; however, the suggestion seems incomplete. I did in fact intend to use Template Haskell, but I think this suggestion implies the ''language extension'' though it doesn't explicitly say so. I believe other error message suggestions are more explicit about mentioning language extension, e.g. {{{use -XFlexibleContexts}}}, which refers to the flag. I'm just bringing this issue up to request a consistent error message suggestion format for language extensions that explicitly mentions ?language extension??or {{{-X}}}. (It may be that the above message is the only one not doing that; I haven't checked.) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 18 08:59:36 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Sep 2015 08:59:36 -0000 Subject: [GHC] #849: Offer control over branch prediction In-Reply-To: <046.9c1a3dec0191543ee72b98b43c5f5f89@haskell.org> References: <046.9c1a3dec0191543ee72b98b43c5f5f89@haskell.org> Message-ID: <061.1ad5de55552fa3587c5f4691ce74d650@haskell.org> #849: Offer control over branch prediction -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 6.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonmar): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 18 09:00:07 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Sep 2015 09:00:07 -0000 Subject: [GHC] #10893: Consistent error message suggestions for using language extensions In-Reply-To: <042.d717259da71a4197660845c46c0800a9@haskell.org> References: <042.d717259da71a4197660845c46c0800a9@haskell.org> Message-ID: <057.72d1e68fcf289c9ff1a4bac1f7c1c703@haskell.org> #10893: Consistent error message suggestions for using language extensions -------------------------------------+------------------------------------- Reporter: spl | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * cc: nomeata (added) Old description: > I saw this error today in 7.10.1: > > {{{ > Parse error: naked expression at top level > Perhaps you intended to use TemplateHaskell > }}} > > I'm glad it suggests using !TemplateHaskell; however, the suggestion > seems incomplete. I did in fact intend to use Template Haskell, but I > think this suggestion implies the ''language extension'' though it > doesn't explicitly say so. > > I believe other error message suggestions are more explicit about > mentioning language extension, e.g. {{{use -XFlexibleContexts}}}, which > refers to the flag. > > I'm just bringing this issue up to request a consistent error message > suggestion format for language extensions that explicitly mentions > ?language extension??or {{{-X}}}. (It may be that the above message is > the only one not doing that; I haven't checked.) New description: I saw this error today in 7.10.1: {{{ Parse error: naked expression at top level Perhaps you intended to use TemplateHaskell }}} I'm glad it suggests using !TemplateHaskell; however, the suggestion seems incomplete. I did in fact intend to use Template Haskell, but I think this suggestion implies the ''language extension'' though it doesn't explicitly say so. I believe other error message suggestions are more explicit about mentioning language extension, e.g. {{{use -XFlexibleContexts}}}, which refers to the flag. I'm just bringing this issue up to request a consistent error message suggestion format for language extensions that explicitly mentions ?language extension??or {{{-X}}}. (It may be that the above message is the only one not doing that; I haven't checked.) -- Comment: See #3647 for why `-X` was removed from error messages. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 18 09:00:41 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Sep 2015 09:00:41 -0000 Subject: [GHC] #7378: Identical alts/bad divInt# code In-Reply-To: <056.22cc8de2dae750ab03e1570e152919d7@haskell.org> References: <056.22cc8de2dae750ab03e1570e152919d7@haskell.org> Message-ID: <071.7506d50648a890601f9b919220a5a0ed@haskell.org> #7378: Identical alts/bad divInt# code -------------------------------------+------------------------------------- Reporter: | Owner: daniel.is.fischer | Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #7360, #2132 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by jstolarek): * related: 7360 => #7360, #2132 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 18 09:01:06 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Sep 2015 09:01:06 -0000 Subject: [GHC] #2132: Optimise nested comparisons In-Reply-To: <046.ba0b25228872b80f2daed8d0d0f8352f@haskell.org> References: <046.ba0b25228872b80f2daed8d0d0f8352f@haskell.org> Message-ID: <061.e2a2227eb95c0afbe0b5a543f579b510@haskell.org> #2132: Optimise nested comparisons -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: 6.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by jstolarek): * cc: jan.stolarek@? (removed) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 18 09:01:41 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Sep 2015 09:01:41 -0000 Subject: [GHC] #4259: Relax restrictions on type family instance overlap In-Reply-To: <044.e5eb645c3ea4a197b93ff685f55f7550@haskell.org> References: <044.e5eb645c3ea4a197b93ff685f55f7550@haskell.org> Message-ID: <059.1d1b3b4a047b25308b30136a79a6f2b3@haskell.org> #4259: Relax restrictions on type family instance overlap -------------------------------------+------------------------------------- Reporter: lilac | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 6.12.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8423 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by jstolarek): * cc: jan.stolarek@? (removed) * cc: jstolarek (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 18 09:02:08 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Sep 2015 09:02:08 -0000 Subject: [GHC] #5567: LLVM: Improve alias analysis / performance In-Reply-To: <045.d9bd466c3bfd8b5c182f7fd75463d86a@haskell.org> References: <045.d9bd466c3bfd8b5c182f7fd75463d86a@haskell.org> Message-ID: <060.83012dffb77aae0fa26632d4f388d93c@haskell.org> #5567: LLVM: Improve alias analysis / performance -------------------------------------+------------------------------------- Reporter: dterei | Owner: dterei Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (LLVM) | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by jstolarek): * cc: jan.stolarek@? (removed) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 18 09:03:16 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Sep 2015 09:03:16 -0000 Subject: [GHC] #7828: RebindableSyntax and Arrow In-Reply-To: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> References: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> Message-ID: <073.34018219c1868c8dc6c45d5e78938e7d@haskell.org> #7828: RebindableSyntax and Arrow -------------------------------------+------------------------------------- Reporter: | Owner: AlessandroVermeulen | Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.6.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #1537, #3613 | Differential Revisions: Phab:D72 -------------------------------------+------------------------------------- Changes (by jstolarek): * cc: jan.stolarek@? (removed) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 18 09:05:04 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Sep 2015 09:05:04 -0000 Subject: [GHC] #7961: Remove restrictions on promoting GADT's In-Reply-To: <047.d0069eb42fb0ed6b29e5044acfcdabb7@haskell.org> References: <047.d0069eb42fb0ed6b29e5044acfcdabb7@haskell.org> Message-ID: <062.d4543bc4415805dbc13e366cc35f6fb4@haskell.org> #7961: Remove restrictions on promoting GADT's -------------------------------------+------------------------------------- Reporter: danharaj | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #6024 | Differential Revisions: Phab:D808 -------------------------------------+------------------------------------- Changes (by jstolarek): * cc: jan.stolarek@? (removed) * cc: jstolarek (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 18 09:05:29 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Sep 2015 09:05:29 -0000 Subject: [GHC] #8048: Register spilling produces ineffecient/highly contending code In-Reply-To: <046.812a6c0f95e2954ecf561f3e19f7d22f@haskell.org> References: <046.812a6c0f95e2954ecf561f3e19f7d22f@haskell.org> Message-ID: <061.a3587d2d983bdb4722ec438b3c1505a6@haskell.org> #8048: Register spilling produces ineffecient/highly contending code -------------------------------------+------------------------------------- Reporter: schyler | Owner: Type: bug | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: 7.6.3 (CodeGen) | Keywords: register Resolution: | allocator spill Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by jstolarek): * cc: jan.stolarek@? (removed) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 18 09:05:54 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Sep 2015 09:05:54 -0000 Subject: [GHC] #8128: Standalone deriving fails for GADTs due to inaccessible code In-Reply-To: <049.b5f919d61189346fb956f5afd152d2c9@haskell.org> References: <049.b5f919d61189346fb956f5afd152d2c9@haskell.org> Message-ID: <064.d62ddff30574c8f9a2039339c483151a@haskell.org> #8128: Standalone deriving fails for GADTs due to inaccessible code -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.7 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #8740 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by jstolarek): * cc: jan.stolarek@? (removed) * cc: jstolarek (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 18 09:06:49 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Sep 2015 09:06:49 -0000 Subject: [GHC] #8423: contraint solver doesn't reduce reducible closed type family expressions (even with undecidable instances!) In-Reply-To: <045.e519cd37d8a4b1c71c71d8593787d92e@haskell.org> References: <045.e519cd37d8a4b1c71c71d8593787d92e@haskell.org> Message-ID: <060.7108d9e5ec14092e30628650fb70911b@haskell.org> #8423: contraint solver doesn't reduce reducible closed type family expressions (even with undecidable instances!) -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.7 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4259 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by jstolarek): * cc: jan.stolarek@? (removed) * cc: jstolarek (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 18 09:08:14 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Sep 2015 09:08:14 -0000 Subject: [GHC] #9157: cmm common block not eliminated In-Reply-To: <048.8d2730e58ddaeb1eb1c72b58cf8a9edb@haskell.org> References: <048.8d2730e58ddaeb1eb1c72b58cf8a9edb@haskell.org> Message-ID: <063.13f58f894c1d10b05717cceec06a751e@haskell.org> #9157: cmm common block not eliminated -------------------------------------+------------------------------------- Reporter: wojteknar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by jstolarek): * cc: jan.stolarek@? (removed) * cc: jstolarek (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 18 09:09:42 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Sep 2015 09:09:42 -0000 Subject: [GHC] #9557: Deriving instances is slow In-Reply-To: <048.4125fec548f18fcd48da9989fc1ebc4e@haskell.org> References: <048.4125fec548f18fcd48da9989fc1ebc4e@haskell.org> Message-ID: <063.e92ffeb553412b67442e6db1afe0b3e9@haskell.org> #9557: Deriving instances is slow -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8731 #10858 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by jstolarek): * cc: jan.stolarek@? (removed) * cc: jstolarek (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 18 09:15:22 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Sep 2015 09:15:22 -0000 Subject: [GHC] #10116: Closed type families: Warn if it doesn't handle all cases In-Reply-To: <049.356115fff338ba416dd9590b8ce78129@haskell.org> References: <049.356115fff338ba416dd9590b8ce78129@haskell.org> Message-ID: <064.a099c4f4a74fce59f5c10dcd485268e7@haskell.org> #10116: Closed type families: Warn if it doesn't handle all cases -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by jstolarek): * cc: jan.stolarek@? (removed) * cc: jstolarek (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 18 09:16:03 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Sep 2015 09:16:03 -0000 Subject: [GHC] #1498: Optimisation: eliminate unnecessary heap check in recursive function In-Reply-To: <047.d854a286f40f24efedada1697ad637ee@haskell.org> References: <047.d854a286f40f24efedada1697ad637ee@haskell.org> Message-ID: <062.179c734c79b898337a97f5e0cd4a0857@haskell.org> #1498: Optimisation: eliminate unnecessary heap check in recursive function -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: low | Milestone: 8.0.1 Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: 4258 | Blocking: Related Tickets: 8326 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by jstolarek): * cc: jan.stolarek@? (removed) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 18 09:17:17 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Sep 2015 09:17:17 -0000 Subject: [GHC] #4101: Primitive constant unfolding In-Reply-To: <045.7851f231c35583c6d8f82e7d68f78eb0@haskell.org> References: <045.7851f231c35583c6d8f82e7d68f78eb0@haskell.org> Message-ID: <060.675a9264e3486d3f3bdf81262b4496c8@haskell.org> #4101: Primitive constant unfolding -------------------------------------+------------------------------------- Reporter: malosh | Owner: schyler Type: bug | Status: new Priority: low | Milestone: 8.0.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Runtime | Test Case: performance bug | Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by jstolarek): * cc: jan.stolarek@? (removed) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 18 09:24:00 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Sep 2015 09:24:00 -0000 Subject: [GHC] #4466: Add extension for type application In-Reply-To: <044.fde123cc43374cdc1e81854ca78c4770@haskell.org> References: <044.fde123cc43374cdc1e81854ca78c4770@haskell.org> Message-ID: <059.7e8548a138a53a4ad3b1ff1b389d2049@haskell.org> #4466: Add extension for type application -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: feature request | Status: closed Priority: low | Milestone: 8.0.1 Component: Compiler | Version: 6.12.3 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5296 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by jstolarek): * cc: jan.stolarek@? (removed) * cc: jstolarek (added) * status: new => closed * resolution: => duplicate * related: => #5296 Comment: Clearly this has been duplicated by #5296 but since all the discussion is happening there I will close this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 18 09:24:18 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Sep 2015 09:24:18 -0000 Subject: [GHC] #5296: Add explicit type applications In-Reply-To: <042.d7f5be0512efad8881e5f10e7830add1@haskell.org> References: <042.d7f5be0512efad8881e5f10e7830add1@haskell.org> Message-ID: <057.92fd03672c8dbdf80477535854254f7c@haskell.org> #5296: Add explicit type applications -------------------------------------+------------------------------------- Reporter: dsf | Owner: goldfire Type: feature request | Status: new Priority: low | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.0.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: 1897 | Blocking: Related Tickets: #4466 | Differential Revisions: Phab:D1138 -------------------------------------+------------------------------------- Changes (by jstolarek): * cc: jan.stolarek@? (removed) * cc: jstolarek (added) * related: => #4466 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 18 09:26:22 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Sep 2015 09:26:22 -0000 Subject: [GHC] #10829: Simplification in the RHS of rules In-Reply-To: <046.7ca7c028ab82ec2d7ad263cb88680067@haskell.org> References: <046.7ca7c028ab82ec2d7ad263cb88680067@haskell.org> Message-ID: <061.b0ce486cfd50536bcb137c34f41b38ef@haskell.org> #10829: Simplification in the RHS of rules -------------------------------------+------------------------------------- Reporter: afarmer | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10528 | Differential Revisions: Phab:D1246 -------------------------------------+------------------------------------- Comment (by simonpj): I'd be rather surprised if anything optimises worse after this change. It's only a question of whether the optimisation happens before or after the rule is fired. I've been wrong before, and a smoke test would be good. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 18 09:27:32 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Sep 2015 09:27:32 -0000 Subject: [GHC] #8156: amd64 + in-tree gmp build broken In-Reply-To: <044.8d3c89c3b747f5cbec4467ee5ef43a21@haskell.org> References: <044.8d3c89c3b747f5cbec4467ee5ef43a21@haskell.org> Message-ID: <059.ee1bd706386f63e51f3ec5354b05d05d@haskell.org> #8156: amd64 + in-tree gmp build broken -------------------------------------+------------------------------------- Reporter: errge | Owner: Type: bug | Status: infoneeded Priority: low | Milestone: 8.0.1 Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: #4022 #4366 | Differential Revisions: #4374 | -------------------------------------+------------------------------------- Changes (by jstolarek): * cc: jan.stolarek@? (removed) * cc: jstolarek (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 18 09:28:07 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Sep 2015 09:28:07 -0000 Subject: [GHC] #8707: Kind inference fails in data instance definition In-Reply-To: <047.42701da74b266d5a65dd7046a49e3572@haskell.org> References: <047.42701da74b266d5a65dd7046a49e3572@haskell.org> Message-ID: <062.082b672dfb8e5aee6aff17c9cb3b9500@haskell.org> #8707: Kind inference fails in data instance definition -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by jstolarek): * cc: jan.stolarek@? (removed) * cc: jstolarek (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 18 09:28:43 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Sep 2015 09:28:43 -0000 Subject: [GHC] #2289: Needless reboxing of values when returning from a tight loop In-Reply-To: <043.32b2235b0e9fe1aba0c28a0cd28686b3@haskell.org> References: <043.32b2235b0e9fe1aba0c28a0cd28686b3@haskell.org> Message-ID: <058.8ade2976b1a21903fdbcf611355bcab1@haskell.org> #2289: Needless reboxing of values when returning from a tight loop -------------------------------------+------------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: lowest | Milestone: 8.0.1 Component: Compiler | Version: 6.8.2 Resolution: | Keywords: boxing, | loops, performance Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #2387,#1600 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by jstolarek): * cc: jan.stolarek@? (removed) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 18 09:29:38 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Sep 2015 09:29:38 -0000 Subject: [GHC] #2387: Optimizer misses unboxing opportunity In-Reply-To: <044.f6f12d90c4b64de9fb4d129e27bf4881@haskell.org> References: <044.f6f12d90c4b64de9fb4d129e27bf4881@haskell.org> Message-ID: <059.9e8c30d283ef6df6946247655119784e@haskell.org> #2387: Optimizer misses unboxing opportunity -------------------------------------+------------------------------------- Reporter: dolio | Owner: Type: bug | Status: new Priority: lowest | Milestone: 8.0.1 Component: Compiler | Version: 6.8.2 Resolution: | Keywords: optimizer | unbox box Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #2289 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by jstolarek): * cc: jan.stolarek@? (removed) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 18 09:29:53 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Sep 2015 09:29:53 -0000 Subject: [GHC] #2731: Avoid unnecessary evaluation when unpacking constructors In-Reply-To: <046.faa1da08abfada8ee02e462f3ba3c08c@haskell.org> References: <046.faa1da08abfada8ee02e462f3ba3c08c@haskell.org> Message-ID: <061.22153ffa9801335f2d07352b134b74a6@haskell.org> #2731: Avoid unnecessary evaluation when unpacking constructors -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: lowest | Milestone: 8.0.1 Component: Compiler | Version: 6.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by jstolarek): * cc: jan.stolarek@? (removed) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 18 09:31:01 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Sep 2015 09:31:01 -0000 Subject: [GHC] #10619: Order matters when type-checking In-Reply-To: <047.c2e45977ca8a75932617b490ff36950d@haskell.org> References: <047.c2e45977ca8a75932617b490ff36950d@haskell.org> Message-ID: <062.baa1aad4a254e41800389f3a618c8324@haskell.org> #10619: Order matters when type-checking -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by jstolarek): * cc: jstolarek (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 18 09:32:52 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Sep 2015 09:32:52 -0000 Subject: [GHC] #10892: ApplicativeDo should use *> and <* In-Reply-To: <047.75544cc852e1b71af89f5571354ace9a@haskell.org> References: <047.75544cc852e1b71af89f5571354ace9a@haskell.org> Message-ID: <062.e59fc200fa4de675241423787dcb2117@haskell.org> #10892: ApplicativeDo should use *> and <* -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 18 09:33:39 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Sep 2015 09:33:39 -0000 Subject: [GHC] #10709: Using ($) allows sneaky impredicativity on its left In-Reply-To: <047.69b727f09e59d3453594f8d03a6e522d@haskell.org> References: <047.69b727f09e59d3453594f8d03a6e522d@haskell.org> Message-ID: <062.5267be02f0d060981464f04ac8e399b7@haskell.org> #10709: Using ($) allows sneaky impredicativity on its left -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by jstolarek): * cc: jstolarek (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 18 09:35:59 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Sep 2015 09:35:59 -0000 Subject: [GHC] #3379: GHC should use the standard binary package In-Reply-To: <044.fa4dfe8be6394c3f94f6b68d8a40f5e7@haskell.org> References: <044.fa4dfe8be6394c3f94f6b68d8a40f5e7@haskell.org> Message-ID: <059.f7102eb2538563fe2d217ee15682cde6@haskell.org> #3379: GHC should use the standard binary package -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by jstolarek): * cc: jstolarek (removed) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 18 09:54:35 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Sep 2015 09:54:35 -0000 Subject: [GHC] #7883: enable GHC LLVM backend to use LLVM provided CAS / Atomicity primitives? In-Reply-To: <045.ccd82245c78d0eab2e30b4e2bcec2782@haskell.org> References: <045.ccd82245c78d0eab2e30b4e2bcec2782@haskell.org> Message-ID: <060.e774e2adddc8e147e4aa56e480835987@haskell.org> #7883: enable GHC LLVM backend to use LLVM provided CAS / Atomicity primitives? -------------------------------------+------------------------------------- Reporter: carter | Owner: carter Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by erikd): * cc: erikd (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 18 10:09:10 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Sep 2015 10:09:10 -0000 Subject: [GHC] #10893: Consistent error message suggestions for using language extensions In-Reply-To: <042.d717259da71a4197660845c46c0800a9@haskell.org> References: <042.d717259da71a4197660845c46c0800a9@haskell.org> Message-ID: <057.9546161583e63c87f8ec35811d4e8a7c@haskell.org> #10893: Consistent error message suggestions for using language extensions -------------------------------------+------------------------------------- Reporter: spl | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Old description: > I saw this error today in 7.10.1: > {{{ > Parse error: naked expression at top level > Perhaps you intended to use TemplateHaskell > }}} > I'm glad it suggests using !TemplateHaskell; however, the suggestion > seems incomplete. I did in fact intend to use Template Haskell, but I > think this suggestion implies the ''language extension'' though it > doesn't explicitly say so. > I believe other error message suggestions are more explicit about > mentioning language extension, e.g. {{{use -XFlexibleContexts}}}, which > refers to the flag. > I'm just bringing this issue up to request a consistent error message > suggestion format for language extensions that explicitly mentions > ?language extension??or {{{-X}}}. (It may be that the above message is > the only one not doing that; I haven't checked.) New description: I saw this error today in 7.10.1: {{{ Parse error: naked expression at top level Perhaps you intended to use TemplateHaskell }}} I'm glad it suggests using !TemplateHaskell; however, the suggestion seems incomplete. I did in fact intend to use Template Haskell, but I think this suggestion implies the ''language extension'' though it doesn't explicitly say so. I believe other error message suggestions are more explicit about mentioning language extension, e.g. {{{use -XFlexibleContexts}}}, which refers to the flag. I'm just bringing this issue up to request a consistent error message suggestion format for language extensions that explicitly mentions ?language extension??or {{{-X}}}. (It may be that the above message is the only one not doing that; I haven't checked.) -- Comment (by spl): Okay, I see that I missed the memo. The reasoning for removing {{{-X}}} is fine, and I'm glad the messages are consistent. I do think it would be useful to mention (language) extension (as opposed to using another flag) in the message, but the issue is minor and I'm not tied to it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 18 10:42:04 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Sep 2015 10:42:04 -0000 Subject: [GHC] #10375: arm: ghci hits an illegal instruction In-Reply-To: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> References: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> Message-ID: <059.f7eb55129f6e5dbaf657d5baeb7d3785@haskell.org> #10375: arm: ghci hits an illegal instruction -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: Runtime System | Version: 7.10.1 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by erikd): Notice that when it crashes the back trace looks like: {{{ (gdb) bt #0 0xb6ff0024 in ?? () #1 0x70000000 in ?? () }}} The address of the previous function (the value `0x70000000`) is a bit strange. If comes from the link register, `lr`: {{{ (gdb) info registers r0 0xb6ff0018 3070165016 r1 0x28 40 r2 0x1 1 r3 0x70000000 1879048192 r4 0x2350b50 37030736 r5 0xb38c4a0c 3012315660 r6 0xb5187d24 3038280996 r7 0xb38c4b30 3012315952 r8 0xb2ad2c38 2997693496 r9 0x7fffffff 2147483647 r10 0x1e6cef4 31903476 r11 0xb38c4750 3012314960 r12 0x235036c 37028716 sp 0xb59fcd70 0xb59fcd70 lr 0x70000000 1879048192 pc 0xb6ff0024 0xb6ff0024 cpsr 0x400f0010 1074724880 }}} So lets run the program under GDB and break on `$lr == 0x70000000` : {{{ (gdb) break main Breakpoint 1 at 0x93b08 (gdb) r Starting program: /home/erikd/Git/ghc-upstream/inplace/lib/bin/ghc-stage2 -B/home/erikd/Git/ghc-upstream/inplace/lib --interactive [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/arm-linux- gnueabihf/libthread_db.so.1". Breakpoint 1, 0x00093b08 in main () (gdb) watch $lr == 0x70000000 Watchpoint 2: $lr == 0x70000000 (gdb) c Continuing. [New Thread 0xb6bff460 (LWP 5344)] [New Thread 0xb61ff460 (LWP 5345)] [New Thread 0xb59ff460 (LWP 5346)] Program received signal SIGILL, Illegal instruction. strlen () at ../ports/sysdeps/arm/armv6t2/strlen.S:82 82 ../ports/sys }}} so we're back to `SIGILL`, but the assembly looks mostly sane: {{{ (gdb) disass 0xb6fe8800 Dump of assembler code for function strlen: 0xb6fe8800 <+0>: pld [r0] 0xb6fe8804 <+4>: strd r4, r5, [sp, #-8]! 0xb6fe8808 <+8>: bic.w r1, r0, #7 0xb6fe880c <+12>: mvn.w r12, #0 0xb6fe8810 <+16>: ands.w r4, r0, #7 0xb6fe8814 <+20>: pld [r1, #32] 0xb6fe8818 <+24>: bne.w 0xb6fe88ae 0xb6fe881c <+28>: mov.w r4, #0 => 0xb6fe8820 <+32>: mvn.w r0, #7 0xb6fe8824 <+36>: ldrd r2, r3, [r1] 0xb6fe8828 <+40>: pld [r1, #64] ; 0x40 0xb6fe882c <+44>: add.w r0, r0, #8 }}} I'm not sure why GDB thinks this is within the `strlen` function. If I disassemble `strlen` I get the same assembler instructions, but at a different address: {{{ (gdb) disass strlen Dump of assembler code for function strlen: 0xb6dbdb40 <+0>: pld [r0] 0xb6dbdb44 <+4>: strd r4, r5, [sp, #-8]! 0xb6dbdb48 <+8>: bic.w r1, r0, #7 0xb6dbdb4c <+12>: mvn.w r12, #0 0xb6dbdb50 <+16>: ands.w r4, r0, #7 0xb6dbdb54 <+20>: pld [r1, #32] 0xb6dbdb58 <+24>: bne.w 0xb6dbdbee 0xb6dbdb5c <+28>: mov.w r4, #0 0xb6dbdb60 <+32>: mvn.w r0, #7 0xb6dbdb64 <+36>: ldrd r2, r3, [r1] 0xb6dbdb68 <+40>: pld [r1, #64] ; 0x40 0xb6dbdb6c <+44>: add.w r0, r0, #8 }}} This does not make sense! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 18 11:43:56 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Sep 2015 11:43:56 -0000 Subject: [GHC] #9516: unsafeUnmask unmasks even inside uninterruptibleMask In-Reply-To: <044.1d01b7c46053b095d721dbccbd1f2dd3@haskell.org> References: <044.1d01b7c46053b095d721dbccbd1f2dd3@haskell.org> Message-ID: <059.b8543028b614a31fffa1047ea63a75f9@haskell.org> #9516: unsafeUnmask unmasks even inside uninterruptibleMask -------------------------------------+------------------------------------- Reporter: edsko | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Runtime System | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D181 -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 18 12:39:51 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Sep 2015 12:39:51 -0000 Subject: [GHC] #10375: arm: ghci hits an illegal instruction In-Reply-To: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> References: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> Message-ID: <059.31afd43c1bbfca3e26c8a6966913fbcb@haskell.org> #10375: arm: ghci hits an illegal instruction -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: Runtime System | Version: 7.10.1 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by int-e): Replying to [comment:57 erikd]: > I'm not sure why GDB thinks this is within the `strlen` function. If I disassemble `strlen` I get the same assembler instructions, but at a different address: That looks like there are several copies of `strlen` in the code, including symbol information. So the function name is found when looking for the symbol closest to `0xb6fe88ae`, but when resolving the name to an address, a different copy is used instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 18 14:04:46 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Sep 2015 14:04:46 -0000 Subject: [GHC] #10843: Allow do blocks without dollar signs as arguments In-Reply-To: <049.979a39a09d7a881598f53a6a6ce9bbe3@haskell.org> References: <049.979a39a09d7a881598f53a6a6ce9bbe3@haskell.org> Message-ID: <064.f310930c51fdb8b153fa5392781ad3da@haskell.org> #10843: Allow do blocks without dollar signs as arguments -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: agibiansky Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1219 -------------------------------------+------------------------------------- Comment (by bgamari): I tried to count the +1s and -1s but it seems to be fairly evenly split. Moreover, it seems like many users are fairly ambivalent on the matter. Andrew's message from Sept 7 nicely reviews the various arguments for and against the proposal. I'll reproduce it and a few other notable points here, == Pro == - It's easier to read than the alternative. - This extension removes syntactic noise. - This makes basic `do`-syntax more approachable to newbies; it is a commonly asked question as to why the `$` is necessary. - This simplifies the resulting AST, potentially making it simpler for editors and other tools to do refactoring. - It's something that belongs in the main language, and if its something we'd consider for a mythical Haskell', it has to start as an extension. - It gets rid of some cases where using `$` doesn't work because `$` interacts with other infix operators being used in the same expression. - This would make do blocks consistent with record creation, where parentheses are skipped, allowing things such as `return R { x = y}` - This does not change the meaning of any old programs, only allows new ones that were previously forbidden. - This gets rid of the need for a specially-typed `$` allowing `runSt $ do ...` - Richard Eisenberg points out that the proposal arguably makes the language **more** consistent, not less, > I think that it makes the language *more* regular, not less: Look at https://www.haskell.org/onlinereport/haskell2010/haskellch3.html#x8-220003, the Haskell 2010 Report on expression syntax. This proposal (if we include `if`, `let`, and `case`, along with `\` and `do`, which would seem to make it more consistent) amounts to dropping the /lexp/ nonterminal and combining it with /aexp/. == Con == - It's harder to read than the alternative. - Creating a language extension to get rid of a single character is overkill and unnecessary. - You can already get rid of the `$` by just adding parentheses. - More and more syntactic "improvements" just fragment the language. - Although this is consistent with record syntax, record syntax without parents was a mistake originally. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 18 15:23:22 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Sep 2015 15:23:22 -0000 Subject: [GHC] #8809: Prettier error messages? In-Reply-To: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> References: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> Message-ID: <062.2a7715532cc16ad5b1aff65712661952@haskell.org> #8809: Prettier error messages? -------------------------------------+------------------------------------- Reporter: joelteon | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: #8809,#10073,#10179 | -------------------------------------+------------------------------------- Changes (by gridaphobe): * cc: gridaphobe (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 18 15:29:35 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Sep 2015 15:29:35 -0000 Subject: [GHC] #10894: In users_guide/profiling.xml : -prof flag not to be used with cabal/stack Message-ID: <051.b9d67c5f210cc06a555ca9241f326e69@haskell.org> #10894: In users_guide/profiling.xml : -prof flag not to be used with cabal/stack -------------------------------------+------------------------------------- Reporter: | Owner: robstewartuk | Type: bug | Status: new Priority: lowest | Milestone: Component: | Version: 7.10.2 Documentation | Keywords: user | Operating System: Unknown/Multiple guide, profiling | Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- The documentation for compiling with cost centre profiling support is here: https://github.com/ghc/ghc/blob/master/docs/users_guide/profiling.xml#L79 It says: {{{ Compile and run this program as follows: $ ghc -prof -fprof-auto -rtsopts Main.hs $ ./Main +RTS -p 121393 $ }}} This is not the case when cabal or stack are used, as `-prof` should be omitted, i.e. {{{ cabal install --enable-executable-profiling --enable-library-profiling --ghc-options="-fprof-auto -rtsopts" }}} If the user does not know this and includes `-prof` in the --ghc-options string, they are likely to see compiler error messages relating to `p_dyn`, e.g. {{{ Failed to load interface for ?GHC.Integer.Type? Perhaps you haven't installed the "p_dyn" libraries for package ?integer- gmp-1.0.0.0?? Use -v to see a list of the files searched for. }}} Given that other parts of the `profiling.xml` file does refer to cabal, do people agree that it might be helpful to make it explicit in Section "5.1. Cost centres and cost-centre stacks", that using ghc directly `-prof` should be used (no change to the XML file): {{{ $ ghc -prof -fprof-auto -rtsopts Main.hs }}} Though if cabal/stack is being used, the `-prof` should be omitted (an addition to the XML file): {{{ $ cabal install --enable-executable-profiling --enable-library-profiling --ghc-options="-fprof-auto -rtsopts" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 18 15:36:13 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Sep 2015 15:36:13 -0000 Subject: [GHC] #8423: Less conservative compatibility check for closed type families (was: contraint solver doesn't reduce reducible closed type family expressions (even with undecidable instances!)) In-Reply-To: <045.e519cd37d8a4b1c71c71d8593787d92e@haskell.org> References: <045.e519cd37d8a4b1c71c71d8593787d92e@haskell.org> Message-ID: <060.a06ade624a4d0ef12762cd66afa3b071@haskell.org> #8423: Less conservative compatibility check for closed type families -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: feature request | Status: new Priority: normal | Milestone: ? Component: Compiler (Type | Version: 7.7 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4259 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * milestone: 8.0.1 => ? Comment: New title and milestone to reflect the realities here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 18 16:21:48 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Sep 2015 16:21:48 -0000 Subject: [GHC] #10751: Implement Phase 1 of MonadFail Proposal (MFP) In-Reply-To: <042.af0b8689bcfac4a130648c64d759a4c0@haskell.org> References: <042.af0b8689bcfac4a130648c64d759a4c0@haskell.org> Message-ID: <057.5c4c61fe2c3b9a3f531521d570fa6973@haskell.org> #10751: Implement Phase 1 of MonadFail Proposal (MFP) -------------------------------------+------------------------------------- Reporter: hvr | Owner: quchen Type: task | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: report- | impact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1248 -------------------------------------+------------------------------------- Comment (by ekmett): My sense is that support within the committee or this proposal is very high, based on various discussions. I will however, take a moment to formally poll for objections within the committee just to make absolutely sure before I commit to signing off. That said, would it be possible to move the proposal from a github page to the Haskell Wiki for posterity? That would make it easier to express questions about minor points, e.g. whether `ViewPatterns`/`PatternSynonyms` should always be considered failable or if they should only be considered failable if their right hand side is. e.g. {{{ pattern Foo = ((),()) }}} is clearly an unfailable pattern. as is {{{ foo (snd -> x) = ... }}} as 'x' is unfailable. These compose for useful patterns like {{{ pattern Polar x y <- (magnitude &&& phase -> (x,y)) where Polar x y = mkPolar x y }}} Those items there are probably the primary sticking point I have personally, but in broad strokes I personally absolutely adore this proposal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 18 16:22:32 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Sep 2015 16:22:32 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMDIxNjogQWxsb3cgYXJyIOKIpyAoZmlyc3Qg?= =?utf-8?q?=E2=88=A8_=28***=29=29_as_minimal_definition_of_Arrow_?= =?utf-8?q?instance?= In-Reply-To: <048.64b271a00a46843da0df000240882f80@haskell.org> References: <048.64b271a00a46843da0df000240882f80@haskell.org> Message-ID: <063.469208b8f3f70116bba5791b8fad3653@haskell.org> #10216: Allow arr ? (first ? (***)) as minimal definition of Arrow instance -------------------------------------+------------------------------------- Reporter: strake888 | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ekmett): * cc: ekmett (added) Comment: Granted. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 18 17:11:36 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Sep 2015 17:11:36 -0000 Subject: [GHC] #10751: Implement Phase 1 of MonadFail Proposal (MFP) In-Reply-To: <042.af0b8689bcfac4a130648c64d759a4c0@haskell.org> References: <042.af0b8689bcfac4a130648c64d759a4c0@haskell.org> Message-ID: <057.4d7e59a959fa3773e0f251d6fd99350d@haskell.org> #10751: Implement Phase 1 of MonadFail Proposal (MFP) -------------------------------------+------------------------------------- Reporter: hvr | Owner: quchen Type: task | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: report- | impact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1248 -------------------------------------+------------------------------------- Comment (by quchen): > would it be possible to move the proposal from a github page to the Haskell Wiki for posterity? Of course, I should have done that earlier. I'll get to it within a few hours. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 18 17:22:00 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Sep 2015 17:22:00 -0000 Subject: [GHC] #10892: ApplicativeDo should use *> and <* In-Reply-To: <047.75544cc852e1b71af89f5571354ace9a@haskell.org> References: <047.75544cc852e1b71af89f5571354ace9a@haskell.org> Message-ID: <062.7463a06e2144537d474f9fb10c032f61@haskell.org> #10892: ApplicativeDo should use *> and <* -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ekmett): Here's a sketch of how this could work: The current patch for `ApplicativeDo` tracks applicative "chains". This would modify the `Applicative` chains you have to hold a `Maybe` pattern instead of a pattern or you could just check for wildcard patterns. There are basically 3 cases for dealing with the chain of (<*>)'s we use today. If you have a prefix of things that don't have meaningful patterns, you can bind them with `(*>)`, just like we'd bind with (>>) before. {{{ do foo;bar;baz; x <- quux; y <- quaffle; return (xyzzy x y) foo *> bar *> baz *> (xyzzy <$> quux <*> quaffle) }}} Otherwise, once you've seen a pattern that actually matters, any subsequent missing patterns can be dropped by using `(<*)` or `(<$)`. The `(<*)` case is mentioned in the description. The `(<$)` case happens for {{{ foo = do bar return whatever }}} which becomes {{{ foo = whatever <$ bar }}} This desugaring should then favor all the right things. `(*>)` is typically a little cheaper than `(<*)`. `(<$)` and `(*>)` are cheaper than `(<$>)` and `(<*>)` when usable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 18 17:58:33 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Sep 2015 17:58:33 -0000 Subject: [GHC] #10895: "no output will be generated" should be an error, not a warning. Message-ID: <047.f8da814851ed39c21e13b0c3f92e534f@haskell.org> #10895: "no output will be generated" should be an error, not a warning. -------------------------------------+------------------------------------- Reporter: gershomb | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Consider a file "Test.hs" which has a "main" function but is declared as "module Test where..." If we attempt to compile it, we get the following warning: {{{ Warning: output was redirected with -o, but no output will be generated because there is no Main module. }}} This should be upgraded from a warning to an error. This would help e.g. Cabal, because such warnings do not lead to a failure of the wrapping Cabal process, which is confusing to end-users. For gory details, see e.g. discussion at https://github.com/haskell/cabal/issues/1847 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 18 18:08:04 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Sep 2015 18:08:04 -0000 Subject: [GHC] #10894: In users_guide/profiling.xml : -prof flag not to be used with cabal/stack In-Reply-To: <051.b9d67c5f210cc06a555ca9241f326e69@haskell.org> References: <051.b9d67c5f210cc06a555ca9241f326e69@haskell.org> Message-ID: <066.5c6ca843fcc1b5905cbb19a3a056b85c@haskell.org> #10894: In users_guide/profiling.xml : -prof flag not to be used with cabal/stack -------------------------------------+------------------------------------- Reporter: robstewartuk | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Documentation | Version: 7.10.2 Resolution: | Keywords: user | guide, profiling Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by osa1): I had this problem before and it's quite annoying, but I feel like the right way to solve this is to add a check in Cabal and print a warning if `--ghc-options=-prof` is used. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 18 18:13:12 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Sep 2015 18:13:12 -0000 Subject: [GHC] #10895: "no output will be generated" should be an error, not a warning. In-Reply-To: <047.f8da814851ed39c21e13b0c3f92e534f@haskell.org> References: <047.f8da814851ed39c21e13b0c3f92e534f@haskell.org> Message-ID: <062.4b9a23fac834ef03c7c99b730fb5f04f@haskell.org> #10895: "no output will be generated" should be an error, not a warning. -------------------------------------+------------------------------------- Reporter: gershomb | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): Attempt to compile it how? Obviously `ghc Test` will not warn, and will just produce an object file. I guess you mean `ghc Test -o foo`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 18 18:36:55 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Sep 2015 18:36:55 -0000 Subject: [GHC] #10895: "no output will be generated" should be an error, not a warning. In-Reply-To: <047.f8da814851ed39c21e13b0c3f92e534f@haskell.org> References: <047.f8da814851ed39c21e13b0c3f92e534f@haskell.org> Message-ID: <062.14b285006573fe9e8f24e64b0433e2a7@haskell.org> #10895: "no output will be generated" should be an error, not a warning. -------------------------------------+------------------------------------- Reporter: gershomb | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by gershomb: Old description: > Consider a file "Test.hs" which has a "main" function but is declared as > "module Test where..." > > If we attempt to compile it, we get the following warning: > > {{{ > Warning: output was redirected with -o, but no output will be generated > because there is no Main module. > }}} > > This should be upgraded from a warning to an error. This would help e.g. > Cabal, because such warnings do not lead to a failure of the wrapping > Cabal process, which is confusing to end-users. > > For gory details, see e.g. discussion at > https://github.com/haskell/cabal/issues/1847 New description: Consider a file "Test.hs" which has a "main" function but is declared as "module Test where..." If we attempt to compile it with for example "ghc --make Test.hs -o Test", we get the following warning: {{{ Warning: output was redirected with -o, but no output will be generated because there is no Main module. }}} This should be upgraded from a warning to an error. This would help e.g. Cabal, because such warnings do not lead to a failure of the wrapping Cabal process, which is confusing to end-users. For gory details, see e.g. discussion at https://github.com/haskell/cabal/issues/1847 -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 18 18:37:18 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Sep 2015 18:37:18 -0000 Subject: [GHC] #10895: "no output will be generated" should be an error, not a warning. In-Reply-To: <047.f8da814851ed39c21e13b0c3f92e534f@haskell.org> References: <047.f8da814851ed39c21e13b0c3f92e534f@haskell.org> Message-ID: <062.a8bfbf41e2ba35a360d600d078200ec9@haskell.org> #10895: "no output will be generated" should be an error, not a warning. -------------------------------------+------------------------------------- Reporter: gershomb | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by gershomb): Yep, ticket amended to indicate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 18 18:38:07 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Sep 2015 18:38:07 -0000 Subject: [GHC] #10580: rejected emails for Trac registrations from https://ghc.haskell.org/trac/haskell-prime In-Reply-To: <042.fca6bf75ceadc97246c14a092e17cda4@haskell.org> References: <042.fca6bf75ceadc97246c14a092e17cda4@haskell.org> Message-ID: <057.5217c44857bc8a85d06efe4fb9c3e7a3@haskell.org> #10580: rejected emails for Trac registrations from https://ghc.haskell.org/trac /haskell-prime -------------------------------------+------------------------------------- Reporter: imz | Owner: hvr Type: bug | Status: closed Priority: normal | Milestone: Component: Trac & Git | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gershomb): * status: new => closed * resolution: => fixed Comment: So I think we fixed this by making the trac for prime send from a real hostname and not just trac at localhost. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 18 18:42:08 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Sep 2015 18:42:08 -0000 Subject: [GHC] #10580: rejected emails for Trac registrations from https://ghc.haskell.org/trac/haskell-prime In-Reply-To: <042.fca6bf75ceadc97246c14a092e17cda4@haskell.org> References: <042.fca6bf75ceadc97246c14a092e17cda4@haskell.org> Message-ID: <057.5b016a7f70315a47ac5f44d2e5303f8b@haskell.org> #10580: rejected emails for Trac registrations from https://ghc.haskell.org/trac /haskell-prime -------------------------------------+------------------------------------- Reporter: imz | Owner: hvr Type: bug | Status: closed Priority: normal | Milestone: Component: Trac & Git | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): gershomb: thanks for fixing this so quickly. imz: sorry that you had to wait such a long time. I didn't see this ticket until yesterday, and after telling the haskell-infra team they quickly fixed it. I hope it works for you now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 18 19:59:23 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Sep 2015 19:59:23 -0000 Subject: [GHC] #10857: "ghci -XMonomorphismRestriction" doesn't turn on the monomorphism restriction In-Reply-To: <047.0bca38b39289a4db2d373be62522bc3d@haskell.org> References: <047.0bca38b39289a4db2d373be62522bc3d@haskell.org> Message-ID: <062.e1c82b6fce6bc09f40e60ce528b98eb8@haskell.org> #10857: "ghci -XMonomorphismRestriction" doesn't turn on the monomorphism restriction -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: cocreature Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #3202, #3217 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by cocreature): * owner: => cocreature -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 18 20:04:42 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Sep 2015 20:04:42 -0000 Subject: [GHC] #1465: Type errors due to different package versions are a bit cryptic In-Reply-To: <044.3eb957974d50a2abe03476d2d0ac2f53@haskell.org> References: <044.3eb957974d50a2abe03476d2d0ac2f53@haskell.org> Message-ID: <059.5d4b536c2c308cd13c1e0f66cc4ae712@haskell.org> #1465: Type errors due to different package versions are a bit cryptic -----------------------------------------------+--------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.8.1 Component: Compiler (Type checker) | Version: 6.6.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Test Case: tcfail182, bug1465, mod180 | Unknown/Multiple -----------------------------------------------+--------------------------- Comment (by Edward Z. Yang ): In [changeset:"a8406f81a5da077d1c4b9995654ca9972f39130c/ghc" a8406f81/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a8406f81a5da077d1c4b9995654ca9972f39130c" Pass TEST_HC_OPTS in bug1465 and T5792. Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1250 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 18 20:07:38 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Sep 2015 20:07:38 -0000 Subject: [GHC] #10751: Implement Phase 1 of MonadFail Proposal (MFP) In-Reply-To: <042.af0b8689bcfac4a130648c64d759a4c0@haskell.org> References: <042.af0b8689bcfac4a130648c64d759a4c0@haskell.org> Message-ID: <057.5879c1c610e784741e4201c68bcbb90c@haskell.org> #10751: Implement Phase 1 of MonadFail Proposal (MFP) -------------------------------------+------------------------------------- Reporter: hvr | Owner: quchen Type: task | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: report- | impact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1248 -------------------------------------+------------------------------------- Comment (by quchen): Wiki entry created: https://wiki.haskell.org/MonadFail_Proposal -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 18 21:18:24 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Sep 2015 21:18:24 -0000 Subject: [GHC] #10896: BadSock triggers failing ASSERT Message-ID: <045.e2606f0aace406a963850215a356a8ed@haskell.org> #10896: BadSock triggers failing ASSERT -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- {{{ --- ./indexed-types/should_fail/BadSock.stderr.normalised 2015-09-18 20:44:48.437390831 +0000 +++ ./indexed-types/should_fail/BadSock.comp.stderr.normalised 2015-09-18 20:44:48.437390831 +0000 @@ -1,5 +1,5 @@ +ghc: panic! (the 'impossible' happened) + (GHC version 7.11.20150918 for x86_64-unknown-linux): + ASSERT failed! file compiler/typecheck/TcFlatten.hs, line 1041 -BadSock.hs:30:5: - The type family ???Readable??? should have 1 argument, but has been given none - In the equations for closed type family ???Foo??? - In the type family declaration for ???Foo??? \ No newline at end of file +Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug \ No newline at end of file *** unexpected failure for BadSock(normal) }}} Haven't investigated any further. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 18 21:24:02 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Sep 2015 21:24:02 -0000 Subject: [GHC] #10896: BadSock triggers failing ASSERT In-Reply-To: <045.e2606f0aace406a963850215a356a8ed@haskell.org> References: <045.e2606f0aace406a963850215a356a8ed@haskell.org> Message-ID: <060.a9074b57d927900bf349abd72c4fda1e@haskell.org> #10896: BadSock triggers failing ASSERT -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * cc: simonpj (added) Comment: This was caused by one of Simon's commits trying to fix the fallout from Phab:D202 (injective type families). See jstolarek's comment in https://phabricator.haskell.org/D202#34497. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 19 00:15:33 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Sep 2015 00:15:33 -0000 Subject: [GHC] #8990: Performance tests behave differently depending on presence of .hi file (even with -fforce-recomp) In-Reply-To: <045.abd2027873a2b9d9a2bc9aa2b4b749ea@haskell.org> References: <045.abd2027873a2b9d9a2bc9aa2b4b749ea@haskell.org> Message-ID: <060.33385708d6596b37189735b1524201b9@haskell.org> #8990: Performance tests behave differently depending on presence of .hi file (even with -fforce-recomp) -------------------------------------+------------------------------------- Reporter: ezyang | Owner: przembot Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.9 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): I found another case recently where this matters: whether or not an interface file is loaded can affect the assignment of uniques, which in turn can cause rules to fire in a different order. (in my case, it was `T7837` with the patchset I've been developing for #10871). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 19 00:18:16 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Sep 2015 00:18:16 -0000 Subject: [GHC] #10653: PatternSynonyms should be imported/exported as part of the wildcard notation In-Reply-To: <049.0e5a3c33a167308dc99ecaed5730df14@haskell.org> References: <049.0e5a3c33a167308dc99ecaed5730df14@haskell.org> Message-ID: <064.ba16235c8c566df8e3cf1320e340196a@haskell.org> #10653: PatternSynonyms should be imported/exported as part of the wildcard notation -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: mpickering Type: feature request | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: pattern | synonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): Here is a use case for this feature. A module in the Darcs codebase currently says: {{{ import GHC.Exception ( throwIO, ErrorCall(..) ) }}} This code doesn't compile with HEAD, because #5273 replaced the `ErrorCall` data constructor by a pattern synonym. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 19 00:51:58 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Sep 2015 00:51:58 -0000 Subject: [GHC] #10897: Incorrect ASSERT for buildPatSyn Message-ID: <045.72f9540a916b61c61568cdbdec70fba4@haskell.org> #10897: Incorrect ASSERT for buildPatSyn -------------------------------------+------------------------------------- Reporter: ezyang | Owner: cactus Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Consider the following two files: {{{ -- A.hs {-# LANGUAGE PatternSynonyms #-} module A where pattern Single :: a -> a pattern Single x = x -- B.hs module B where import A Single y = True }}} When I build these using one-shot compilation using a debugged GHC (i.e. with ASSERTs) I get the following error: {{{ [ezyang at hs01 ghc-quick3]$ inplace/bin/ghc-stage2 -c A.hs -fforce-recomp [ezyang at hs01 ghc-quick3]$ inplace/bin/ghc-stage2 -c B.hs -fforce-recomp ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.11.20150918 for x86_64-unknown-linux): ASSERT failed! file compiler/iface/BuildTyCl.hs, line 210 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I expanded the assert and discovered it was claiming the universal type variables of the matcher should be equal to the type variables of the pattern declaration. This assert cannot possibly be right: the matcher and the pattern declaration are typechecked separately and there's no reason that the local binders should actually be the same. The equality test here should be done up to alpha-renaming. The other thing I found a bit puzzling was whether or not it mattered whether or not we used the local type variables from the matcher or the freshly bound ones. I suppose if we are consistent it shouldn't matter, so I don't think the code is buggy, just a bad ASSERT. BTW: this assert problem doesn't show up with `--make` because the assert occurs during typechecking of interface files, and with `--make` we don't need to typecheck an interface file. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 19 01:57:15 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Sep 2015 01:57:15 -0000 Subject: [GHC] #10871: Implement "fat" interface files which can be directly compiled without source (was: Implement "buildable" interface files which can be directly compiled without source) In-Reply-To: <045.f4306fd46ddf30e7464e9ea8971267bf@haskell.org> References: <045.f4306fd46ddf30e7464e9ea8971267bf@haskell.org> Message-ID: <060.a8bc4c717ad173279118a2075394792d@haskell.org> #10871: Implement "fat" interface files which can be directly compiled without source -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): Posting a little update about the tiresome root main function: the root main function is a special implicit binding that is added to Haskell programs during type checking and serves as the "well known" entry point to enter a Haskell program. Currently, it is named `:Main.main` (i.e. `ZCMain_main`): unusually, it is a binding in a Haskell program that can have a different `Module` than the module actually being compiled. Because of this, it has to be treated specially when we serialize it out to an interface file: namely, we have to know /which/ binding is the root main binding (so it doesn't clobber the user-written main binding), as interface file serialization doesn't record `Module`, only the `OccName`. In our last phone call, we proposed two fixes, but I don't think either of them will work: 1. Move the binding to be injected during tidying, rather than typechecking. This is tiresome because `main` is to have type `IO a`, where `a` is anything we want. We'd have to extract out this type to make a well-formed core binding (this is marginally easier in the typechecker, where the current code does unification to pull it out.) We are also only given the `RdrName` of the function which is supposed to be main; we have to consult the `GlobalRdrEnv` to turn this into an actual `Name`. So we also have to make sure to preserve this information until the final tidying so that we can point to the correct main function, which means yet another thing to record in `ModGuts`. Finally, we can't really eliminate `checkMain`, since we need to give errors when appropriate. So this is a large amount of work for a questionable amount of benefit. 2. Rename the main `OccName` to something special, e.g. `$main`, so we can identify it in the interface file. If we do this, it means the name that you must refer to for a Haskell program for main, `ZCMain_main_closure`, has to be renamed to `ZCMain_zdmain_closure`. This is pretty gratuitous and will break any C-Haskell bridges for no good reason. So I'd like not to do that. I think my current plan is to just have a flag in `IfaceBinding` which says if this is "main" or not, and then we just typecheck it accordingly one way or another. A small amount of code, no penalty for normal interface files, and very simple. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 19 04:14:22 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Sep 2015 04:14:22 -0000 Subject: [GHC] #10898: GHCI crash Message-ID: <045.6b0350008e1009dd255fc812f56da5c5@haskell.org> #10898: GHCI crash ---------------------------------+------------------------------- Reporter: trebor | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ---------------------------------+------------------------------- robert at HeisenbergJr:~$ ghci GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for i386-unknown-linux): interactiveUI:setBuffering2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 19 04:48:57 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Sep 2015 04:48:57 -0000 Subject: [GHC] #10871: Implement "fat" interface files which can be directly compiled without source In-Reply-To: <045.f4306fd46ddf30e7464e9ea8971267bf@haskell.org> References: <045.f4306fd46ddf30e7464e9ea8971267bf@haskell.org> Message-ID: <060.6881d246211ac846ae40273cb4e9ae8a@haskell.org> #10871: Implement "fat" interface files which can be directly compiled without source -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): Here is a comment about the extra things that we seem to need to serialize to a `ModIface`, beyond `IfaceBinding`s: 1. `mg_rdr_env :: GlobalRdrEnv`. Originally, I claimed that this was only used by the vectorizor; however, I was slightly mistaken: it is ALSO used to generate error messages / debug information in the simplifier and interface generation code. For example, we don't warn about orphans until `MkIface`; and to give nice qualified names, we need a `GlobalRdrEnv`. I'm investigating if we can move orphan warnings earlier, but in general to not serialize `GlobalRdrEnv` we will pay a little bit in how good the error messages are (maybe this is OK for the simplifier monad, which I don't believe gives any user-visible messages using this). 2. `mg_hpc_info :: HpcInfo` and `mg_foreign :: ForeignStubs` are directly passed through to code generation during Tidy, so we can't get rid of them. So my inclination is to create a field in `ModIface` like `mi_cg_info :: Maybe CgIface`, which contains just these two bits. I managed to eliminate the usage fields in `ModGuts` by computing usage information earlier, during desugaring. This seems to work quite well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 19 09:08:12 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Sep 2015 09:08:12 -0000 Subject: [GHC] #10898: GHCI crash In-Reply-To: <045.6b0350008e1009dd255fc812f56da5c5@haskell.org> References: <045.6b0350008e1009dd255fc812f56da5c5@haskell.org> Message-ID: <060.47497b66ec3b18457beaf45e2f29ee96@haskell.org> #10898: GHCI crash -------------------------------+-------------------------------- Reporter: trebor | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+-------------------------------- Comment (by thomie): Can you try upgrading to the latest version of GHC? Which instructions did you follow to install ghc-7.6? I'm asking, because we only support ghc-7.10, so any guide or tutorial you followed should be updated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 19 09:51:09 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Sep 2015 09:51:09 -0000 Subject: [GHC] #10375: arm: ghci hits an illegal instruction In-Reply-To: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> References: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> Message-ID: <059.64b09155f423c91b2b307732c349d1ff@haskell.org> #10375: arm: ghci hits an illegal instruction -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: Runtime System | Version: 7.10.1 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by erikd): On irc, @bgamari suggested that this problem may just be a failure to flush the instruction caches. On inspecting the code and adding debug printf statements, found that the instruction cache is indeed being flushed. Futhermore cache flushing on arm/linux only works if it was allocated using `mmap()` with the `PROT_EXEC` flag set. I have also confirmed that this is case. Since this issue of a `SIGILL` in seemingly correct and valid code only happens when I try to break on `watch $lr == 0x70000000` I'm going to chalk this up to an GDB related Heisenburg-like interaction between GDB and the debug target. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 19 10:16:13 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Sep 2015 10:16:13 -0000 Subject: [GHC] #7830: Error: operand out of range In-Reply-To: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> References: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> Message-ID: <059.f19718d6ea5aea9267a0bef518a755bc@haskell.org> #7830: Error: operand out of range -------------------------------------+------------------------------------- Reporter: erikd | Owner: trommler Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Installing GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by trommler): * owner: => trommler -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 19 14:16:42 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Sep 2015 14:16:42 -0000 Subject: [GHC] #10895: "no output will be generated" should be an error, not a warning. In-Reply-To: <047.f8da814851ed39c21e13b0c3f92e534f@haskell.org> References: <047.f8da814851ed39c21e13b0c3f92e534f@haskell.org> Message-ID: <062.86643cc37f6b12844f5e1c175db6f986@haskell.org> #10895: "no output will be generated" should be an error, not a warning. -------------------------------------+------------------------------------- Reporter: gershomb | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1253 -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch * differential: => Phab:D1253 * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 19 15:21:41 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Sep 2015 15:21:41 -0000 Subject: [GHC] #10726: Upgrade MingW-w64 distributions for windows In-Reply-To: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> References: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> Message-ID: <059.bbb2318a7c55f274e3f13b1edc2c68f8@haskell.org> #10726: Upgrade MingW-w64 distributions for windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: task | Status: merge Priority: normal | Milestone: 7.10.3 Component: Build System | Version: 7.11 Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9218 #9014 | Differential Revisions: Phab:D1123 #10435 | -------------------------------------+------------------------------------- Comment (by hanjoosten): I would also VERY much see this fix released early. My project is bumping on this issue too. (see this ticket: https://github.com/fpco/minghc/issues/91) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 19 16:08:00 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Sep 2015 16:08:00 -0000 Subject: [GHC] #10815: Need more kind inference in associated type instances In-Reply-To: <047.d8bc1a4461bf2f49e829557a2b73313c@haskell.org> References: <047.d8bc1a4461bf2f49e829557a2b73313c@haskell.org> Message-ID: <062.8234d692818d7a6b6041a8791412aa06@haskell.org> #10815: Need more kind inference in associated type instances -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1195 -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"2d4db40ac07db2fc776d61aac2383608911281ff/ghc" 2d4db40a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2d4db40ac07db2fc776d61aac2383608911281ff" Fix #10815 by kind-checking type patterns against known kinds. tcFamTyPats now must take information about the instantiation of any class variables, when checking the instance of an associated type. Getting this to work out required some unexpected refactoring in TcDeriv. TcDeriv needs to look at class instances because of the possibility of associated datatypes with `deriving` specs. TcDeriv worked over the user-specified instances. But any data family instances were already processed, and TcDeriv had no way of finding the rep tycons. Indeed, TcDeriv *re-type-checked* any data family instances in an attempt to rediscover what GHC already knew. So, this commit introduces better tracking of compiled data families between TcInstDcls and TcDeriv to streamline all of this. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 19 16:10:59 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Sep 2015 16:10:59 -0000 Subject: [GHC] #10815: Need more kind inference in associated type instances In-Reply-To: <047.d8bc1a4461bf2f49e829557a2b73313c@haskell.org> References: <047.d8bc1a4461bf2f49e829557a2b73313c@haskell.org> Message-ID: <062.79528136d21a4a6eb68dd1eb203a53a2@haskell.org> #10815: Need more kind inference in associated type instances -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: merge Priority: normal | Milestone: 7.10.3 Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_compile/T10815 Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1195 -------------------------------------+------------------------------------- Changes (by goldfire): * status: patch => merge * testcase: => indexed-types/should_compile/T10815 * milestone: => 7.10.3 Comment: Merge only if convenient. I doubt this is biting anyone other than me, and I can wait until 8.0 for this. But it is a real bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 19 16:49:52 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Sep 2015 16:49:52 -0000 Subject: [GHC] #10899: Polytype accepted in RHS of default associated type Message-ID: <047.7b758dc1f514e80e61654f6aef2fa500@haskell.org> #10899: Polytype accepted in RHS of default associated type -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- This hogwash is accepted: {{{ class C a where type F a type F a = forall m. m a }}} I will fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 19 17:22:48 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Sep 2015 17:22:48 -0000 Subject: [GHC] #10726: Upgrade MingW-w64 distributions for windows In-Reply-To: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> References: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> Message-ID: <059.d2662ab19b9cb8e98fa1110d9c825b2c@haskell.org> #10726: Upgrade MingW-w64 distributions for windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: task | Status: merge Priority: normal | Milestone: 7.10.3 Component: Build System | Version: 7.11 Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9218 #9014 | Differential Revisions: Phab:D1123 #10435 | -------------------------------------+------------------------------------- Comment (by hanjoosten): Thinking even more about this: Sandboxing is done more and more, resulting in longer paths, thus triggering this bug sooner. Hopefully there will be a 7.10.3 soon. If there is anything I could do to test, please let me know. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 19 17:26:36 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Sep 2015 17:26:36 -0000 Subject: [GHC] #10891: `reify` doesn't find associated type families In-Reply-To: <046.9e704f075dee9514291b5d5766834bf9@haskell.org> References: <046.9e704f075dee9514291b5d5766834bf9@haskell.org> Message-ID: <061.403788591adfed5338770c6caa8eddc7@haskell.org> #10891: `reify` doesn't find associated type families -------------------------------------+------------------------------------- Reporter: antalsz | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: type | families; newcomer 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 osa1): How should default type instances be reified? e.g. if I have something like: {{{#!haskell class C a where type T a :: * type T a = a }}} Syntactically it looks like `TySynD` but semantically it's different. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 19 18:13:11 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Sep 2015 18:13:11 -0000 Subject: [GHC] #10726: Upgrade MingW-w64 distributions for windows In-Reply-To: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> References: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> Message-ID: <059.d4755ebc14c046092b5b62f8e5e86e74@haskell.org> #10726: Upgrade MingW-w64 distributions for windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: task | Status: merge Priority: normal | Milestone: 7.10.3 Component: Build System | Version: 7.11 Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9218 #9014 | Differential Revisions: Phab:D1123 #10435 | -------------------------------------+------------------------------------- Comment (by tejon): Just found this via @hanjoosten in a MinGHC issue thread. Haven't tested yet, but there's a very good chance this will fix building the GTK+ bindings on Windows: current failures mostly revolve around attempts to use -pthreads, which is not available in GCC 4.6.3 but is as of 4.9.x. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 19 18:35:15 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Sep 2015 18:35:15 -0000 Subject: [GHC] #10653: PatternSynonyms should be imported/exported as part of the wildcard notation In-Reply-To: <049.0e5a3c33a167308dc99ecaed5730df14@haskell.org> References: <049.0e5a3c33a167308dc99ecaed5730df14@haskell.org> Message-ID: <064.1db235a86577e6321a81333354d12427@haskell.org> #10653: PatternSynonyms should be imported/exported as part of the wildcard notation -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: mpickering Type: feature request | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: | PatternSynonyms, pattern synonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * keywords: pattern synonyms => PatternSynonyms, pattern synonyms * cc: cactus (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 19 18:36:17 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Sep 2015 18:36:17 -0000 Subject: [GHC] #10894: In users_guide/profiling.xml : -prof flag not to be used with cabal/stack In-Reply-To: <051.b9d67c5f210cc06a555ca9241f326e69@haskell.org> References: <051.b9d67c5f210cc06a555ca9241f326e69@haskell.org> Message-ID: <066.04de6f399ecb25ebe43df5d18fa54809@haskell.org> #10894: In users_guide/profiling.xml : -prof flag not to be used with cabal/stack -------------------------------------+------------------------------------- Reporter: robstewartuk | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Documentation | Version: 7.10.2 Resolution: | Keywords: user | guide, profiling Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by robstewartuk): Thanks @osa1 , I agree with this suggestion. I have opened this suggestion for both cabal and stack in two mirrored tickets: https://github.com/commercialhaskell/stack/issues/1015 https://github.com/haskell/cabal/issues/2827 Once both tickets are addressed, I will return here to close this one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 19 18:39:26 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Sep 2015 18:39:26 -0000 Subject: [GHC] #10891: `reify` doesn't find associated type families In-Reply-To: <046.9e704f075dee9514291b5d5766834bf9@haskell.org> References: <046.9e704f075dee9514291b5d5766834bf9@haskell.org> Message-ID: <061.a05bc20d06c013beb7ed9c641057fba4@haskell.org> #10891: `reify` doesn't find associated type families -------------------------------------+------------------------------------- Reporter: antalsz | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: type | families; newcomer 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 goldfire): That's true that it's different semantically. But Template Haskell is all about syntax, not semantics. But I'd make it a `TySynInstD` instead of a `TySynD` (even though the latter is more syntactically accurate). It seems a bit overwrought to make a new constructor for `Dec` for this case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 19 18:53:07 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Sep 2015 18:53:07 -0000 Subject: [GHC] #10774: Use `Natural` rather than `Integer` in `GHC.TypeLits` In-Reply-To: <042.7c7cb988b2d1af2ee71900558e4a13e4@haskell.org> References: <042.7c7cb988b2d1af2ee71900558e4a13e4@haskell.org> Message-ID: <057.a05471409305b6674936fe0e0c5b88c4@haskell.org> #10774: Use `Natural` rather than `Integer` in `GHC.TypeLits` -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.2 Resolution: | Keywords: TypeLits | Natural Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * milestone: 8.0.1 => Comment: Just went to fix this. But it has to wait until we won't use GHCs < 7.10 for bootstrapping. (I //could// make it all work without waiting, but it would be ugly. Far better to wait.) (There is no milestone 8.2. Or would it be 8.4?) We could also just change the interfaces while still storing `Integer`s internally. But that would have performance implications. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 19 18:56:20 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Sep 2015 18:56:20 -0000 Subject: [GHC] #10770: Typeable solver has strange effects In-Reply-To: <051.c272986722d18d60205f4faa0b3da2dc@haskell.org> References: <051.c272986722d18d60205f4faa0b3da2dc@haskell.org> Message-ID: <066.bfd19891e47b17d1fbce29f4e87a3d36@haskell.org> #10770: Typeable solver has strange effects -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * milestone: => 8.0.1 Comment: I have reason to believe that this will go away with visible type application (#5296). I'll add test cases to be sure. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 19 19:26:16 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Sep 2015 19:26:16 -0000 Subject: [GHC] #10900: Suggestions for improvement of the PatternSynonyms chapter in the User's Guide Message-ID: <045.3ca8c7c70c117f1fbb26e794adbec55f@haskell.org> #10900: Suggestions for improvement of the PatternSynonyms chapter in the User's Guide -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.10.2 Documentation | Keywords: | Operating System: Unknown/Multiple PatternSynonms | Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- I read the chapter on PatternSynonyms recently. Seems like a very useful feature! Here are my notes, in the same spirit as #10140. == 7.3.9 == * This section starts with a nice example of how pattern synonyms can make some code much clearer. No problems sofar. > Note that in this example, the pattern synonyms Int and Arrow can also be > used as expressions (they are bidirectional). * How can a pattern (synonym) possibly be used as an expression. They seem such different concepts. You say "bidirectional", but what are the directions? You mentioned "constructor-like" before, maybe it's something like that? * This could use an example. * Is `Arrow Int Int` an example of using a pattern synonym as an expression? * What about `pattern Maybe t`, can it also be used as an expression? Why is this not mentioned? What is it doing there anyway, it's not used in either of the functions `collectArgs`, `isInt` and `isIntEndo`. > This is not necessarily the case: unidirectional pattern synonyms can also be > declared with the following syntax * Ok. > We can give an explicit inversion of a pattern synonym using the > following syntax * What does inverting a pattern synonym mean? * You mentioned unidirectional and bidirectional pattern synonyms. Can I invert both? {{{ pattern Head x <- x:xs where Head x = [x] }}} * Weird syntax. But what does it //do//? (I'm very confused now) == 7.3.9.1 == > Either prefix or infix syntax can be used. * I have no idea what this refers to. > For implicitly bidirectional pattern synonyms * This is the first time you mention the word "implicit". > For unidirectional and explicitly-bidirectional pattern synonyms * Ok, now it's getting clear. There seem to be 3 types of pattern synonyms. I wish you had said this earlier. (goes back to read from the beginning: ok I guess the first time you mentioned bidirectional patttern synonyms, they were the implicit ones, and the "explicit inversion" stuff with the weird syntax are the explicit ones.) == 7.3.9.2 == {{{ import Data.Maybe( pattern Just ) }}} * This doesn't compile. It turns out I need the PatternSynonyms extension in the importing module, even though you said in the beginning "it is required for defining them, but //not// for using them". * I later found #10653, so that explains it. Maybe mention that ticket. == 7.3.9.3 == > In the common case where CReq is empty, (), it can be omitted altogether. * Why is it more common for CReq to empty than for CProv to be empty? * What if CProv is empty, but CReq isn't? * What if both are empty, can they both be omitted? > so function f is rejected because the type signature is Maybe a * I tried this example, and f is not rejected at all. **Bug**? == 7.3.9.4 == > A pattern synonym occurrence in a pattern is evaluated by first matching > against the pattern synonym itself, and then on the argument patterns. * Should be "against the //rhs// of the pattern synonym" I think. * This is tricky stuff. Why is pattern synonym semantics not just defined as 'textual substitution'? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 19 19:45:16 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Sep 2015 19:45:16 -0000 Subject: [GHC] #10891: `reify` doesn't find associated type families In-Reply-To: <046.9e704f075dee9514291b5d5766834bf9@haskell.org> References: <046.9e704f075dee9514291b5d5766834bf9@haskell.org> Message-ID: <061.9c74a689774ff9cf0617968488b3a4a7@haskell.org> #10891: `reify` doesn't find associated type families -------------------------------------+------------------------------------- Reporter: antalsz | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: type | families; newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by jstolarek): * cc: jstolarek (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 19 20:09:20 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Sep 2015 20:09:20 -0000 Subject: [GHC] #10653: PatternSynonyms should be imported/exported as part of the wildcard notation In-Reply-To: <049.0e5a3c33a167308dc99ecaed5730df14@haskell.org> References: <049.0e5a3c33a167308dc99ecaed5730df14@haskell.org> Message-ID: <064.4bd464e3338f781b1a07d8d4cceaf531@haskell.org> #10653: PatternSynonyms should be imported/exported as part of the wildcard notation -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: mpickering Type: feature request | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: | PatternSynonyms, pattern synonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): I just want to check that you really intend this to work {{{ module M( Maybe(P) ) where pattern P x y = (x, True, y) module N( T(P, X, Y) ) where import M( Maybe(..) ) data T = X | Y }}} Pattern synonym `P` has ''absolutely nothing'' to do with the `Maybe`, but as I understand it module `M` is legal under this proposal, and anyone going `import M( Maybe(..) )` will get `P` in scope. Then module `N` gets the `P` from the import, and attaches it to the also- unrelated data type `T`. I think it's all well-defined, but perhaps rather surprising. Is there a consensus that this is the behaviour we all want; or has it perhaps simply not been discussed? A possible restriction might be that you can only add `P` to an export of a data type `T` if `P`'s type has form `... -> T t1 ..tn`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 19 20:13:32 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Sep 2015 20:13:32 -0000 Subject: [GHC] #10726: Upgrade MingW-w64 distributions for windows In-Reply-To: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> References: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> Message-ID: <059.01dac327dc19fd3ad9a868f4d841fe06@haskell.org> #10726: Upgrade MingW-w64 distributions for windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: task | Status: merge Priority: normal | Milestone: 7.10.3 Component: Build System | Version: 7.11 Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9218 #9014 | Differential Revisions: Phab:D1123 #10435 | -------------------------------------+------------------------------------- Comment (by simonpj): Can someone be specific about what you'd like to see in 7.10.3. I assume the patch in comment:7. Anything else? There is some muttering above about "and the related response file fix" but what is that fix? Anything else? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 19 20:22:44 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Sep 2015 20:22:44 -0000 Subject: [GHC] #10726: Upgrade MingW-w64 distributions for windows In-Reply-To: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> References: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> Message-ID: <059.a8041b11c891e95187c641ffa7c526fa@haskell.org> #10726: Upgrade MingW-w64 distributions for windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: task | Status: merge Priority: normal | Milestone: 7.10.3 Component: Build System | Version: 7.11 Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9218 #9014 | Differential Revisions: Phab:D1123 #10435 | -------------------------------------+------------------------------------- Comment (by thomie): It concerns #10777 ( 296bc70b5ff6c853f2782e9ec5aa47a52110345e, already merged to the ghc-7.10 branch) and the patch from comment:7 (7b211b4e5a38efca437d76ea442495370da7cc9a). I updated https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 19 20:32:34 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Sep 2015 20:32:34 -0000 Subject: [GHC] #10653: PatternSynonyms should be imported/exported as part of the wildcard notation In-Reply-To: <049.0e5a3c33a167308dc99ecaed5730df14@haskell.org> References: <049.0e5a3c33a167308dc99ecaed5730df14@haskell.org> Message-ID: <064.618a0161abc8523ec5f0ac1ab0876f15@haskell.org> #10653: PatternSynonyms should be imported/exported as part of the wildcard notation -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: mpickering Type: feature request | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: | PatternSynonyms, pattern synonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Your examples agree with my understanding of this proposal. > A possible restriction might be that you can only add `P` to an export of a data type `T` if `P`'s type has form `... -> T t1 ..tn`. This has been suggested. I think it's a good idea. My guess is that it was removed because of concerns that the whole thing has to be resolved by the renamer. But I actually don't think this is problematic at all. The whole thing //is// resolved by the renamer. It's just that the typechecker does an extra validity check. One reason I like this restriction is that it agrees with our guiding principle: a library should be able to refactor what was previously a concrete type into an abstract one with pattern synonyms. Are there other opinions out there? And has anyone gone beyond Trac to solicit support? I've come around to thinking this is a good idea, but it would be nice to know that others do, too. Apologies if the answer to this is above -- only so many things can fit in my brain at once! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 19 20:34:49 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Sep 2015 20:34:49 -0000 Subject: [GHC] #10842: "Reactive" Template Haskell In-Reply-To: <050.6f7bb562017372f9e5bba0241a40c1a7@haskell.org> References: <050.6f7bb562017372f9e5bba0241a40c1a7@haskell.org> Message-ID: <065.c891e07091d2299039580aa208c50331@haskell.org> #10842: "Reactive" Template Haskell -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9699, #10391 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Just noting that I'm moving this out of my queue. If you want something like this to happen, please get others to agree, write a spec of the idea on a wiki page, beg for people to submit a patch, etc. Sounds like an interesting idea, but it needs to be fleshed out. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 19 20:47:17 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Sep 2015 20:47:17 -0000 Subject: [GHC] #10653: PatternSynonyms should be imported/exported as part of the wildcard notation In-Reply-To: <049.0e5a3c33a167308dc99ecaed5730df14@haskell.org> References: <049.0e5a3c33a167308dc99ecaed5730df14@haskell.org> Message-ID: <064.c956f7e38645eb059d6f89fd18db6729@haskell.org> #10653: PatternSynonyms should be imported/exported as part of the wildcard notation -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: mpickering Type: feature request | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: | PatternSynonyms, pattern synonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by mpickering): Richard is right that I removed it because I thought there was some worry that the typechecker would have to get involved but if he says not then I think it's a good idea. I'm of the opinion that without this, pattern synonyms are a bit useless but apart from the two requests from Thomas and Eric I don't think wider opinion has been solicited. I'll clean up the wiki page and post it to ghc-devs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 19 20:57:36 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Sep 2015 20:57:36 -0000 Subject: [GHC] #10900: Suggestions for improvement of the PatternSynonyms chapter in the User's Guide In-Reply-To: <045.3ca8c7c70c117f1fbb26e794adbec55f@haskell.org> References: <045.3ca8c7c70c117f1fbb26e794adbec55f@haskell.org> Message-ID: <060.ca8814146b9729beba9b93666de70c24@haskell.org> #10900: Suggestions for improvement of the PatternSynonyms chapter in the User's Guide -------------------------------------+------------------------------------- Reporter: thomie | Owner: mpickering Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.10.2 Resolution: | Keywords: | PatternSynonms Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by mpickering): * owner: => mpickering Comment: Thanks Thomas for the notes. I think much of the confusion around *pattern* synonyms is that the pattern part is (now) only a small part of what they are. A perhaps nicer way to think about them is as normal data constructors but not attached to a specific type like normal data constructors. After declaring a bidirectional synonym {{{ pattern P x = [x] }}} then `P` should behave (nearly) exactly like a data constructor but instead of constructing some type `Q`, constructs lists. I will try to improve this section whilst working on D1152. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 19 21:08:48 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Sep 2015 21:08:48 -0000 Subject: [GHC] #10890: Incorrect redundant import warning for type classes In-Reply-To: <045.1d7793ff19c595f6fc025366df90cb33@haskell.org> References: <045.1d7793ff19c595f6fc025366df90cb33@haskell.org> Message-ID: <060.162551c3bde132b4463cc4085c6467f3@haskell.org> #10890: Incorrect redundant import warning for type classes -------------------------------------+------------------------------------- Reporter: quchen | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by quchen): * cc: quchen (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 19 21:10:46 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Sep 2015 21:10:46 -0000 Subject: [GHC] #5296: Add explicit type applications In-Reply-To: <042.d7f5be0512efad8881e5f10e7830add1@haskell.org> References: <042.d7f5be0512efad8881e5f10e7830add1@haskell.org> Message-ID: <057.e98804466600ede0473ba476c96554be@haskell.org> #5296: Add explicit type applications -------------------------------------+------------------------------------- Reporter: dsf | Owner: goldfire Type: feature request | Status: new Priority: low | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.0.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: 1897 | Blocking: Related Tickets: #4466 | Differential Revisions: Phab:D1138 -------------------------------------+------------------------------------- Changes (by WrenThornton): * cc: wren@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 19 21:33:39 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Sep 2015 21:33:39 -0000 Subject: [GHC] #5296: Add explicit type applications In-Reply-To: <042.d7f5be0512efad8881e5f10e7830add1@haskell.org> References: <042.d7f5be0512efad8881e5f10e7830add1@haskell.org> Message-ID: <057.167be55ec7994094942b49a66fe55246@haskell.org> #5296: Add explicit type applications -------------------------------------+------------------------------------- Reporter: dsf | Owner: goldfire Type: feature request | Status: new Priority: low | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.0.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: 1897 | Blocking: Related Tickets: #4466 | Differential Revisions: Phab:D1138 -------------------------------------+------------------------------------- Comment (by WrenThornton): Replying to [comment:17 goldfire]: > I have two open design questions: > > 1. What to do with `:type` in GHCi? Suppose we have `pair :: forall a. a -> forall b. b -> (a,b)`. I ask `:type pair 3`. The real type of this expression is `forall b. b -> (a0, b)`, where `a0` is the type of the overloaded `3`. The problem is that this type loses the fact that we need `Num a0`. We could say `forall b. Num a0 => b -> (a0, b)`, which is a little closer. Would we report that without `-fprint-explicit-foralls`? It would be wrong to say `forall a b. Num a => b -> (a, b)` (as is done today, even with this patch) because we can't instantiate `a` with a further visible type application. IMO, the type `forall a b. Num a => b -> (a, b)` is wrong for the expression `(pair 3)` aka `(pair @a (fromInteger @a $3))`, because the type `a` is fixed, albeit unknown. My first inclination would be to say those expressions have type `iota a. Num a => forall b. b -> (a, b)`. Of course, I wouldn't expect most folks to know anything about the `iota` quantifier, so I probably wouldn't print it that way. Do we have a notation for metavariables yet? We could say `Num ?a => forall b. b -> (?a, b)` supposing `?a` is the way we write a metavariable (rather than that syntax being used by ImplicitParams). > 2. It would be nice to be able to say `3 @Int` instead of `(3 :: Int)`. I agree with spj here. There's not really any benefit in terms of expressibility nor brevity. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 19 22:56:55 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Sep 2015 22:56:55 -0000 Subject: [GHC] #10891: `reify` doesn't find associated type families In-Reply-To: <046.9e704f075dee9514291b5d5766834bf9@haskell.org> References: <046.9e704f075dee9514291b5d5766834bf9@haskell.org> Message-ID: <061.ca4977ad8cc9ac55d124a6c7b912299a@haskell.org> #10891: `reify` doesn't find associated type families -------------------------------------+------------------------------------- Reporter: antalsz | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: type | families; newcomer 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 osa1): Another question: Normally we don't fill `InstanceD` contents, probably because we can't anyway -- because we need source code for this, right? But we can still fill information about associated type instances. Should we do this or are there any problems with that? (maybe it's not possible etc.) (By `InstanceD` I mean the one generated for `ClassI`) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 19 23:50:53 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Sep 2015 23:50:53 -0000 Subject: [GHC] #10901: failing build of ghc in openSUSE with ncurses-6.0 Message-ID: <046.56ed3ec6ea0e0e43d43cc81f7b3aebcf@haskell.org> #10901: failing build of ghc in openSUSE with ncurses-6.0 -------------------------------------+------------------------------------- Reporter: mimi.vx | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.10.2 System | Keywords: | Operating System: Linux Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- build of GHC-7.10.2 in openSUSE:Factory always fails with: {{{ [ 530s] "/usr/bin/ghc" -o utils/ghc-pkg/dist/build/tmp/ghc-pkg -hisuf hi -osuf o -hcsuf hc -static -H32m -O -package-db libraries/bootstrapping.conf -hide-all-packages -i -iutils/ghc-pkg/. -iutils/ghc-pkg/dist/build -iutils/ghc-pkg/dist/build/autogen -Iutils/ghc- pkg/dist/build -Iutils/ghc-pkg/dist/build/autogen -optP-include -optPutils/ghc-pkg/dist/build/autogen/cabal_macros.h -package Cabal-1.22.4.0 -package base-4.7.0.1 -package bin-package-db-0.0.0.0 -package binary-0.7.5.0 -package bytestring-0.10.4.0 -package containers-0.5.5.1 -package directory-1.2.1.0 -package filepath-1.3.0.2 -package process-1.2.0.0 -package terminfo-0.4.0.1 -package unix-2.7.0.1 -XHaskell2010 -no-user-package-db -rtsopts -odir utils/ghc- pkg/dist/build -hidir utils/ghc-pkg/dist/build -stubdir utils/ghc- pkg/dist/build -optl-L'/home/abuild/rpmbuild/BUILD/ghc-7.10.2/libraries/terminfo/dist- boot/build' -optl-L'/home/abuild/rpmbuild/BUILD/ghc-7.10.2/libraries/bin- package-db/dist-boot/build' -optl-L'/home/abuild/rpmbuild/BUILD/ghc-7.10.2/libraries/Cabal/Cabal/dist- boot/build' -optl-L'/usr/lib/ghc-7.8.3/process-1.2.0.0' -optl-L'/usr/lib/ghc-7.8.3/pretty-1.1.1.1' -optl-L'/usr/lib/ghc-7.8.3/directory-1.2.1.0' -optl-L'/usr/lib/ghc-7.8.3/unix-2.7.0.1' -optl-L'/usr/lib/ghc-7.8.3/time-1.4.2' -optl-L'/usr/lib/ghc-7.8.3/old- locale-1.0.0.6' -optl-L'/usr/lib/ghc-7.8.3/filepath-1.3.0.2' -optl-L'/home/abuild/rpmbuild/BUILD/ghc-7.10.2/libraries/binary/dist- boot/build' -optl-L'/usr/lib/ghc-7.8.3/containers-0.5.5.1' -optl-L'/usr/lib/ghc-7.8.3/bytestring-0.10.4.0' -optl-L'/usr/lib/ghc-7.8.3/deepseq-1.3.0.2' -optl-L'/usr/lib/ghc-7.8.3/array-0.5.0.0' -optl-L'/usr/lib/ghc-7.8.3/base-4.7.0.1' -optl-L'/usr/lib/ghc-7.8.3 /integer-simple-0.1.1.0' -optl-L'/usr/lib/ghc-7.8.3/ghc-prim-0.3.1.0' -optl-L'/usr/lib/ghc-7.8.3/rts-1.0' -optl-ltinfo -optl-lrt -optl-lutil -optl-ldl -optl-lpthread -optl-lm -optl-lrt -optl-ldl -static -H32m -O -package-db libraries/bootstrapping.conf -hide-all-packages -i -iutils /ghc-pkg/. -iutils/ghc-pkg/dist/build -iutils/ghc-pkg/dist/build/autogen -Iutils/ghc-pkg/dist/build -Iutils/ghc-pkg/dist/build/autogen -optP- include -optPutils/ghc-pkg/dist/build/autogen/cabal_macros.h -package Cabal-1.22.4.0 -package base-4.7.0.1 -package bin-package-db-0.0.0.0 -package binary-0.7.5.0 -package bytestring-0.10.4.0 -package containers-0.5.5.1 -package directory-1.2.1.0 -package filepath-1.3.0.2 -package process-1.2.0.0 -package terminfo-0.4.0.1 -package unix-2.7.0.1 -XHaskell2010 -no-user-package-db -rtsopts utils/ghc- pkg/dist/build/Main.o utils/ghc-pkg/dist/build/Version.o [ 531s] /home/abuild/rpmbuild/BUILD/ghc-7.10.2/libraries/terminfo/dist- boot/build/libHSterminfo-0.4.0.1.a(Base.o): In function `c8bd_info': [ 531s] /tmp/ghc13028_0/ghc13028_6.o:(.text+0x1a1a): undefined reference to `cur_term' [ 531s] /tmp/ghc13028_0/ghc13028_6.o:(.text+0x1a1e): undefined reference to `cur_term' [ 531s] /home/abuild/rpmbuild/BUILD/ghc-7.10.2/libraries/terminfo/dist- boot/build/libHSterminfo-0.4.0.1.a(Base.o): In function `c8bw_info': [ 531s] /tmp/ghc13028_0/ghc13028_6.o:(.text+0x1b2a): undefined reference to `cur_term' [ 531s] /tmp/ghc13028_0/ghc13028_6.o:(.text+0x1b2e): undefined reference to `cur_term' [ 531s] /home/abuild/rpmbuild/BUILD/ghc-7.10.2/libraries/terminfo/dist- boot/build/libHSterminfo-0.4.0.1.a(Base.o): In function `s7EW_info': [ 531s] /tmp/ghc13028_0/ghc13028_6.o:(.text+0x1d02): undefined reference to `cur_term' [ 531s] /home/abuild/rpmbuild/BUILD/ghc-7.10.2/libraries/terminfo/dist- boot/build/libHSterminfo-0.4.0.1.a(Base.o):/tmp/ghc13028_0/ghc13028_6.o:(.text+0x1d06): more undefined references to `cur_term' follow [ 531s] collect2: error: ld returned 1 exit status [ 531s] utils/ghc-pkg/ghc.mk:46: recipe for target 'utils/ghc- pkg/dist/build/tmp/ghc-pkg' failed [ 531s] make[1]: *** [utils/ghc-pkg/dist/build/tmp/ghc-pkg] Error 1 [ 531s] make[1]: *** Waiting for unfinished jobs.... [ 536s] <> [ 540s] Makefile:71: recipe for target 'all' failed [ 540s] make: *** [all] Error 2 [ 540s] error: Bad exit status from /var/tmp/rpm-tmp.1kHoMD (%build) }}} in openSUSE was today updated ncurses to version 6.0 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 20 01:17:30 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Sep 2015 01:17:30 -0000 Subject: [GHC] #10891: `reify` doesn't find associated type families In-Reply-To: <046.9e704f075dee9514291b5d5766834bf9@haskell.org> References: <046.9e704f075dee9514291b5d5766834bf9@haskell.org> Message-ID: <061.094fa6c5fc9940f266c4e5a6e453b1fa@haskell.org> #10891: `reify` doesn't find associated type families -------------------------------------+------------------------------------- Reporter: antalsz | Owner: osa1 Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: type | families; newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: 1254 -------------------------------------+------------------------------------- Changes (by osa1): * owner: => osa1 * differential: => 1254 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 20 03:27:13 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Sep 2015 03:27:13 -0000 Subject: [GHC] #10653: PatternSynonyms should be imported/exported as part of the wildcard notation In-Reply-To: <049.0e5a3c33a167308dc99ecaed5730df14@haskell.org> References: <049.0e5a3c33a167308dc99ecaed5730df14@haskell.org> Message-ID: <064.420f97ec9994d8defe0aadb027406e9f@haskell.org> #10653: PatternSynonyms should be imported/exported as part of the wildcard notation -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: mpickering Type: feature request | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: | PatternSynonyms, pattern synonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by gridaphobe): > A possible restriction might be that you can only add P to an export of a data type T if P's type has form ... -> T t1 ..tn. I also prefer having this restriction. >Richard is right that I removed it because I thought there was some worry that the typechecker would have to get involved but if he says not then I think it's a good idea. As I recall, I had previously suggested that `T(..)` export '''every''' pattern with a type whose result is headed by `T`, which would have required running the typechecker just to determine which things `T(..)` refers to. This, I believe, is what was really concerning Simon. If on the other hand, the export list has to '''explicitly''' name patterns to associate with `T`, then we can do a simple validity/sanity check during typechecking, as Richard says. Thanks for forging ahead with this ticket Matthew! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 20 03:40:50 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Sep 2015 03:40:50 -0000 Subject: [GHC] #5296: Add explicit type applications In-Reply-To: <042.d7f5be0512efad8881e5f10e7830add1@haskell.org> References: <042.d7f5be0512efad8881e5f10e7830add1@haskell.org> Message-ID: <057.d4ad5fe3e0a488f549cfa834d50ce1b1@haskell.org> #5296: Add explicit type applications -------------------------------------+------------------------------------- Reporter: dsf | Owner: goldfire Type: feature request | Status: new Priority: low | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.0.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: 1897 | Blocking: Related Tickets: #4466 | Differential Revisions: Phab:D1138 -------------------------------------+------------------------------------- Comment (by goldfire): Thanks for the suggestion. Unfortunately, I think that `?a` looks too much like !ImplicitParams. But I do like the general idea. Here's a very, very radical thought: what if we use color? We could print `forall b. Num a => b -> (a, b)` but put `a` in a different color. (Even though it's a bit of a lie, I prefer putting the `forall b` before the `Num a`, only because Haskellers are much more used to that ordering.) Non-colored terminals still get all the information they need: that `b` is available for type application whereas `a` is not. But someone with color could see the needed information very easily. But something tells me it would be a major plumbing job to get color output... :( -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 20 03:48:01 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Sep 2015 03:48:01 -0000 Subject: [GHC] #10902: Refactor type families in Template Haskell Message-ID: <047.b25240b031d2012bf9d6cd9d3443b8ca@haskell.org> #10902: Refactor type families in Template Haskell -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Template | Version: 7.11 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- I see that we now have `OpenTypeFamilyD` and `ClosedTypeFamilyD` in Template Haskell. These constructors have quite a lot in common, and I think it's worth having a `TypeFamilyHead` datatype that contains the bits in common. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 20 03:51:35 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Sep 2015 03:51:35 -0000 Subject: [GHC] #10891: `reify` doesn't find associated type families In-Reply-To: <046.9e704f075dee9514291b5d5766834bf9@haskell.org> References: <046.9e704f075dee9514291b5d5766834bf9@haskell.org> Message-ID: <061.35b099c74c796af461778633c4ba6c2f@haskell.org> #10891: `reify` doesn't find associated type families -------------------------------------+------------------------------------- Reporter: antalsz | Owner: osa1 Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: type | families; newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:1254 -------------------------------------+------------------------------------- Changes (by goldfire): * differential: 1254 => Phab:1254 Comment: That's a good point. If it's easy to do, I think adding the associated type stuff would be nice. But don't go too far out of way to do it. Thanks for jumping in! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 20 08:55:14 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Sep 2015 08:55:14 -0000 Subject: [GHC] #10902: Refactor type families in Template Haskell In-Reply-To: <047.b25240b031d2012bf9d6cd9d3443b8ca@haskell.org> References: <047.b25240b031d2012bf9d6cd9d3443b8ca@haskell.org> Message-ID: <062.44c2a11523763a487922e5eeac2afe39@haskell.org> #10902: Refactor type families in Template Haskell -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.11 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by jstolarek): * cc: jstolarek (added) * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 20 09:39:40 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Sep 2015 09:39:40 -0000 Subject: [GHC] #9587: Type checking with type functions introduces many type variables, which remain ambiguous. The code no longer type checks. In-Reply-To: <043.f69d596cc0abdaf73ad7a995b5399971@haskell.org> References: <043.f69d596cc0abdaf73ad7a995b5399971@haskell.org> Message-ID: <058.984a2c5a2bb6c8664a2038f2e3d976cb@haskell.org> #9587: Type checking with type functions introduces many type variables, which remain ambiguous. The code no longer type checks. -------------------------------------+------------------------------------- Reporter: oleg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Keywords: type Resolution: | family, ambiguity check Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #9607 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by jstolarek): For the record, this code can now be compiled using injective type families: {{{#!hs {-# LANGUAGE NoMonomorphismRestriction #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE ScopedTypeVariables #-} module T9587 where type family Arr (repr :: * -> *) (a :: *) (b :: *) = (r :: *) | r -> repr a b class ESymantics repr where int :: Int -> repr Int add :: repr Int -> repr Int -> repr Int lam :: (repr a -> repr b) -> repr (Arr repr a b) app :: repr (Arr repr a b) -> repr a -> repr b te4 = let c3 = lam (\f -> lam (\x -> f `app` (f `app` (f `app` x)))) in (c3 `app` (lam (\x -> x `add` int 14))) `app` (int 0) }}} Not sure if that addresses the original problem because: a) `Arr` might not be injective at all b) if I understand correctly [comment:10 comment 10] the actual injectivity annotation on `Arr` is `r repr -> a b` and that is not supported yet -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 20 10:55:51 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Sep 2015 10:55:51 -0000 Subject: [GHC] #10510: Testsuite driver does not run tests in parallel on Windows In-Reply-To: <045.f7051a2be634cd79e52b8850db4fc44f@haskell.org> References: <045.f7051a2be634cd79e52b8850db4fc44f@haskell.org> Message-ID: <060.708e9b3e392846002f5c5d04ecc9f4bc@haskell.org> #10510: Testsuite driver does not run tests in parallel on Windows -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Test Suite | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Phyx-): Hmm could someone who's still getting this issue get a memory dump of the process that's blocking? I'd like to compare it to the one I had. Maybe that will give me more information on where in the msys2 runtime this happens.. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 20 11:56:37 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Sep 2015 11:56:37 -0000 Subject: [GHC] #10800: vector-0.11 compile time increased substantially with 7.10.1 In-Reply-To: <046.b08e48c7e3091b06d4d1122f9be87efe@haskell.org> References: <046.b08e48c7e3091b06d4d1122f9be87efe@haskell.org> Message-ID: <061.7820bc39eb4885482e9b206df6e396b9@haskell.org> #10800: vector-0.11 compile time increased substantially with 7.10.1 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): The culprit appears to be `tests/Tests/Vector.hs`, which seems to blow up in the simplifier with GHC 7.10.1, = 7.10.1 = {{{ [5 of 6] Compiling Tests.Vector ( tests/Tests/Vector.hs, dist/dist- sandbox-7565eaee/build/vector-tests-O2/vector-tests-O2-tmp/Tests/Vector.o ) *** Parser: *** Renamer/typechecker: *** Simplify: *** CorePrep: *** ByteCodeGen: ... *** Simplify: *** CorePrep: *** ByteCodeGen: *** Simplify: *** CorePrep: *** ByteCodeGen: *** Simplify: *** CorePrep: *** ByteCodeGen: *** Simplify: *** CorePrep: *** ByteCodeGen: *** Simplify: *** CorePrep: *** ByteCodeGen: *** Simplify: *** CorePrep: *** ByteCodeGen: *** Simplify: *** CorePrep: *** ByteCodeGen: *** Simplify: *** CorePrep: *** ByteCodeGen: *** Simplify: *** CorePrep: *** ByteCodeGen: *** Simplify: *** CorePrep: *** ByteCodeGen: *** Simplify: *** CorePrep: *** ByteCodeGen: tests/Tests/Vector.hs:20:1: Warning: The import of ?Data.Monoid? is redundant except perhaps to import instances from ?Data.Monoid? To import instances alone, use: import Data.Monoid() tests/Tests/Vector.hs:405:5: Warning: Defined but not used: ?limitUnfolds? tests/Tests/Vector.hs:408:5: Warning: Defined but not used: ?prop_unfoldr? tests/Tests/Vector.hs:615:1: Warning: Defined but not used: ?testBoolUnboxedVector? *** Desugar: Result size of Desugar (after optimization) = {terms: 8,929, types: 29,113, coercions: 12,626} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 7,718, types: 22,842, coercions: 12,683} Result size of Simplifier iteration=2 = {terms: 7,645, types: 22,550, coercions: 12,627} Result size of Simplifier = {terms: 7,645, types: 22,550, coercions: 12,627} *** Specialise: Result size of Specialise = {terms: 158,601, types: 473,559, coercions: 266,978} *** Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}): Result size of Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) = {terms: 191,838, types: 610,090, coercions: 266,978} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 341,716, types: 752,822, coercions: 950,308} Result size of Simplifier iteration=2 = {terms: 341,082, types: 678,899, coercions: 700,199} Result size of Simplifier iteration=3 = {terms: 324,911, types: 649,679, coercions: 477,703} Result size of Simplifier iteration=4 = {terms: 323,711, types: 646,845, coercions: 470,304} Result size of Simplifier = {terms: 323,711, types: 646,845, coercions: 470,304} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 2,421,941, types: 4,434,113, coercions: 2,600,098} Result size of Simplifier iteration=2 = {terms: 1,532,846, types: 2,868,287, coercions: 1,167,104} Result size of Simplifier iteration=3 = {terms: 1,333,796, types: 2,347,850, coercions: 910,168} Result size of Simplifier iteration=4 = {terms: 1,326,682, types: 2,333,558, coercions: 893,473} Result size of Simplifier = {terms: 1,326,682, types: 2,333,558, coercions: 893,473} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 2,517,661, types: 3,700,180, coercions: 1,244,341} Result size of Simplifier iteration=2 = {terms: 1,648,651, types: 2,362,735, coercions: 1,118,836} Result size of Simplifier iteration=3 = {terms: 1,533,366, types: 2,160,536, coercions: 1,018,335} Result size of Simplifier iteration=4 = {terms: 1,531,057, types: 2,158,142, coercions: 1,017,409} Result size of Simplifier = {terms: 1,531,057, types: 2,158,142, coercions: 1,017,409} *** Float inwards: Result size of Float inwards = {terms: 1,531,057, types: 2,158,142, coercions: 1,017,409} *** Called arity analysis: Result size of Called arity analysis = {terms: 1,531,057, types: 2,158,142, coercions: 1,017,409} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 1,525,383, types: 2,148,094, coercions: 1,012,837} Result size of Simplifier iteration=2 = {terms: 1,519,162, types: 2,137,087, coercions: 1,009,451} Result size of Simplifier iteration=3 = {terms: 1,518,511, types: 2,135,070, coercions: 1,008,419} Result size of Simplifier iteration=4 = {terms: 1,517,741, types: 2,133,682, coercions: 1,008,349} Result size of Simplifier = {terms: 1,517,741, types: 2,133,682, coercions: 1,008,349} *** Demand analysis: Result size of Demand analysis = {terms: 1,517,741, types: 2,133,682, coercions: 1,008,349} *** Worker Wrapper binds: Result size of Worker Wrapper binds = {terms: 1,638,656, types: 2,267,189, coercions: 1,016,585} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 1,581,976, types: 2,235,934, coercions: 1,015,794} Result size of Simplifier iteration=2 = {terms: 1,498,911, types: 2,130,083, coercions: 1,007,028} Result size of Simplifier iteration=3 = {terms: 1,498,641, types: 2,129,656, coercions: 1,007,547} Result size of Simplifier iteration=4 = {terms: 1,498,663, types: 2,129,564, coercions: 1,008,931} Result size of Simplifier = {terms: 1,498,663, types: 2,129,564, coercions: 1,008,931} *** Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True}): Result size of Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True}) = {terms: 1,574,915, types: 2,289,456, coercions: 1,008,931} *** Common sub-expression: Result size of Common sub-expression = {terms: 1,437,681, types: 2,110,200, coercions: 999,668} *** Float inwards: Result size of Float inwards = {terms: 1,437,681, types: 2,110,200, coercions: 999,668} *** Liberate case: Result size of Liberate case = {terms: 1,460,235, types: 2,122,207, coercions: 1,002,808} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 1,409,789, types: 2,018,248, coercions: 1,006,095} Result size of Simplifier iteration=2 = {terms: 1,409,904, types: 2,020,763, coercions: 1,004,750} Result size of Simplifier iteration=3 = {terms: 1,407,598, types: 2,016,738, coercions: 1,005,425} Result size of Simplifier iteration=4 = {terms: 1,407,068, types: 2,015,811, coercions: 1,003,311} Result size of Simplifier = {terms: 1,407,068, types: 2,015,811, coercions: 1,003,311} *** SpecConstr: Result size of SpecConstr = {terms: 2,875,513, types: 4,153,092, coercions: 1,868,890} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 2,811,029, types: 3,774,293, coercions: 1,781,476} Result size of Simplifier iteration=2 = {terms: 1,657,609, types: 2,285,271, coercions: 1,158,260} Result size of Simplifier iteration=3 = {terms: 1,634,476, types: 2,261,260, coercions: 1,111,721} Result size of Simplifier iteration=4 = {terms: 1,623,734, types: 2,229,084, coercions: 1,097,616} Result size of Simplifier = {terms: 1,623,734, types: 2,229,084, coercions: 1,097,616} *** Tidy Core: Result size of Tidy Core = {terms: 1,374,780, types: 1,868,771, coercions: 949,928} writeBinIface: 12038 Names writeBinIface: 14118 dict entries writeBinIface: 12038 Names writeBinIface: 14118 dict entries *** CorePrep: Result size of CorePrep = {terms: 1,742,444, types: 2,159,089, coercions: 949,848} *** Stg2Stg: *** CodeGen: *** Assembler: /usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -Itests/Tests -Idist/dist-sandbox-7565eaee/build/vector-tests-O2/vector-tests-O2-tmp -Idist/dist-sandbox-7565eaee/build/vector-tests-O2/vector-tests-O2-tmp -Idist/dist-sandbox-7565eaee/build/autogen -Idist/dist-sandbox- 7565eaee/build/vector-tests-O2/vector-tests-O2-tmp -x assembler -c /tmp/ghc32343_0/ghc32343_13.s -o dist/dist-sandbox-7565eaee/build/vector- tests-O2/vector-tests-O2-tmp/Tests/Vector.o *** CorePrep: Result size of CorePrep = {terms: 1,742,444, types: 2,159,089, coercions: 949,848} }}} This is a substantial change from 7.8.3, which behaves as follows, = 7.8.3 = {{{ [5 of 6] Compiling Tests.Vector ( tests/Tests/Vector.hs, dist/dist- sandbox-8a24a56a/build/vector-tests-O2/vector-tests-O2-tmp/Tests/Vector.o ) *** Parser: *** Renamer/typechecker: *** Simplify: *** CorePrep: *** ByteCodeGen: *** Simplify: *** CorePrep: *** ByteCodeGen: *** Simplify: *** CorePrep: *** ByteCodeGen: *** Simplify: *** CorePrep: *** ByteCodeGen: *** Simplify: *** CorePrep: *** ByteCodeGen: *** Simplify: *** CorePrep: *** ByteCodeGen: *** Simplify: *** CorePrep: *** ByteCodeGen: *** Simplify: *** CorePrep: *** ByteCodeGen: *** Simplify: *** CorePrep: *** ByteCodeGen: *** Simplify: *** CorePrep: *** ByteCodeGen: *** Simplify: *** CorePrep: *** ByteCodeGen: *** Simplify: *** CorePrep: *** ByteCodeGen: tests/Tests/Vector.hs:405:5: Warning: Defined but not used: ?limitUnfolds? tests/Tests/Vector.hs:408:5: Warning: Defined but not used: ?prop_unfoldr? tests/Tests/Vector.hs:615:1: Warning: Defined but not used: ?testBoolUnboxedVector? *** Desugar: Result size of Desugar (after optimization) = {terms: 11,244, types: 57,883, coercions: 7,302} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 9,193, types: 44,105, coercions: 7,337} Result size of Simplifier iteration=2 = {terms: 9,116, types: 43,718, coercions: 7,159} Result size of Simplifier = {terms: 9,116, types: 43,718, coercions: 7,159} *** Specialise: Result size of Specialise = {terms: 82,833, types: 519,765, coercions: 78,989} *** Float out(FOS {Lam = Just 0, Consts = True, PAPs = False}): Result size of Float out(FOS {Lam = Just 0, Consts = True, PAPs = False}) = {terms: 100,958, types: 568,910, coercions: 78,989} *** Float inwards: Result size of Float inwards = {terms: 100,958, types: 568,910, coercions: 78,989} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 179,170, types: 343,254, coercions: 645,024} Result size of Simplifier iteration=2 = {terms: 123,469, types: 170,930, coercions: 259,665} Result size of Simplifier iteration=3 = {terms: 113,030, types: 155,318, coercions: 230,494} Result size of Simplifier iteration=4 = {terms: 112,745, types: 154,554, coercions: 221,711} Result size of Simplifier = {terms: 112,745, types: 154,554, coercions: 221,711} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 515,401, types: 809,314, coercions: 598,712} Result size of Simplifier iteration=2 = {terms: 345,742, types: 520,083, coercions: 376,036} Result size of Simplifier iteration=3 = {terms: 294,322, types: 416,385, coercions: 312,220} Result size of Simplifier iteration=4 = {terms: 287,445, types: 402,244, coercions: 297,516} Result size of Simplifier = {terms: 287,445, types: 402,244, coercions: 297,516} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 453,076, types: 567,575, coercions: 280,117} Result size of Simplifier iteration=2 = {terms: 321,815, types: 378,160, coercions: 222,556} Result size of Simplifier iteration=3 = {terms: 309,758, types: 365,364, coercions: 219,987} Result size of Simplifier iteration=4 = {terms: 308,628, types: 364,331, coercions: 219,583} Result size of Simplifier = {terms: 308,628, types: 364,331, coercions: 219,583} *** Demand analysis: Result size of Demand analysis = {terms: 308,628, types: 364,331, coercions: 219,583} *** Worker Wrapper binds: Result size of Worker Wrapper binds = {terms: 352,621, types: 419,343, coercions: 223,102} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 334,327, types: 396,352, coercions: 217,632} Result size of Simplifier iteration=2 = {terms: 297,776, types: 344,782, coercions: 211,762} Result size of Simplifier iteration=3 = {terms: 297,134, types: 343,498, coercions: 211,068} Result size of Simplifier iteration=4 = {terms: 296,791, types: 342,860, coercions: 211,033} Result size of Simplifier = {terms: 296,791, types: 342,860, coercions: 211,033} *** Float out(FOS {Lam = Just 0, Consts = True, PAPs = True}): Result size of Float out(FOS {Lam = Just 0, Consts = True, PAPs = True}) = {terms: 311,717, types: 380,250, coercions: 211,033} *** Common sub-expression: Result size of Common sub-expression = {terms: 281,729, types: 346,991, coercions: 196,315} *** Float inwards: Result size of Float inwards = {terms: 281,729, types: 346,991, coercions: 196,315} *** Liberate case: Result size of Liberate case = {terms: 301,329, types: 362,935, coercions: 200,458} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 281,187, types: 322,484, coercions: 200,278} Result size of Simplifier iteration=2 = {terms: 279,511, types: 320,001, coercions: 199,549} Result size of Simplifier = {terms: 279,511, types: 320,001, coercions: 199,549} *** SpecConstr: Result size of SpecConstr = {terms: 398,168, types: 420,420, coercions: 230,461} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 390,005, types: 411,465, coercions: 230,270} Result size of Simplifier iteration=2 = {terms: 272,588, types: 315,504, coercions: 201,634} Result size of Simplifier iteration=3 = {terms: 269,759, types: 310,458, coercions: 200,366} Result size of Simplifier = {terms: 269,759, types: 310,458, coercions: 200,366} *** Tidy Core: Result size of Tidy Core = {terms: 269,759, types: 310,458, coercions: 200,366} writeBinIface: 518 Names writeBinIface: 694 dict entries writeBinIface: 518 Names writeBinIface: 694 dict entries *** CorePrep: Result size of CorePrep = {terms: 341,307, types: 360,564, coercions: 200,286} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 20 12:08:44 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Sep 2015 12:08:44 -0000 Subject: [GHC] #10800: vector-0.11 compile time increased substantially with 7.10.1 In-Reply-To: <046.b08e48c7e3091b06d4d1122f9be87efe@haskell.org> References: <046.b08e48c7e3091b06d4d1122f9be87efe@haskell.org> Message-ID: <061.704709d546a2ccfeac8cb40bccaec8ad@haskell.org> #10800: vector-0.11 compile time increased substantially with 7.10.1 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): This is also reproducible with 7.11. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 20 12:23:24 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Sep 2015 12:23:24 -0000 Subject: [GHC] #8832: Constant-folding regression wrt `clearBit (bit 0) 0 ` In-Reply-To: <042.89bb0eec284b44a45a7b0586c22bb7a4@haskell.org> References: <042.89bb0eec284b44a45a7b0586c22bb7a4@haskell.org> Message-ID: <057.796ec72dbc5afe875f8cf14cf92d9fe5@haskell.org> #8832: Constant-folding regression wrt `clearBit (bit 0) 0 ` -------------------------------------+------------------------------------- Reporter: hvr | Owner: bgamari Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Core Libraries | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | simplCore/should_compile/T8832 Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1255 -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D1255 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 20 15:06:38 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Sep 2015 15:06:38 -0000 Subject: [GHC] #10901: failing build of ghc in openSUSE with ncurses-6.0 In-Reply-To: <046.56ed3ec6ea0e0e43d43cc81f7b3aebcf@haskell.org> References: <046.56ed3ec6ea0e0e43d43cc81f7b3aebcf@haskell.org> Message-ID: <061.59280b09ae0e8bea671263b525e5878d@haskell.org> #10901: failing build of ghc in openSUSE with ncurses-6.0 -------------------------------------+------------------------------------- Reporter: mimi.vx | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by mimi.vx): ncurses 6.0 doesn't export function cur_term, {{{ $ readelf -a libncurses.so.6 | grep cur_term 000000228328 006d00000007 R_X86_64_JUMP_SLO 0000000000000000 _nc_cur_term + 0 109: 0000000000000000 0 FUNC GLOBAL DEFAULT UND _nc_cur_term at NCURSES6_TINFO_5.7.20081102 (24) $ readelf -a libncurses.so.5 | grep cur_term 000000225f70 003900000006 R_X86_64_GLOB_DAT 0000000000000000 cur_term + 0 57: 0000000000000000 0 OBJECT GLOBAL DEFAULT UND cur_term at NCURSES_TINFO_5.0.19991023 (29) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 20 15:19:10 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Sep 2015 15:19:10 -0000 Subject: [GHC] #10800: vector-0.11 compile time increased substantially with 7.10.1 In-Reply-To: <046.b08e48c7e3091b06d4d1122f9be87efe@haskell.org> References: <046.b08e48c7e3091b06d4d1122f9be87efe@haskell.org> Message-ID: <061.b8004a9e568226cf4c759f575b23666e@haskell.org> #10800: vector-0.11 compile time increased substantially with 7.10.1 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): I have cut down the `tests/Tests/Vector.hs` file from `vector` commit `e000d6c50e68f539a6f6cfa35fe91350a0691499` to something a bit more minimal that may still exhibit a similar slow-down. The result is the following, {{{#!hs module Tests.Vector (tests) where import Boilerplater import Utilities as Util import qualified Data.Vector.Generic as V import qualified Data.Vector import Test.QuickCheck import Test.Framework import Test.Framework.Providers.QuickCheck2 import Data.List #define COMMON_CONTEXT(a, v) \ VANILLA_CONTEXT(a, v), VECTOR_CONTEXT(a, v) #define VANILLA_CONTEXT(a, v) \ Eq a, Show a, Arbitrary a, CoArbitrary a, TestData a, Model a ~ a, EqTest a ~ Property #define VECTOR_CONTEXT(a, v) \ Eq (v a), Show (v a), Arbitrary (v a), CoArbitrary (v a), TestData (v a), Model (v a) ~ [a], EqTest (v a) ~ Property, V.Vector v a testTuplyFunctions:: forall a v. (COMMON_CONTEXT(a, v), VECTOR_CONTEXT((a, a), v), VECTOR_CONTEXT((a, a, a), v)) => v a -> [Test] testTuplyFunctions _ = $(testProperties ['prop_unzip3]) where prop_unzip3 :: P (v (a, a, a) -> (v a, v a, v a)) = V.unzip3 `eq` unzip3 tests = [ testGroup "Data.Vector.Vector (Bool)" (testTuplyFunctions (undefined :: Data.Vector.Vector Bool)) ] }}} GHC 7.10.1 takes around 30% longer than 7.8.3 with this simple example, with the program size peaking at 10000 terms during specialization, as opposed to 7.8 which never goes above 400 terms. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 20 15:34:33 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Sep 2015 15:34:33 -0000 Subject: [GHC] #10901: failing build of ghc in openSUSE with ncurses-6.0 In-Reply-To: <046.56ed3ec6ea0e0e43d43cc81f7b3aebcf@haskell.org> References: <046.56ed3ec6ea0e0e43d43cc81f7b3aebcf@haskell.org> Message-ID: <061.18fa47ffdd72ea6d95c601e8cf2e1343@haskell.org> #10901: failing build of ghc in openSUSE with ncurses-6.0 -------------------------------------+------------------------------------- Reporter: mimi.vx | Owner: Type: bug | Status: upstream Priority: normal | Milestone: Component: Build System | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => upstream Comment: Thanks for opening https://github.com/judah/terminfo/issues/7. It should be fixed there first, after which we can update the terminfo submodule in the ghc repository. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 20 17:01:19 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Sep 2015 17:01:19 -0000 Subject: [GHC] #365: GHC dies silently with faulty preprocessor In-Reply-To: <045.970f5372032e408119e71a3210b4ecaf@haskell.org> References: <045.970f5372032e408119e71a3210b4ecaf@haskell.org> Message-ID: <060.553780759c1d1bbf06deefb7c929377c@haskell.org> #365: GHC dies silently with faulty preprocessor -------------------------------------+------------------------------------- Reporter: josefs | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T365 Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1256 -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => patch * testcase: => T365 * differential: => Phab:D1256 Comment: Added a patch so it doesn't silently die. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 20 17:01:36 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Sep 2015 17:01:36 -0000 Subject: [GHC] #365: GHC dies silently with faulty preprocessor In-Reply-To: <045.970f5372032e408119e71a3210b4ecaf@haskell.org> References: <045.970f5372032e408119e71a3210b4ecaf@haskell.org> Message-ID: <060.a7aec91f64bc18e3ea036e6d5ec32395@haskell.org> #365: GHC dies silently with faulty preprocessor -------------------------------------+------------------------------------- Reporter: josefs | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T365 Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1256 -------------------------------------+------------------------------------- Changes (by Phyx-): * owner: => Phyx- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 20 17:08:46 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Sep 2015 17:08:46 -0000 Subject: [GHC] #10890: Incorrect redundant import warning for type classes In-Reply-To: <045.1d7793ff19c595f6fc025366df90cb33@haskell.org> References: <045.1d7793ff19c595f6fc025366df90cb33@haskell.org> Message-ID: <060.7a1f5e4b945ac323e402f47eab2a7f5a@haskell.org> #10890: Incorrect redundant import warning for type classes -------------------------------------+------------------------------------- Reporter: quchen | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by osa1): I started to think like my experimental patch doesn't make things any worse, but fixes some of the cases. I'll test it a little bit more and probably open a Phab ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 20 17:16:39 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Sep 2015 17:16:39 -0000 Subject: [GHC] #10800: vector-0.11 compile time increased substantially with 7.10.1 In-Reply-To: <046.b08e48c7e3091b06d4d1122f9be87efe@haskell.org> References: <046.b08e48c7e3091b06d4d1122f9be87efe@haskell.org> Message-ID: <061.ef01709fc44053050027fc1080123b8d@haskell.org> #10800: vector-0.11 compile time increased substantially with 7.10.1 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): Well this potentially is interesting... `vector`'s test suite defines a type class `TestData`, {{{#!hs class (Testable (EqTest a), Conclusion (EqTest a)) => TestData a where type Model a model :: a -> Model a unmodel :: Model a -> a type EqTest a equal :: a -> a -> EqTest a }}} The `-ddump-simpl` output produced by 7.10 contains a variety of bindings referring to types containing `Model`, e.g., {{{#!hs lvl18 :: Model (Vector (Bool, Bool, Bool) -> (Vector Bool, Vector Bool, Vector Bool)) -> Vector (Bool, Bool, Bool) -> (Vector Bool, Vector Bool, Vector Bool) }}} whereas the Core produced by 7.8 contains no such references. I'm not sure whether this is problematic or not The simplified testcase above produces 6500 lines of Core in 7.10 and around 800 with 7.8. Despite the failure to resolve the `Model` type family, 7.10 seems to generally be doing more simplification. I believe much of the difference is due to the fact that 7.10 inlines the `$fTestData(,,)` dictionary whereas 7.8 does not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 20 17:42:43 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Sep 2015 17:42:43 -0000 Subject: [GHC] #10895: "no output will be generated" should be an error, not a warning. In-Reply-To: <047.f8da814851ed39c21e13b0c3f92e534f@haskell.org> References: <047.f8da814851ed39c21e13b0c3f92e534f@haskell.org> Message-ID: <062.2ec474cad49148a33b33534a22367859@haskell.org> #10895: "no output will be generated" should be an error, not a warning. -------------------------------------+------------------------------------- Reporter: gershomb | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1253 -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"1637e4d16d28223aac66100cf7308d76a2a7ee7c/ghc" 1637e4d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1637e4d16d28223aac66100cf7308d76a2a7ee7c" Driver: --make -o without Main should be an error (#10895) Reviewed by: austin Differential Revision: https://phabricator.haskell.org/D1253 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 20 17:43:49 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Sep 2015 17:43:49 -0000 Subject: [GHC] #10895: "no output will be generated" should be an error, not a warning. In-Reply-To: <047.f8da814851ed39c21e13b0c3f92e534f@haskell.org> References: <047.f8da814851ed39c21e13b0c3f92e534f@haskell.org> Message-ID: <062.b1f05f97b46152f379b86d336fc09719@haskell.org> #10895: "no output will be generated" should be an error, not a warning. -------------------------------------+------------------------------------- Reporter: gershomb | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | driver/should_fail/T10895 Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1253 -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => closed * testcase: => driver/should_fail/T10895 * resolution: => fixed Comment: Thanks for the suggestion. Should be fixed in ghc-8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 20 18:34:52 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Sep 2015 18:34:52 -0000 Subject: [GHC] #10890: Incorrect redundant import warning for type classes In-Reply-To: <045.1d7793ff19c595f6fc025366df90cb33@haskell.org> References: <045.1d7793ff19c595f6fc025366df90cb33@haskell.org> Message-ID: <060.8ec231b7aab67ffda3b7e1853b312273@haskell.org> #10890: Incorrect redundant import warning for type classes -------------------------------------+------------------------------------- Reporter: quchen | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: D1257 -------------------------------------+------------------------------------- Changes (by osa1): * status: new => patch * differential: => D1257 Comment: Thanks to @quchen for realizing that my patch reduces to previous version if there's only one imported `RdrName` with same name. I created a patch for this and I'll be adding tests soon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 20 20:17:19 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Sep 2015 20:17:19 -0000 Subject: [GHC] #10857: "ghci -XMonomorphismRestriction" doesn't turn on the monomorphism restriction In-Reply-To: <047.0bca38b39289a4db2d373be62522bc3d@haskell.org> References: <047.0bca38b39289a4db2d373be62522bc3d@haskell.org> Message-ID: <062.8a2e8221240dab5f11c50a136746b210@haskell.org> #10857: "ghci -XMonomorphismRestriction" doesn't turn on the monomorphism restriction -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: cocreature Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #3202, #3217 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by cocreature): Hey, I looked into this and it turns out it's actually not that easy to move it to an earlier point because those options should be in the interactive DynFlags which we set only after we have overwritten the DynFlags using the command line arguments. Now there is an easy solution which consists of just putting it in the standard DynFlags instead of the interactive ones. In fact we already do this for [https://github.com/ghc/ghc/blob/master/ghc/Main.hs#L182 another flag]. This works just fine but obviously some tests fail now since it is now not limited to the interactive flags. The other option is to set all of the interactive DynFlags earlier, but it looks like we then need to have two different set of flags, modify both of them by the command line arguments and then set them. This does not seem like a very nice solution either. If you are okay with putting it not in the interactive dynflags, then that's definitely the easiest solution, but as I am not really happy with that myself I'll think about it a bit more and try to come up with a less hacky solution. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 20 20:18:32 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Sep 2015 20:18:32 -0000 Subject: [GHC] #10890: Incorrect redundant import warning for type classes In-Reply-To: <045.1d7793ff19c595f6fc025366df90cb33@haskell.org> References: <045.1d7793ff19c595f6fc025366df90cb33@haskell.org> Message-ID: <060.4b117563debe173271b7b3e4c5a2a21d@haskell.org> #10890: Incorrect redundant import warning for type classes -------------------------------------+------------------------------------- Reporter: quchen | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1257 -------------------------------------+------------------------------------- Changes (by thomie): * differential: D1257 => Phab:D1257 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 20 20:39:44 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Sep 2015 20:39:44 -0000 Subject: [GHC] #10715: Possible regression in Coercible a (X a) between 7.8 and 7.10 In-Reply-To: <044.cc1e9df1bbafaf4fb6388749f2b76941@haskell.org> References: <044.cc1e9df1bbafaf4fb6388749f2b76941@haskell.org> Message-ID: <059.21b25443fd735dc9d3fe2f2e9975458a@haskell.org> #10715: Possible regression in Coercible a (X a) between 7.8 and 7.10 -------------------------------------+------------------------------------- Reporter: inaki | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:11 nomeata]: > Richard , would it be unreasonable to support recursive newtypes where the occurrences of the newtype are all in phantom positions? In a word: maybe. Though I haven't actually sat down to prove it, I very strongly suspect that solving for `Coercible` is undecidable in the presence of recursive newtypes. In effect, we are solving for equirecursive type equality. This can be done, but the algorithm I have to hand (from Pierce's TAPL, Chapter 21) requires (translating to the language of `Coercible`) that there be only one way to decompose an equality. But that's not true here! If we have `[W] N a ~R N b`, where `N` is a newtype, there are //two// ways forward: unwrap the newtype and try again, or look at the type parameters `a` and `b` (according to `N`'s parameter's role). So Pierce's algorithm doesn't work out. We are left, then, with an incomplete algorithm. I'm confident that we could keep adding special cases to this algorithm to cover yet-weirder scenarios, but I think it's best to wait until we have a better motivation. (This ticket doesn't qualify, because there is a better way to do what the author wants.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 20 22:00:00 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Sep 2015 22:00:00 -0000 Subject: [GHC] #10844: CallStack should not be inlined In-Reply-To: <046.c5d6c4205be9804afd3acc1b71ee4c7b@haskell.org> References: <046.c5d6c4205be9804afd3acc1b71ee4c7b@haskell.org> Message-ID: <061.b1ea5383344037a67231c2741373f35c@haskell.org> #10844: CallStack should not be inlined -------------------------------------+------------------------------------- Reporter: nomeata | Owner: gridaphobe Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by gridaphobe): Sorry to be slow here. I've been investigating this more today, trying to get GHC to not inline CallStacks. I can tell GHC to not inline Ids with an `IP CallStack` type by adding a special case to `CoreUnfold.callSiteInline` and `SimplUtils.{pre,post}InlineUnconditionally`, but this doesn't seem to be good enough. In Joachim's minimal example (thanks by the way!) the CallStack ''still'' ends up in `T10844`. I've posted the output of `-dverbose-core2core` with what I believe to be the relevant portion highlighted. https://gist.github.com/gridaphobe/fd9f313d7d91be405f01#file- gistfile1-txt-L773-L981 You can see that the pieces of the CallStack have just been floated out to the top-level, but `$cfoo`s unfolding still contains the whole CallStack instead of just a reference to the newly-created binder. So it seems that we want to tell the simplifier to update the unfolding when a CallStack is floated out. Is that a reasonable thing to do? (Sorry, my knowledge of this part of GHC is very limited) As an alternative, perhaps we could revise how CallStacks are desugared. If we could tell the Desugarer to translate CallStack evidence into exported binders instead of local binders, we could mark those binders as NOINLINE. This approach seems like it would be less brittle. (My WIP branch is at https://github.com/gridaphobe/ghc.git, branch `noinline-callstacks`) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 00:19:57 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 00:19:57 -0000 Subject: [GHC] #10653: PatternSynonyms should be imported/exported as part of the wildcard notation In-Reply-To: <049.0e5a3c33a167308dc99ecaed5730df14@haskell.org> References: <049.0e5a3c33a167308dc99ecaed5730df14@haskell.org> Message-ID: <064.f4116faee49ff7534e2d683b31c32a17@haskell.org> #10653: PatternSynonyms should be imported/exported as part of the wildcard notation -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: mpickering Type: feature request | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: | PatternSynonyms, pattern synonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1258 -------------------------------------+------------------------------------- Changes (by mpickering): * differential: => Phab:D1258 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 01:41:50 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 01:41:50 -0000 Subject: [GHC] #10853: Refine addTopDecls In-Reply-To: <047.c86dd8a253022fe77935e07f26b94dc1@haskell.org> References: <047.c86dd8a253022fe77935e07f26b94dc1@haskell.org> Message-ID: <062.714c929ad0b7d2074ec75a4ba10e849f@haskell.org> #10853: Refine addTopDecls -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by osa1): Sorry if this is completely unrelated, but I realized this weird behavior while implementing #10891. Let's say I have this: {{{#!haskell {-# LANGUAGE TemplateHaskell #-} module Main where import Language.Haskell.TH import System.IO data D = A Int | B Bool test = $(... reify ''D ...) main :: IO () main = return () }}} This fails with: {{{ Main.hs:11:5: ?D? is not in the type environment at a reify }}} But if I add this line between the splice and `D`: {{{ $(return []) }}} Suddenly it works. I couldn't find anything about regions in the wiki, but how do we split this program into regions and how do we explain this seemingly weird behavior? It seems like we can improve the way we evaluate TH splices. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 01:42:41 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 01:42:41 -0000 Subject: [GHC] #10844: CallStack should not be inlined In-Reply-To: <046.c5d6c4205be9804afd3acc1b71ee4c7b@haskell.org> References: <046.c5d6c4205be9804afd3acc1b71ee4c7b@haskell.org> Message-ID: <061.2a50e2789acc6d26b6401117e406b331@haskell.org> #10844: CallStack should not be inlined -------------------------------------+------------------------------------- Reporter: nomeata | Owner: gridaphobe Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: D1259 -------------------------------------+------------------------------------- Changes (by gridaphobe): * status: new => patch * differential: => D1259 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 01:43:34 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 01:43:34 -0000 Subject: [GHC] #10772: Type operator variable in prefix notation fails In-Reply-To: <046.ab9a1e8aa534bcd6d1b2f12748c0ce5a@haskell.org> References: <046.ab9a1e8aa534bcd6d1b2f12748c0ce5a@haskell.org> Message-ID: <061.2ea016670efc618bb7e2947ef8d5d872@haskell.org> #10772: Type operator variable in prefix notation fails -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"d19a77ab420dec1dbd9c95744b987283ef5aa4cc/ghc" d19a77ab/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d19a77ab420dec1dbd9c95744b987283ef5aa4cc" Update user guide, fixing #10772 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 01:43:34 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 01:43:34 -0000 Subject: [GHC] #10347: Spurious "unused constructor" warning with Coercible In-Reply-To: <047.95d70bb35e967b5051d311b602ee2dc7@haskell.org> References: <047.95d70bb35e967b5051d311b602ee2dc7@haskell.org> Message-ID: <062.4ae3ff8cba01720c78d0a03827c4768e@haskell.org> #10347: Spurious "unused constructor" warning with Coercible -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"1a135511344f14deca314cb38cedda4bcfe53dc0/ghc" 1a135511/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1a135511344f14deca314cb38cedda4bcfe53dc0" Test #10347 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 01:43:34 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 01:43:34 -0000 Subject: [GHC] #10770: Typeable solver has strange effects In-Reply-To: <051.c272986722d18d60205f4faa0b3da2dc@haskell.org> References: <051.c272986722d18d60205f4faa0b3da2dc@haskell.org> Message-ID: <066.9f8b66ea17fa5df80c7447636c0d2d53@haskell.org> #10770: Typeable solver has strange effects -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"d7f2ab05494aac0561a19d75e6c4a9fccca24554/ghc" d7f2ab0/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d7f2ab05494aac0561a19d75e6c4a9fccca24554" Test #10770 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 01:43:34 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 01:43:34 -0000 Subject: [GHC] #10811: Template Haskell does associated types poorly (printing & quoting) In-Reply-To: <047.eefd4e69268b49667f9aa1e189a8806f@haskell.org> References: <047.eefd4e69268b49667f9aa1e189a8806f@haskell.org> Message-ID: <062.fedbcf18c355a43c5b8c1a67091344ba@haskell.org> #10811: Template Haskell does associated types poorly (printing & quoting) -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"1292c17e61400dfa0c27eddff4bea6a935006657/ghc" 1292c17e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1292c17e61400dfa0c27eddff4bea6a935006657" Allow TH quoting of assoc type defaults. This fixes #10811. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 01:43:34 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 01:43:34 -0000 Subject: [GHC] #10811: Template Haskell does associated types poorly (printing & quoting) In-Reply-To: <047.eefd4e69268b49667f9aa1e189a8806f@haskell.org> References: <047.eefd4e69268b49667f9aa1e189a8806f@haskell.org> Message-ID: <062.e251a7be8c5337b7ab2cc370996b285f@haskell.org> #10811: Template Haskell does associated types poorly (printing & quoting) -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"79b8e891d88bd4018e31be042364e314a25fbb41/ghc" 79b8e89/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="79b8e891d88bd4018e31be042364e314a25fbb41" Print associated types a bit better. This is part of #10811. It removes the "family" keyword from associated type family declarations, and it adds the "type" keyword to associated type family defaults. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 01:43:34 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 01:43:34 -0000 Subject: [GHC] #10810: Data constructor operators mis-printed in Template Haskell In-Reply-To: <047.9a0eacfe35e8d9bc3ca01ce57985f5f2@haskell.org> References: <047.9a0eacfe35e8d9bc3ca01ce57985f5f2@haskell.org> Message-ID: <062.5c4026c1eb30e829412f7ba6f830072c@haskell.org> #10810: Data constructor operators mis-printed in Template Haskell -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"6a2092050c14570b9131fb5189c96dc562713b4c/ghc" 6a20920/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6a2092050c14570b9131fb5189c96dc562713b4c" Small improvement in pretty-printing constructors. This fixes #10810 by cleaning up pretty-printing of constructor declarations. This change also removes a (in my opinion) deeply bogus orphan instance OutputableBndr [Located name], making HsDecls now a non-orphan module. Yay all around. Test case: th/T10810 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 01:43:34 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 01:43:34 -0000 Subject: [GHC] #10855: GHC rejects code that Haskell 2010 report accepts In-Reply-To: <047.18e6e77fdcbdaa2d5abe96a152166a71@haskell.org> References: <047.18e6e77fdcbdaa2d5abe96a152166a71@haskell.org> Message-ID: <062.62718c0224759ccc352392f548989d18@haskell.org> #10855: GHC rejects code that Haskell 2010 report accepts -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"27f9186d8e35387c3f48f848ff3b2c8e967a9c97/ghc" 27f9186d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="27f9186d8e35387c3f48f848ff3b2c8e967a9c97" Clarify parsing infelicity. This fixes #10855. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 01:52:03 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 01:52:03 -0000 Subject: [GHC] #10772: Type operator variable in prefix notation fails In-Reply-To: <046.ab9a1e8aa534bcd6d1b2f12748c0ce5a@haskell.org> References: <046.ab9a1e8aa534bcd6d1b2f12748c0ce5a@haskell.org> Message-ID: <061.43b83193b99684d8f338d8b8b32ddd2e@haskell.org> #10772: Type operator variable in prefix notation fails -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.3 Component: Documentation | Version: 7.11 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 goldfire): * status: new => merge * milestone: => 7.10.3 Comment: May as well merge. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 01:52:47 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 01:52:47 -0000 Subject: [GHC] #10347: Spurious "unused constructor" warning with Coercible In-Reply-To: <047.95d70bb35e967b5051d311b602ee2dc7@haskell.org> References: <047.95d70bb35e967b5051d311b602ee2dc7@haskell.org> Message-ID: <062.b410375c086000809b5bfadb3e88d073@haskell.org> #10347: Spurious "unused constructor" warning with Coercible -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): I actually had this test case sitting in my tree for a while. Thought I would push. I haven't looked at this ticket at all otherwise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 01:53:25 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 01:53:25 -0000 Subject: [GHC] #10347: Spurious "unused constructor" warning with Coercible In-Reply-To: <047.95d70bb35e967b5051d311b602ee2dc7@haskell.org> References: <047.95d70bb35e967b5051d311b602ee2dc7@haskell.org> Message-ID: <062.8cae1095fda2cc926e08c2ba378a8f43@haskell.org> #10347: Spurious "unused constructor" warning with Coercible -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | typecheck/should_compile/T10347 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * testcase: => typecheck/should_compile/T10347 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 01:54:25 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 01:54:25 -0000 Subject: [GHC] #10811: Template Haskell does associated types poorly (printing & quoting) In-Reply-To: <047.eefd4e69268b49667f9aa1e189a8806f@haskell.org> References: <047.eefd4e69268b49667f9aa1e189a8806f@haskell.org> Message-ID: <062.ca54f1fe582f80112d74545f681f013c@haskell.org> #10811: Template Haskell does associated types poorly (printing & quoting) -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: th/T10811 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * testcase: => th/T10811 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 01:55:42 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 01:55:42 -0000 Subject: [GHC] #10770: Typeable solver has strange effects In-Reply-To: <051.c272986722d18d60205f4faa0b3da2dc@haskell.org> References: <051.c272986722d18d60205f4faa0b3da2dc@haskell.org> Message-ID: <066.062783d7b8e1b6fae63cdcaa78b0ff8d@haskell.org> #10770: Typeable solver has strange effects -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T10770{a,b} Blocked By: 5296 | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * owner: => goldfire * testcase: => typecheck/should_compile/T10770{a,b} * blockedby: => 5296 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 01:56:06 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 01:56:06 -0000 Subject: [GHC] #10844: CallStack should not be inlined In-Reply-To: <046.c5d6c4205be9804afd3acc1b71ee4c7b@haskell.org> References: <046.c5d6c4205be9804afd3acc1b71ee4c7b@haskell.org> Message-ID: <061.70c8fd222f0a1f718191fd9815f24444@haskell.org> #10844: CallStack should not be inlined -------------------------------------+------------------------------------- Reporter: nomeata | Owner: gridaphobe Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1259 -------------------------------------+------------------------------------- Changes (by gridaphobe): * differential: D1259 => Phab:D1259 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 01:56:26 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 01:56:26 -0000 Subject: [GHC] #10855: GHC rejects code that Haskell 2010 report accepts In-Reply-To: <047.18e6e77fdcbdaa2d5abe96a152166a71@haskell.org> References: <047.18e6e77fdcbdaa2d5abe96a152166a71@haskell.org> Message-ID: <062.9306bfea7bb5f672f76105368bffd837@haskell.org> #10855: GHC rejects code that Haskell 2010 report accepts -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 (Parser) | 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 goldfire): * status: new => merge * milestone: => 7.10.3 Comment: May as well merge this one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 01:58:16 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 01:58:16 -0000 Subject: [GHC] #10810: Data constructor operators mis-printed in Template Haskell In-Reply-To: <047.9a0eacfe35e8d9bc3ca01ce57985f5f2@haskell.org> References: <047.9a0eacfe35e8d9bc3ca01ce57985f5f2@haskell.org> Message-ID: <062.0e73c445ac076be42d985dc744451410@haskell.org> #10810: Data constructor operators mis-printed in Template Haskell -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.3 Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: th/T10810 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => merge * testcase: => th/T10810 * milestone: 8.0.1 => 7.10.3 Comment: Merge only if convenient. This is a tiny bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 02:06:00 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 02:06:00 -0000 Subject: [GHC] #10853: Refine addTopDecls In-Reply-To: <047.c86dd8a253022fe77935e07f26b94dc1@haskell.org> References: <047.c86dd8a253022fe77935e07f26b94dc1@haskell.org> Message-ID: <062.d8e1c5c668174369e76941a3ec0763ec@haskell.org> #10853: Refine addTopDecls -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Old description: > This suggested refactoring/documentation task is spurred on by #10486. > Readers do not have to read that ticket to understand this task. > > Currently, `addTopDecls` is restricted in what it can add. In an email > exchange with Geoff Mainland (the original implementor of `addTopDecls`), > it was unclear exactly why this restriction is in place. So, I propose > lifting the restriction. > > We do have to be careful about ordering. As it is currently implemented, > here is what happens: > > {{{ > -- region A, including everything up to but not including a top-level > splice > $( {- region B, the contents of a top-level splice -} ) > -- region C, everything after the splice > }}} > > In addition to those regions, we also have > > {{{ > -- region D, consisting of all declarations added with `addTopDecls`. > }}} > > By reading the code (`TcRnDriver.tc_rn_src_decls`), it seems that the > expected behavior should be this: > > 1. Rename region A. Anything defined in other regions is not in scope. > 2. Rename region D, with declarations from region A in scope. > 3. Type-check regions A and D together. > 4. When running TH code in region B, all declarations from A and D are in > scope and can be accessed via `reify` and friends. > 5. Combine regions B and C together, and recur to step 1 (where the > combined B and C is now a new region A). > > This all means that A and D are mutually recursive w.r.t. the type- > checker but not the renamer. This is a bit peculiar, but not terrible. > For example, this means that there could be a function whose definition > is in A and type signature in D. Proper mutual recursion would be hard > (impossible?) without better renaming support. > > In any case, I don't see a reason to restrict what's allowed in > `addTopDecls`. > > So, at a minimum, I propose: > * Remove restrictions in `addTopDecls` > * Document `addTopDecls` generally > * Document the above behavior, detailing the interaction between these > regions > > Perhaps better, we could do: > * Remove restrictions in `addTopDecls` > * Rejigger the implementation of `addTopDecls` to lump region D in with B > and C. This looks quite straightforward, and it makes for a simpler story > about mutual recursion. This is a potentially-breaking change, if > existing code has, say, a function defined in A with its type signature > in D. > * Document the new, simpler behavior > > Regardless of which proposal we go with, some testing is in order, to > make sure that this is all correct. I've done no testing in formulating > this ticket, just reading code. New description: This suggested refactoring/documentation task is spurred on by #10486. Readers do not have to read that ticket to understand this task. Currently, `addTopDecls` is restricted in what it can add. In an email exchange with Geoff Mainland (the original implementor of `addTopDecls`), it was unclear exactly why this restriction is in place. So, I propose lifting the restriction. We do have to be careful about ordering. As it is currently implemented, here is what happens: {{{ -- region A, including everything up to but not including a top-level splice $( {- region B, the contents of a top-level splice -} ) -- region C, everything after the splice }}} In addition to those regions, we also have {{{ -- region D, consisting of all declarations added with `addTopDecls`, -- as called from splices in region A }}} By reading the code (`TcRnDriver.tc_rn_src_decls`), it seems that the expected behavior should be this: 1. Rename region A. Anything defined in other regions is not in scope. 2. Rename region D, with declarations from region A in scope. 3. Type-check regions A and D together. 4. When running TH code in region B, all declarations from A and D are in scope and can be accessed via `reify` and friends. 5. Combine regions B and C together, and recur to step 1 (where the combined B and C is now a new region A). This all means that A and D are mutually recursive w.r.t. the type-checker but not the renamer. This is a bit peculiar, but not terrible. For example, this means that there could be a function whose definition is in A and type signature in D. Proper mutual recursion would be hard (impossible?) without better renaming support. In any case, I don't see a reason to restrict what's allowed in `addTopDecls`. So, at a minimum, I propose: * Remove restrictions in `addTopDecls` * Document `addTopDecls` generally * Document the above behavior, detailing the interaction between these regions Perhaps better, we could do: * Remove restrictions in `addTopDecls` * Rejigger the implementation of `addTopDecls` to lump region D in with B and C. This looks quite straightforward, and it makes for a simpler story about mutual recursion. This is a potentially-breaking change, if existing code has, say, a function defined in A with its type signature in D. * Document the new, simpler behavior Regardless of which proposal we go with, some testing is in order, to make sure that this is all correct. I've done no testing in formulating this ticket, just reading code. EDIT: Clarify that region D is created from splices from region A -- Comment (by goldfire): The behavior in comment:2 is documented: See the last bullet point under section 7.17.1 [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/template- haskell.html here]. Mind you, I didn't say this is documented well or in an obvious place (though I think we could do worse). If you have a concrete suggestion of how to make this better, I'm happy to take it. Does this clarify? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 02:07:13 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 02:07:13 -0000 Subject: [GHC] #10896: BadSock triggers failing ASSERT In-Reply-To: <045.e2606f0aace406a963850215a356a8ed@haskell.org> References: <045.e2606f0aace406a963850215a356a8ed@haskell.org> Message-ID: <060.31f507c2faaa236f9fd2ecdd96f99689@haskell.org> #10896: BadSock triggers failing ASSERT -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1260 -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => patch * differential: => Phab:D1260 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 02:08:10 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 02:08:10 -0000 Subject: [GHC] #10837: Constant-time indexing of closed type family axioms In-Reply-To: <048.d99ce2299f3cf4c3e12cff389baa1f66@haskell.org> References: <048.d99ce2299f3cf4c3e12cff389baa1f66@haskell.org> Message-ID: <063.22d5901370c69a922476e41cb15b3b9a@haskell.org> #10837: Constant-time indexing of closed type family axioms -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: patch Priority: low | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1261 -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => patch * differential: => Phab:D1261 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 02:08:51 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 02:08:51 -0000 Subject: [GHC] #10817: Looping default associated type family without UndecidableInstances In-Reply-To: <047.64ffaf6cb4d5ab1829ed952b25df0d19@haskell.org> References: <047.64ffaf6cb4d5ab1829ed952b25df0d19@haskell.org> Message-ID: <062.79b195c99999cbafa0dc09215791d5ba@haskell.org> #10817: Looping default associated type family without UndecidableInstances -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1262 -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => patch * differential: => Phab:D1262 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 02:09:11 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 02:09:11 -0000 Subject: [GHC] #10899: Polytype accepted in RHS of default associated type In-Reply-To: <047.7b758dc1f514e80e61654f6aef2fa500@haskell.org> References: <047.7b758dc1f514e80e61654f6aef2fa500@haskell.org> Message-ID: <062.300590404e99bdeafbcb05219d71f7a8@haskell.org> #10899: Polytype accepted in RHS of default associated type -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: patch Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1262 -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => patch * differential: => Phab:D1262 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 02:09:49 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 02:09:49 -0000 Subject: [GHC] #10715: Possible regression in Coercible a (X a) between 7.8 and 7.10 In-Reply-To: <044.cc1e9df1bbafaf4fb6388749f2b76941@haskell.org> References: <044.cc1e9df1bbafaf4fb6388749f2b76941@haskell.org> Message-ID: <059.f10585c0004beb01aa43fe599bfdf8d1@haskell.org> #10715: Possible regression in Coercible a (X a) between 7.8 and 7.10 -------------------------------------+------------------------------------- Reporter: inaki | Owner: goldfire Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1263 -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => patch * differential: => Phab:D1263 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 02:28:38 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 02:28:38 -0000 Subject: [GHC] #10877: x86_64: dll-split: out of memory (requested 1099512676352 bytes) In-Reply-To: <050.ab3ee9d3ff60499476bc10d829ff13d9@haskell.org> References: <050.ab3ee9d3ff60499476bc10d829ff13d9@haskell.org> Message-ID: <065.063c006fafaee18459322f769af781e0@haskell.org> #10877: x86_64: dll-split: out of memory (requested 1099512676352 bytes) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: #10682 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by gcampax): Is it possible that you have an address space limit configured (ulimit -v or /etc/security/limits.conf )? If so, is it ok to disable it to run any Haskell code, or is it a policy to have it? Unfortunately the large address space support fails if the address space limit is low. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 06:03:17 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 06:03:17 -0000 Subject: [GHC] #10903: Add an option to infer CallStack implicit parameters Message-ID: <049.6338361130d6be120ef2a488517f665c@haskell.org> #10903: Add an option to infer CallStack implicit parameters -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Adam Foltzer mentioned to me at ICFP that it would be nice if GHC had a "debug" mode that automatically inserted CallStack IPs in every function signature. Then you could easily get nice, fairly complete, call-stacks during development. Of course you could already do this with judicious use of CPP macros, but that's quite tedious (and error prone). As an example, consider {{{#!hs module A where foo xs = head xs head :: [a] -> a head (x:xs) = x head _ = error "bad" }}} Compiling `A` in this mode should result in the following signature {{{#!hs module A where foo :: (?callStack :: CallStack) => [a] -> a head :: (?callStack :: CallStack) => [a] -> a }}} I have a few concerns with this though: 1. We're '''changing''' a type signature that the user wrote. It would be a well-defined and consistent change across the whole module, but it's still unsettling. 2. How do we handle a function that already has a CallStack IP? {{{#!hs bar :: (?stk :: CallStack) => [a] -> a }}} If we're aiming for consistent insertion of CallStacks everywhere, it might make sense to remove the `?stk :: CallStack` and insert a `?callStack :: CallStack`, so they'll be appended correctly. But here again we'd be changing a user-written type signature. Furthermore, `bar` might call a function from a different module (or package) that hasn't been given this consistent debug treatment, and this other module might expect that the CallStack be named `?stk`. 3. If the CallStack is not used, e.g. {{{#!hs null :: (?callStack :: CallStack) => [a] -> Bool null [] = True null (_:_) = False }}} it will trigger a redundant constraint warning. I think we could address this by bubbling up CallStack constraints in much the same way that other constraints are propagated, so {{{#!hs module A where foo xs = head xs head :: [a] -> a head (x:xs) = x head _ = error "bad" null [] = True null (_:_) = False }}} would get the signature {{{#!hs module A where foo :: (?callStack :: CallStack) => [a] -> a head :: (?callStack :: CallStack) => [a] -> a null :: [a] -> Bool }}} In other words, we would only infer a CallStack constraint for a function when the body induces a wanted CallStack constraint. 4. How would this interact with cabal packages? If I accidentally install a package in debug mode, all downsteam packages will be compiled against the CallStack-laden signatures. Seems like we might need a new "debug" way.. It's pretty clear to me that a debug mode would be useful (in fact I manually added a bunch of CallStacks to my code the other day, only to remove them once I was done debugging), but the concerns (particularly 4.) are substantial. There's also the question of how all of this interacts with the ongoing DWARF work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 07:06:40 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 07:06:40 -0000 Subject: [GHC] #10871: Implement "fat" interface files which can be directly compiled without source In-Reply-To: <045.f4306fd46ddf30e7464e9ea8971267bf@haskell.org> References: <045.f4306fd46ddf30e7464e9ea8971267bf@haskell.org> Message-ID: <060.528358ca03347719b47c593526ad42d0@haskell.org> #10871: Implement "fat" interface files which can be directly compiled without source -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): Let's talk about recompilation avoidance and how the user-facing interface for fat interfaces work. Ideally, compilation to a fat interface (`-fno-code -fwrite-fat- interface`) should be similar to compilation to an interface (`-fno-code `-fwrite-interface`), including recompilation avoidance. This includes the following properties: 1. Incremental compile. If `A` imports `B`, and I've built `B.hi-fat`, I should also be able to build `A.hi-fat`. (This implies that an `hi-fat` file should be loadable to get `TyThing`s.) 2. If I build `A.hi-fat`, and then modify `A.hs`, if I ask GHC to build `A .hi-fat` again, it should be rebuilt; similarly if the `TyThing`s of any of its dependencies changed. However, if there are no changes, I shouldn't have to rebuild `A.hi-fat`. 3. If I am compiling an `A.hi-fat` to `A.o` and `A.hi` (e.g. finishing the compilation), it's unreasonable to expect GHC to handle the case where the `A.hi-fat` is out of date relative to the `A.hs` or any of its dependencies. However, if it is out of date, GHC should detect this and give an error, rather than generate some incorrect code. The mental model I have is that we can think of an `hi-fat` file as consisting of two parts: an types only `hi` file that would have been the result of an `-fno-code -fwrite-interface` (so, a properly Tidied interface that is good for typechecking and then loading in for later typechecking, but without any unfoldings) as well as the `fat` bits which can be used to reconstruct a `ModGuts` and finish compilation. (Of course, you'd really like this to all be ONE file. Should look at this carefully and make sure it works!) Importantly, we DON'T care about fingerprinting the bindings and stuff for compilation; only the typechecking information. We have to be careful not to confuse `hi` files and `hi-fat` files in GHC. If I'm typechecking for an `hi-fat` file, I only want to preferentially use `hi-fat` files; however, if I'm actually building a module, I really want `hi` files (so I get the right unfoldings). We have a somewhat similar situation in Backpack: I really don't want the types only definitions polluting the EPT, because then things won't optimize. Here is where things get tricky, because when we typecheck a module and then desugar it, we are going to use the typecheck only `hi` files, but when we BUILD the ModGuts, we're going to want to use the actually built `hi` files. How do we tell if these are actually in sync? We're going to need some only "type-check" only hash which we can use to test for consistency. Hmm! ModIface should have something close to this already but we have to check. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 07:30:07 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 07:30:07 -0000 Subject: [GHC] #3919: Or-patterns as GHC extension In-Reply-To: <051.27f4dc97a096cc6bd656d7691ce3afb5@haskell.org> References: <051.27f4dc97a096cc6bd656d7691ce3afb5@haskell.org> Message-ID: <066.8201ae4415c49b3057a5a09597890008@haskell.org> #3919: Or-patterns as GHC extension -------------------------------------+------------------------------------- Reporter: BjornEdstrom | Owner: Type: feature request | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by zardoz): * cc: zardoz (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 11:56:50 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 11:56:50 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.58fe057f6ac88556c5cdb8c411640425@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192 -------------------------------------+------------------------------------- Comment (by meteficha): Assuming that the main source of non-deterministic Uniques is the non- deterministic, lazy I/O, how about making a different Unique "namespace" for each file? Conceptually, it would mean having: {{{#!hs data Unique = MkUnique {-# UNPACK #-} !Int (Maybe ModuleName) }}} There could still be problems if each file was processed in a non- deterministic way, but now files could be processed in any order without changing the Uniques. This is of course an extremely naive suggestion, I'm sharing it with the hope that it may spark some better idea in someone else's mind :). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 11:58:32 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 11:58:32 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.4922395af38ad7d93055da990a04b10e@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192 -------------------------------------+------------------------------------- Changes (by meteficha): * cc: felipe.lessa@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 13:03:21 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 13:03:21 -0000 Subject: [GHC] #10877: x86_64: dll-split: out of memory (requested 1099512676352 bytes) In-Reply-To: <050.ab3ee9d3ff60499476bc10d829ff13d9@haskell.org> References: <050.ab3ee9d3ff60499476bc10d829ff13d9@haskell.org> Message-ID: <065.94c33e4890f3df2b8ef8be6cc45828fe@haskell.org> #10877: x86_64: dll-split: out of memory (requested 1099512676352 bytes) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: #10682 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by RyanGlScott): Yes, it does appear that I have an address space limit: {{{ $ ulimit -v 67108864 }}} This isn't a machine I have root access on, so I don't believe this can be changed easily. Is 67.1 GB of address space not enough? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 13:59:40 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 13:59:40 -0000 Subject: [GHC] #10904: C finalizer may be called on re-used memory Message-ID: <046.82d7a624ac5d38e3fd81c14129ab8c8d@haskell.org> #10904: C finalizer may be called on re-used memory -------------------------------------+------------------------------------- Reporter: bherzog | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.4.1 System | Keywords: | Operating System: Linux Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- It seems that the runtime system sometimes reuses memory referred to by `ForeignPtr` values before the associated C finalizers have been run. At that's what it looks like to me. Maybe I'm interpreting the behavior of GHC's runtime system incorrectly, or it's a defect in my test program. To reproduce the defect, compile `finalizertest.hs` and `finalizerlib.c`, e.g. with {{{ ghc finalizertest.hs finalizerlib.c -threaded }}} Run the resulting program as {{{ ./finalizertest +RTS -N2 }}} After a while it prints a message like {{{ finalize_value: 80f69dc != 11223344 after 47393 calls Aborted }}} The C code prints this if the pointer passed to the finalizer does not point to the expected value. It's not necessary to link with the threaded runtime, nor is it necessary to run with more than one CPU. Doing so increases the likelihood of the defect to occur substantially, though. I've observed this with several different combinations of GHC and host- systems: * GHC 7.10.2 on a 64 bit Linux (Debian jessie) * GHC 7.10.1 on a 32 bit Linux (Debian wheezy) * GHC 7.4.1 on a 32 bit Linux (Debian wheezy) This GHC is the one packaged by Debian It's crucial for the defect that the memory is allocated with `mallocForeignPtrBytes`. Using `mallocBytes` instead and building a `ForeignPtr` with `finalizerFree` avoids the defect. I came across this defect while trying to debug a segmentation fault in the `zlib` package. This defect was reported on the libraries mailing list https://mail.haskell.org/pipermail/libraries/2015-June/025829.html (corresponding Agda ticket: https://github.com/agda/agda/issues/1518). I came across it in one of my own projects last week. My test program basically does what `zlib` does when allocating and initializing the `z_stream` value: it allocates memory with `mallocForeignPtrBytes` and later adds a finalizer with `addForeignPtrFinalizer`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 14:03:04 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 14:03:04 -0000 Subject: [GHC] #10904: C finalizer may be called on re-used memory In-Reply-To: <046.82d7a624ac5d38e3fd81c14129ab8c8d@haskell.org> References: <046.82d7a624ac5d38e3fd81c14129ab8c8d@haskell.org> Message-ID: <061.8ad951bc8c1fb5df1c37519223d41f96@haskell.org> #10904: C finalizer may be called on re-used memory -------------------------------------+------------------------------------- Reporter: bherzog | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.4.1 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bherzog): * Attachment "finalizertest.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 14:03:18 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 14:03:18 -0000 Subject: [GHC] #10904: C finalizer may be called on re-used memory In-Reply-To: <046.82d7a624ac5d38e3fd81c14129ab8c8d@haskell.org> References: <046.82d7a624ac5d38e3fd81c14129ab8c8d@haskell.org> Message-ID: <061.9b6101becc1c69a09461cef0b3c35cc6@haskell.org> #10904: C finalizer may be called on re-used memory -------------------------------------+------------------------------------- Reporter: bherzog | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.4.1 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bherzog): * Attachment "finalizerlib.c" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 14:03:29 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 14:03:29 -0000 Subject: [GHC] #10904: C finalizer may be called on re-used memory In-Reply-To: <046.82d7a624ac5d38e3fd81c14129ab8c8d@haskell.org> References: <046.82d7a624ac5d38e3fd81c14129ab8c8d@haskell.org> Message-ID: <061.15e16dafedbe1e7824c4672d548d1454@haskell.org> #10904: C finalizer may be called on re-used memory -------------------------------------+------------------------------------- Reporter: bherzog | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.4.1 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bherzog): * Attachment "finalizerlib.h" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 14:53:42 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 14:53:42 -0000 Subject: [GHC] #10347: Spurious "unused constructor" warning with Coercible In-Reply-To: <047.95d70bb35e967b5051d311b602ee2dc7@haskell.org> References: <047.95d70bb35e967b5051d311b602ee2dc7@haskell.org> Message-ID: <062.28e3ca51d81c36e5a326a4ef0fcf919d@haskell.org> #10347: Spurious "unused constructor" warning with Coercible -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | typecheck/should_compile/T10347 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"cbcad859acb350a33dec077d50438f929afbf0ad/ghc" cbcad85/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="cbcad859acb350a33dec077d50438f929afbf0ad" Fix typo in test for #10347. Thanks to Gabor Greif for spotting the mistake. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 14:53:42 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 14:53:42 -0000 Subject: [GHC] #10715: Possible regression in Coercible a (X a) between 7.8 and 7.10 In-Reply-To: <044.cc1e9df1bbafaf4fb6388749f2b76941@haskell.org> References: <044.cc1e9df1bbafaf4fb6388749f2b76941@haskell.org> Message-ID: <059.1e5e479870e00cda04246c6ca75aaea8@haskell.org> #10715: Possible regression in Coercible a (X a) between 7.8 and 7.10 -------------------------------------+------------------------------------- Reporter: inaki | Owner: goldfire Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1263 -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"2f9809efdbc11fee445dbe3d5c555433ec3c5e6a/ghc" 2f9809ef/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2f9809efdbc11fee445dbe3d5c555433ec3c5e6a" Slightly better `Coercible` errors. This makes two real changes: - Equalities like (a ~R [a]) really *are* insoluble. Previously, GHC refused to give up when an occurs check bit on a representational equality. But for datatypes, it really should bail. - Now, GHC will sometimes report an occurs check error (in cases above) for representational equalities. Previously, it never did. This "fixes" #10715, where by "fix", I mean clarifies the error message. It's unclear how to do more to fix that ticket. Test cases: typecheck/should_fail/T10715{,b} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 14:53:42 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 14:53:42 -0000 Subject: [GHC] #10817: Looping default associated type family without UndecidableInstances In-Reply-To: <047.64ffaf6cb4d5ab1829ed952b25df0d19@haskell.org> References: <047.64ffaf6cb4d5ab1829ed952b25df0d19@haskell.org> Message-ID: <062.55011adaa47c19af1929d4b688f531cf@haskell.org> #10817: Looping default associated type family without UndecidableInstances -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1262 -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"e27b267f3675180c03a75282dd952b8a59339a1f/ghc" e27b267/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e27b267f3675180c03a75282dd952b8a59339a1f" Perform a validity check on assoc type defaults. This fixes #10817 and #10899. A knock-on effect is that we must now remember locations of associated type defaults for error messages during validity checking. This isn't too bad, but it increases the size of the diff somewhat. Test cases: indexed-types/should_fail/T108{17,99} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 14:53:42 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 14:53:42 -0000 Subject: [GHC] #10899: Polytype accepted in RHS of default associated type In-Reply-To: <047.7b758dc1f514e80e61654f6aef2fa500@haskell.org> References: <047.7b758dc1f514e80e61654f6aef2fa500@haskell.org> Message-ID: <062.66ba571c088df3b69f883dbb21df52aa@haskell.org> #10899: Polytype accepted in RHS of default associated type -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: patch Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1262 -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"e27b267f3675180c03a75282dd952b8a59339a1f/ghc" e27b267/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e27b267f3675180c03a75282dd952b8a59339a1f" Perform a validity check on assoc type defaults. This fixes #10817 and #10899. A knock-on effect is that we must now remember locations of associated type defaults for error messages during validity checking. This isn't too bad, but it increases the size of the diff somewhat. Test cases: indexed-types/should_fail/T108{17,99} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 14:53:42 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 14:53:42 -0000 Subject: [GHC] #10896: BadSock triggers failing ASSERT In-Reply-To: <045.e2606f0aace406a963850215a356a8ed@haskell.org> References: <045.e2606f0aace406a963850215a356a8ed@haskell.org> Message-ID: <060.41bdc4b72730d5ae1f77ceab988dae34@haskell.org> #10896: BadSock triggers failing ASSERT -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1260 -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"8e8b9ed9849ba21e454e6204b368f8e993feaf7b/ghc" 8e8b9ed/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8e8b9ed9849ba21e454e6204b368f8e993feaf7b" Run simplifier only when the env is clean. This fixes #10896. In the indexed-types/should_fail/BadSock test, there is a bad type definition. This gets type-checked, an error gets reported, but then **GHC keeps going**. Later, when running the simplifier to do an ambiguity check, the bad type environment causes GHC to fall over. My solution: only run the simplifier in a clean, error-free type environment. A downside of this is that fewer error messages are reported. This makes me a bit sad, but I'm not sure how to avoid the problem. Suggestions welcome. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 14:55:59 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 14:55:59 -0000 Subject: [GHC] #10715: Possible regression in Coercible a (X a) between 7.8 and 7.10 In-Reply-To: <044.cc1e9df1bbafaf4fb6388749f2b76941@haskell.org> References: <044.cc1e9df1bbafaf4fb6388749f2b76941@haskell.org> Message-ID: <059.24f1a63f6dcd937f25189d4aec4f1421@haskell.org> #10715: Possible regression in Coercible a (X a) between 7.8 and 7.10 -------------------------------------+------------------------------------- Reporter: inaki | Owner: goldfire Type: bug | Status: merge Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_fail/T10715{,b} Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1263 -------------------------------------+------------------------------------- Changes (by goldfire): * testcase: => typecheck/should_fail/T10715{,b} * status: patch => merge * milestone: => 7.10.3 Comment: Merge only if convenient -- this does nothing but improve error messages. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 14:56:57 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 14:56:57 -0000 Subject: [GHC] #10899: Polytype accepted in RHS of default associated type In-Reply-To: <047.7b758dc1f514e80e61654f6aef2fa500@haskell.org> References: <047.7b758dc1f514e80e61654f6aef2fa500@haskell.org> Message-ID: <062.722992a5aeb2873300ed7b08b14ed33a@haskell.org> #10899: Polytype accepted in RHS of default associated type -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: merge Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_fail/T10899 Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1262 -------------------------------------+------------------------------------- Changes (by goldfire): * status: patch => merge * testcase: => indexed-types/should_fail/T10899 Comment: It's worth merging this one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 14:57:58 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 14:57:58 -0000 Subject: [GHC] #10896: BadSock triggers failing ASSERT In-Reply-To: <045.e2606f0aace406a963850215a356a8ed@haskell.org> References: <045.e2606f0aace406a963850215a356a8ed@haskell.org> Message-ID: <060.8081daaa9776528e9131adde33b0baf7@haskell.org> #10896: BadSock triggers failing ASSERT -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_fail/BadSock Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1260 -------------------------------------+------------------------------------- Changes (by goldfire): * testcase: => indexed-types/should_fail/BadSock * status: patch => closed * resolution: => fixed Comment: All set now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 14:58:35 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 14:58:35 -0000 Subject: [GHC] #10817: Looping default associated type family without UndecidableInstances In-Reply-To: <047.64ffaf6cb4d5ab1829ed952b25df0d19@haskell.org> References: <047.64ffaf6cb4d5ab1829ed952b25df0d19@haskell.org> Message-ID: <062.53959a47afaf548e37e030643fc8f604@haskell.org> #10817: Looping default associated type family without UndecidableInstances -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.3 Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_fail/T10817 Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1262 -------------------------------------+------------------------------------- Changes (by goldfire): * status: patch => merge * testcase: => indexed-types/should_fail/T10817 * milestone: => 7.10.3 Comment: Worth merging this one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 15:26:51 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 15:26:51 -0000 Subject: [GHC] #10862: No way to exclude current directory from search path In-Reply-To: <046.896446a44757716ea085cdf95c0a86ea@haskell.org> References: <046.896446a44757716ea085cdf95c0a86ea@haskell.org> Message-ID: <061.f2c3fdc563f0689b30f8a48fee1facd0@haskell.org> #10862: No way to exclude current directory from search path -------------------------------------+------------------------------------- Reporter: literon | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Driver | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => infoneeded Comment: literon: I'm waiting for your response. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 15:29:44 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 15:29:44 -0000 Subject: [GHC] #10898: GHCI crash In-Reply-To: <045.6b0350008e1009dd255fc812f56da5c5@haskell.org> References: <045.6b0350008e1009dd255fc812f56da5c5@haskell.org> Message-ID: <060.d389f8ae722506208b41f2ea08ea51a4@haskell.org> #10898: GHCI crash -------------------------------+------------------------------------- Reporter: trebor | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+------------------------------------- Changes (by thomie): * status: new => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 15:56:23 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 15:56:23 -0000 Subject: [GHC] #10905: Incorrect number of parameters in "role" errors Message-ID: <047.769c113cdba80683b91dbad9e4b88b4d@haskell.org> #10905: Incorrect number of parameters in "role" errors -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: roles | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- The following code produces the error: {{{ import Data.Coerce import Data.Functor.Trans.Tagged toTT :: Tagged t [a] -> TaggedT t [] a toTT = coerce }}} {{{ Couldn't match representation of type ?[a]? with that of ?Data.Functor.Identity.Identity [a]? arising from trying to show that the representations of ?Tagged t [a]? and ?TaggedT t [] a? are the same Relevant role signatures: type role [] representational type role Data.Functor.Identity.Identity representational type role TaggedT nominal nominal phantom representational nominal The data constructor ?Data.Functor.Identity.Identity? of newtype ?Data.Functor.Identity.Identity? is not in scope Relevant bindings include toTT :: Tagged t [a] -> TaggedT t [] a (bound at Main.hs:9:1) In the expression: coerce In an equation for ?toTT?: toTT = coerce }}} First, kudos for correctly identifying the problem: I failed to import the `Identity` constructor. However, it seems that the report for the roles of the `TaggedT` type has too many parameters. It is defined in tagged-transformer [https://hackage.haskell.org/package/tagged-transformer-0.8/docs/Data- Functor-Trans-Tagged.html] as `newtype TaggedT s m b = TagT { untagT :: m b }`, but is listed with 5 roles. I did try to move the definition of `TaggedT/Tagged` into my module so I didn't have to import the library, but when I did the error didn't show up: TaggedT was listed with the expected roles `phantom representational nominal`. As a user, it wasn't clear to me why there are 5 roles listed for a type with 3 parameters, and I didn't know which roles I should be looking at to help me debug the `coerce` error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 16:02:17 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 16:02:17 -0000 Subject: [GHC] #10837: Constant-time indexing of closed type family axioms In-Reply-To: <048.d99ce2299f3cf4c3e12cff389baa1f66@haskell.org> References: <048.d99ce2299f3cf4c3e12cff389baa1f66@haskell.org> Message-ID: <063.816f345a5418b202e657ed343c67cae9@haskell.org> #10837: Constant-time indexing of closed type family axioms -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: patch Priority: low | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1261 -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"cd2840a784f4136a8cfdb704124e892430ad9ead/ghc" cd2840a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="cd2840a784f4136a8cfdb704124e892430ad9ead" Refactor BranchLists. Now we use Array to store branches. This makes sense because we often have to do random access (once inference is done). This also vastly simplifies the awkward BranchList type. This fixes #10837 and updates submodule utils/haddock. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 16:15:59 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 16:15:59 -0000 Subject: [GHC] #10652: Better cache performance in Array# In-Reply-To: <050.29d287c6c00bdf49b58de908b0c4a371@haskell.org> References: <050.29d287c6c00bdf49b58de908b0c4a371@haskell.org> Message-ID: <065.bf769090bfcfd2b838a9ff47f1aefe4a@haskell.org> #10652: Better cache performance in Array# -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): MikeIzbicki, you will probably be interested in Phab:D1264. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 16:16:28 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 16:16:28 -0000 Subject: [GHC] #10857: "ghci -XMonomorphismRestriction" doesn't turn on the monomorphism restriction In-Reply-To: <047.0bca38b39289a4db2d373be62522bc3d@haskell.org> References: <047.0bca38b39289a4db2d373be62522bc3d@haskell.org> Message-ID: <062.0eda65d6250c35808310cb7d69670d15@haskell.org> #10857: "ghci -XMonomorphismRestriction" doesn't turn on the monomorphism restriction -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: cocreature Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #3202, #3217 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): Which tests fail if you add `-XNoMonomorphismRestriction` to the standard DynFlags? You linked to `-fimplicit-import-qualified` being added to the standard DynFlags. I see there is a TODO (XXX) there, so it looks like this is considered to be a bug. But I'm having trouble coming with an example that would trigger the bug, can you? I tried the following, expecting it to be erroneously accepted by GHCi (when running `ghci Test.hs`), but it isn't: Test.hs: {{{ main = print $ Data.List.foldl' (+) 0 [1,2,3] }}} This fails with `error: Not in scope: ?Data.List.foldl'?`. So now I don't understand the difference between the standard DynFlags and the interactive DynFlags. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 16:18:07 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 16:18:07 -0000 Subject: [GHC] #10905: Incorrect number of parameters in "role" errors In-Reply-To: <047.769c113cdba80683b91dbad9e4b88b4d@haskell.org> References: <047.769c113cdba80683b91dbad9e4b88b4d@haskell.org> Message-ID: <062.262d43104ad7448c8fe8c58437c3df95@haskell.org> #10905: Incorrect number of parameters in "role" errors -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: roles Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): I know what's going on here: GHC is reporting the role of //kind// parameters (which are all nominal). It shouldn't (unless you say `-fprint- explicit-kinds`, I think). Easy to fix. But Simon removed this role-signature-reporting code. From !TcErrors: {{{ -- SLPJ Jun 15: I could not convince myself that these hints were really -- useful. Maybe they are, but I think we need more work to make them -- actually helpful. }}} So the error is therefore absent in HEAD. But I thought those role signatures were helpful, and it sounds like @crockeea does too. So, Simon, care to elaborate on why you removed these? Are there too many signatures reported? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 16:18:46 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 16:18:46 -0000 Subject: [GHC] #10905: Incorrect number of parameters in "role" errors In-Reply-To: <047.769c113cdba80683b91dbad9e4b88b4d@haskell.org> References: <047.769c113cdba80683b91dbad9e4b88b4d@haskell.org> Message-ID: <062.76921f0ff2e30d7527ff3bcff90139cf@haskell.org> #10905: Incorrect number of parameters in "role" errors -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: roles Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Here's my test case. It produces the bad output in 7.10, but (as noted above) not in HEAD. {{{ {-# LANGUAGE PolyKinds #-} module T10905 where import Data.Coerce import Data.Functor.Identity data TaggedT s m b = TagT { untagT :: m b } foo :: TaggedT () [] Int -> TaggedT () [] (Identity Int) foo = coerce -- test the printing of TaggedT's role signature }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 16:25:45 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 16:25:45 -0000 Subject: [GHC] #10837: Constant-time indexing of closed type family axioms In-Reply-To: <048.d99ce2299f3cf4c3e12cff389baa1f66@haskell.org> References: <048.d99ce2299f3cf4c3e12cff389baa1f66@haskell.org> Message-ID: <063.c4782ef31673e9c8d841bb65c7f35c40@haskell.org> #10837: Constant-time indexing of closed type family axioms -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: closed Priority: low | Milestone: Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1261 -------------------------------------+------------------------------------- Changes (by goldfire): * status: patch => closed * resolution: => fixed Comment: No need for a test case. Do //not// merge. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 16:27:17 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 16:27:17 -0000 Subject: [GHC] #10905: Incorrect number of parameters in "role" errors In-Reply-To: <047.769c113cdba80683b91dbad9e4b88b4d@haskell.org> References: <047.769c113cdba80683b91dbad9e4b88b4d@haskell.org> Message-ID: <062.450966a725f80d31a5ae6a1ac0532369@haskell.org> #10905: Incorrect number of parameters in "role" errors -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: roles Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Old description: > The following code produces the error: > > {{{ > import Data.Coerce > import Data.Functor.Trans.Tagged > > toTT :: Tagged t [a] -> TaggedT t [] a > toTT = coerce > }}} > > {{{ > Couldn't match representation of type ?[a]? > with that of ?Data.Functor.Identity.Identity > [a]? > arising from trying to show that the representations of > ?Tagged t [a]? and > ?TaggedT t [] a? are the same > Relevant role signatures: > type role [] representational > type role Data.Functor.Identity.Identity representational > type role TaggedT nominal nominal phantom representational nominal > The data constructor ?Data.Functor.Identity.Identity? > of newtype ?Data.Functor.Identity.Identity? is not in scope > Relevant bindings include > toTT :: Tagged t [a] -> TaggedT t [] a (bound at Main.hs:9:1) > In the expression: coerce > In an equation for ?toTT?: toTT = coerce > }}} > > First, kudos for correctly identifying the problem: I failed to import > the `Identity` constructor. > However, it seems that the report for the roles of the `TaggedT` type has > too many parameters. It is defined in tagged-transformer > [https://hackage.haskell.org/package/tagged-transformer-0.8/docs/Data- > Functor-Trans-Tagged.html] as `newtype TaggedT s m b = TagT { untagT :: m > b }`, but is listed with 5 roles. > > I did try to move the definition of `TaggedT/Tagged` into my module so I > didn't have to import the library, but when I did the error didn't show > up: TaggedT was listed with the expected roles `phantom representational > nominal`. > > As a user, it wasn't clear to me why there are 5 roles listed for a type > with 3 parameters, and I didn't know which roles I should be looking at > to help me debug the `coerce` error. New description: The following code produces the error: {{{ import Data.Coerce import Data.Functor.Trans.Tagged toTT :: Tagged t [a] -> TaggedT t [] a toTT = coerce }}} {{{ Couldn't match representation of type ?[a]? with that of ?Data.Functor.Identity.Identity [a]? arising from trying to show that the representations of ?Tagged t [a]? and ?TaggedT t [] a? are the same Relevant role signatures: type role [] representational type role Data.Functor.Identity.Identity representational type role TaggedT nominal nominal phantom representational nominal The data constructor ?Data.Functor.Identity.Identity? of newtype ?Data.Functor.Identity.Identity? is not in scope Relevant bindings include toTT :: Tagged t [a] -> TaggedT t [] a (bound at Main.hs:9:1) In the expression: coerce In an equation for ?toTT?: toTT = coerce }}} First, kudos for correctly identifying the problem: I failed to import the `Identity` constructor. However, it seems that the report for the roles of the `TaggedT` type has too many parameters. It is defined in tagged-transformer [https://hackage.haskell.org/package/tagged-transformer-0.8/docs/Data- Functor-Trans-Tagged.html] as `newtype TaggedT s m b = TagT { untagT :: m b }`, but is listed with 5 roles. I did try to move the definition of `TaggedT/Tagged` into my module so I didn't have to import the library, but when I did the error didn't show up: TaggedT was listed with the expected roles `phantom representational nominal`. As a user, it wasn't clear to me why there are 5 roles listed for a type with 3 parameters, and I didn't know which roles I should be looking at to help me debug the `coerce` error. It's also not clear why using the library vs defining the types locally changed the behavior. -- Comment (by crockeea): I agree with your test case, and it appears that 5 roles are printed with both `-fprint-explicit-kinds` and with `-fno-print-explicit-kinds`, which seems odd (or is that merely because of `PolyKinds`?). I suppose it makes sense to print the roles of the kinds if you have `fprint-explicit-kinds` enabled, but in my original test case (without `fprint-explicit-kinds` or `PolyKinds`, the kind roles should probably not be printed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 16:36:39 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 16:36:39 -0000 Subject: [GHC] #10539: ghc internal error compiling simple template haskell + lens program In-Reply-To: <049.325e9961b4964885fc9c66aa2a848ba4@haskell.org> References: <049.325e9961b4964885fc9c66aa2a848ba4@haskell.org> Message-ID: <064.83d8117631d7f1265c834da7e57a165c@haskell.org> #10539: ghc internal error compiling simple template haskell + lens program -------------------------------------+------------------------------------- Reporter: andrew.wja | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: worksforme | Keywords: lens | template-haskell Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: infoneeded => closed * resolution: => worksforme Comment: I tried with ghc-7.10.2 and lens-4.12.3, and couldn't reproduce it either. andrew.wja: please reopen if you can reproduce this problem with ghc-7.10.2. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 16:39:04 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 16:39:04 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2310515=3A_ghc=3A_panic=3A_tyThingTyC?= =?utf-8?b?b24gSWRlbnRpZmllciDigJgkZlN0ZW5jaWw6LmEoLCwsLCk34oCZ?= In-Reply-To: <046.1a69329a1db1e1b89b8b31699fd5aae1@haskell.org> References: <046.1a69329a1db1e1b89b8b31699fd5aae1@haskell.org> Message-ID: <061.28d6cb6f4085083eebf4245512c80b5a@haskell.org> #10515: ghc: panic: tyThingTyCon Identifier ?$fStencil:.a(,,,,)7? -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: infoneeded => closed * resolution: => invalid Comment: yongqli: please reopen if you see something like that again. Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 16:45:21 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 16:45:21 -0000 Subject: [GHC] #10829: Simplification in the RHS of rules In-Reply-To: <046.7ca7c028ab82ec2d7ad263cb88680067@haskell.org> References: <046.7ca7c028ab82ec2d7ad263cb88680067@haskell.org> Message-ID: <061.7086d7551fa45ac47c25c7ae58deb660@haskell.org> #10829: Simplification in the RHS of rules -------------------------------------+------------------------------------- Reporter: afarmer | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10528 | Differential Revisions: Phab:D1246 -------------------------------------+------------------------------------- Comment (by afarmer): I'm working on updating test suite so validation passes, and I'm also compiling stackage LTS 3.6 as a smoke test. I'll report back when those things are done. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 16:48:53 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 16:48:53 -0000 Subject: [GHC] #9927: Should simplifier try more iterations? In-Reply-To: <047.578e70cae2a9663a3bc68c7bc786ce1f@haskell.org> References: <047.578e70cae2a9663a3bc68c7bc786ce1f@haskell.org> Message-ID: <062.0e013f04aba95ac0c8768b7468dd0f8b@haskell.org> #9927: Should simplifier try more iterations? -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * component: Compiler => Build System -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 16:52:21 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 16:52:21 -0000 Subject: [GHC] #10857: "ghci -XMonomorphismRestriction" doesn't turn on the monomorphism restriction In-Reply-To: <047.0bca38b39289a4db2d373be62522bc3d@haskell.org> References: <047.0bca38b39289a4db2d373be62522bc3d@haskell.org> Message-ID: <062.7c3ad11924f24e64c7c26afca25080e7@haskell.org> #10857: "ghci -XMonomorphismRestriction" doesn't turn on the monomorphism restriction -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: cocreature Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #3202, #3217 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by cocreature): The tests that fail are {{{ make TEST="dynbrk002 break021 break012 print012 break020 ghci057 T9293 ghci024 ghci058" }}} and here's the [http://lpaste.net/141427 output]. One reason for the failure is that :show language shows the extensions whereas atm only :showi language shows them. The other failures seem to be related to the ghci debugger printing some type signatures differently which is probably related to {{{-XExtendedDefaultRules and}}} {{{-XNoMonomorphismRestriction}}} now appearing outside of the interactive session flags as well. Apart from the debugger case I feel like it's mostly a semantic distinction. Your code doesn't fail because the hack only adds {{{-fimplicit-import- qualified}}} to the DynFlags if load mode is {{{DoInteractive}}} or {{{DoEval}}}. I haven't managed to come up with anything that triggers the bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 17:13:53 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 17:13:53 -0000 Subject: [GHC] #10857: "ghci -XMonomorphismRestriction" doesn't turn on the monomorphism restriction In-Reply-To: <047.0bca38b39289a4db2d373be62522bc3d@haskell.org> References: <047.0bca38b39289a4db2d373be62522bc3d@haskell.org> Message-ID: <062.14db14bab461be8bad9e6e31c213ccea@haskell.org> #10857: "ghci -XMonomorphismRestriction" doesn't turn on the monomorphism restriction -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: cocreature Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #3202, #3217 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): {{{ +[1 of 1] Compiling Ghci058 ( Ghci058.hs, interpreted ) [flags changed] Ok, modules loaded: Ghci058. }}} That's unacceptable I think. After compiling a module with `-dynamic`, and then loading it in GHCi, GHCi shouldn't have to reinterpret it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 17:24:35 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 17:24:35 -0000 Subject: [GHC] #10857: "ghci -XMonomorphismRestriction" doesn't turn on the monomorphism restriction In-Reply-To: <047.0bca38b39289a4db2d373be62522bc3d@haskell.org> References: <047.0bca38b39289a4db2d373be62522bc3d@haskell.org> Message-ID: <062.023994149cc5b6de2997fbce59edaca9@haskell.org> #10857: "ghci -XMonomorphismRestriction" doesn't turn on the monomorphism restriction -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: cocreature Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #3202, #3217 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): Replying to [comment:6 cocreature]: > Your code doesn't fail because the hack only adds {{{-fimplicit-import- qualified}}} to the DynFlags if load mode is {{{DoInteractive}}} or {{{DoEval}}}. But when I run `ghci`, isn't the load mode always `DoInteractive`? So shouldn't `-fimplicit-import-qualified` also apply to modules loaded into GHCi, as in my example? I guess it doesn't, but I don't understand why not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 17:27:56 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 17:27:56 -0000 Subject: [GHC] #10459: -fsimple-tick-factor required In-Reply-To: <046.318589501785c7d424a25275b1b3f56a@haskell.org> References: <046.318589501785c7d424a25275b1b3f56a@haskell.org> Message-ID: <061.242a130ed92499fe6cc873a12475e715@haskell.org> #10459: -fsimple-tick-factor required -------------------------------------+------------------------------------- Reporter: mikehat | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: worksforme | Keywords: fsimple- | tick-factor Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: infoneeded => closed * resolution: => worksforme Comment: mikehat: as I said in comment:3, I can't reproduce your problem with ghc-7.6. Please reopen if this is still a problem for you. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 17:31:07 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 17:31:07 -0000 Subject: [GHC] #10295: Putting SCC in heavily inlined code results in "error: redefinition of global" In-Reply-To: <046.adbcfa466714e863665bb32dacf6e5dc@haskell.org> References: <046.adbcfa466714e863665bb32dacf6e5dc@haskell.org> Message-ID: <061.c95a8daf2343f4a1c37a97958833edbe@haskell.org> #10295: Putting SCC in heavily inlined code results in "error: redefinition of global" -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * component: Compiler => Compiler (LLVM) Comment: yongqli: which version of llvm were you using? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 17:35:36 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 17:35:36 -0000 Subject: [GHC] #10083: ghc: panic! (the 'impossible' happened) In-Reply-To: <047.98ab68675b5fd7aadd4f473d218b6ef3@haskell.org> References: <047.98ab68675b5fd7aadd4f473d218b6ef3@haskell.org> Message-ID: <062.ea387a3f2a41e7a26ec558bd0e244ccb@haskell.org> #10083: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: hedayaty | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: infoneeded => new * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 18:14:20 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 18:14:20 -0000 Subject: [GHC] #9978: DEBUG is always replaced as 1 when CPP pragma is on In-Reply-To: <046.1e158369b154425aa800b189096e6147@haskell.org> References: <046.1e158369b154425aa800b189096e6147@haskell.org> Message-ID: <061.c479342cfa24c0ddca39eba0dcb30867@haskell.org> #9978: DEBUG is always replaced as 1 when CPP pragma is on -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (Parser) | Resolution: worksforme | Keywords: cpp Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: infoneeded => closed * resolution: => worksforme Comment: As I said, I can not reproduce this issue. Maybe check if the output of `ghc --info` contains `-DDEBUG` for some reason, that would explain it. Please reopen if you can reproduce this issue with ghc-7.10.2. Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 18:44:32 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 18:44:32 -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.86272a0f07b19929522c108373744b97@haskell.org> #9906: Warning generated by hscpp code have unhelpful file names -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Driver | Version: 7.8.3 Resolution: worksforme | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: infoneeded => closed * resolution: => worksforme * os: Unknown/Multiple => MacOS X Comment: Searching for "/var/folders" on https://github.com/haskell/cabal only shows issues dealing with ghc-7.8. I'm assuming this is fixed, whatever it was. Please reopen if this is still a problem. See also comment:1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 18:49:41 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 18:49:41 -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.c15d934067a44922b18803a57314d27d@haskell.org> #9868: ghc: panic! Dynamic linker not initialised -------------------------------------+------------------------------------- Reporter: Jamedjo | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 7.8.3 (Linker) | Resolution: worksforme | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: infoneeded => closed * resolution: => worksforme Comment: Closing this ticket, as we don't have a way to reproduce the bug. Please //do// reopen if happens again. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 18:52:49 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 18:52:49 -0000 Subject: [GHC] #10333: hs-boot modification doesn't induce recompilation In-Reply-To: <045.b2a6545e2380bf06a403c64b9db0df81@haskell.org> References: <045.b2a6545e2380bf06a403c64b9db0df81@haskell.org> Message-ID: <060.5e49fe02b5e0096088884648d4d9a9be@haskell.org> #10333: hs-boot modification doesn't induce recompilation -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"06d46b1e4507e09eb2a7a04998a92610c8dc6277/ghc" 06d46b1e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="06d46b1e4507e09eb2a7a04998a92610c8dc6277" Unify hsig and hs-boot; add preliminary "hs-boot" merging. This patch drops the file level distinction between hs-boot and hsig; we figure out which one we are compiling based on whether or not there is a corresponding hs file lying around. To make the "import A" syntax continue to work for bare hs-boot files, we also introduce hs-boot merging, which takes an A.hi-boot and converts it to an A.hi when there is no A.hs file in scope. This will be generalized in Backpack to merge multiple A.hi files together; which means we can jettison the "load multiple interface files" functionality. This works automatically for --make, but for one-shot compilation we need a new mode: ghc --merge-requirements A will generate an A.hi/A.o from a local A.hi-boot file; Backpack will extend this mechanism further. Has Haddock submodule update to deal with change in msHsFilePath behavior. - This commit drops support for the hsig extension. Can we support it? It's annoying because the finder code is written with the assumption that where there's an hs-boot file, there's always an hs file too. To support hsig, you'd have to probe two locations. Easier to just not support it. - #10333 affects us, modifying an hs-boot still doesn't trigger recomp. - See compiler/main/Finder.hs: this diff is very skeevy, but it seems to work. - This code cunningly doesn't drop hs-boot files from the "drop hs-boot files" module graph, if they don't have a corresponding hs file. I have no idea if this actually is useful. Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: simonpj, austin, bgamari, spinda Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1098 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 18:56:15 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 18:56:15 -0000 Subject: [GHC] #9704: GHC fails with "Loading temp shared object failed" In-Reply-To: <049.1e96b8f599d87115d367d6587554afa1@haskell.org> References: <049.1e96b8f599d87115d367d6587554afa1@haskell.org> Message-ID: <064.faa41450586097fa13348dc7271d2b8f@haskell.org> #9704: GHC fails with "Loading temp shared object failed" -------------------------------------+------------------------------------- Reporter: MaxGabriel | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: 9074 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => infoneeded Comment: Can you try again with ghc-7.10.2? This looks like #10058, which was fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 19:02:06 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 19:02:06 -0000 Subject: [GHC] #9615: GHC panic: Loading temp shared object failed In-Reply-To: <042.4e53618d00dd07f1d8d85e351181a7b3@haskell.org> References: <042.4e53618d00dd07f1d8d85e351181a7b3@haskell.org> Message-ID: <057.8f73570c7b9e14d18369b4409211700c@haskell.org> #9615: GHC panic: Loading temp shared object failed -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #10110 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: infoneeded => closed * resolution: => duplicate * related: => #10110 Comment: I'm going to optimistically assume this was the same issue as #10110, which is fixed in ghc-7.10.2. Please reopen if you see it happening again! Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 19:58:57 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 19:58:57 -0000 Subject: [GHC] #5108: Allow unicode sub/superscript symbols in operators (was: 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.ca4395f54bb9f072a40e11700f56d3f0@haskell.org> #5108: Allow unicode sub/superscript symbols in operators -------------------------------------+------------------------------------- Reporter: | Owner: mikhail.vorozhtsov | Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.1 (Parser) | Keywords: lexer Resolution: | unicode Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10196 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: infoneeded => new * milestone: 8.0.1 => Comment: `v? = 1` is now accepted, but `m >>=? f` still isn't. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 20:01:06 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 20:01:06 -0000 Subject: [GHC] #10906: `SPECIALIZE instance` could be better Message-ID: <047.543c3642e928cd31af650afc3fdc96ba@haskell.org> #10906: `SPECIALIZE instance` could be better -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- END GOAL: Use dependent types (or their approximation) to make code run faster. ----------------------------- Suppose we have a heterogeneous list type that can only hold a nice, limited set of things, as defined by this universe: {{{ data U = INT | BOOL | LIST U -- interpret the universe into Haskell types type family El u where El 'INT = Int El 'BOOL = Bool El ('LIST u) = [El u] }}} Here's our list type: {{{ data HList :: [U] -> * where Nil :: HList '[] (:>) :: El u -> HList us -> HList (u ': us) infixr 5 :> }}} Now, suppose I want to write a `Show` instance for `HList us`. This should certainly be possible -- we can see that such a list can contain only things that have instances for `Show`. But I don't really expect GHC to do the nested induction to figure that out. Through moderate pyrotechnics, I can get something like this to type- check, where I'm eliding the pyrotechnics: {{{ -- space separated (terminated, actually), just for ease instance {- don't look here -} => Show (HList us) where show Nil = "" show (x :> xs) = {- convince GHC that we can `show x` -} $ show x ++ " " ++ show xs }}} (The full file is attached. But it's nothing extraordinary.) Now, suppose in client code, I know I'm often dealing with `HList '[INT, BOOL, LIST INT]`. Let's call that type `MyList`. When printing a `MyList`, the `Show` instance above has to do a runtime lookup to figure how to print the elements of `MyList`. It must do this //every time//. This is very silly. The whole point of putting the element types in the index to `HList` is so that GHC can know, statically, what types the elements are. We shouldn't have to check! The next step in my thought process was to use `{-# SPECIALIZE instance ... #-}` to specialize the `Show` instance. But then I ran into two problems: 1. `{-# SPECIALIZE instance ... #-}` is allowed only in the context of the instance declaration. You can't do it in an importing module, even if the exporting module is kind enough to say `INLINABLE` in the right spots. 2. `{-# SPECIALIZE instance ... #-}` doesn't allow one specialization to use another. 3. (For more complicated scenarios) `{-# SPECIALIZE instance ... #-}` doesn't allow type families in the `...`. About point (1): Is there a good reason for this restriction? Of course, the concrete implementations of the methods of the instance to be specialized must be available, but the exporting module should be able to arrange that with the right pragmas. To illustrate (2), I said `{-# SPECIALIZE instance Show (HList '[ 'INT, 'BOOL, 'LIST 'INT ]) #-}` and GHC specialized only the first layer. OK. Reasonable enough. But then I tried {{{ {-# SPECIALIZE instance Show (HList '[ 'LIST 'INT ]) #-} {-# SPECIALIZE instance Show (HList '[ 'BOOL, 'LIST 'INT ]) #-} {-# SPECIALIZE instance Show (HList '[ 'INT, 'BOOL, 'LIST 'INT]) #-} }}} and it still only went one layer deep. One specialization didn't call another. (Examined with `-ddump-simpl` on `-O2`.) That's frustrating. About point (3): While it would be a bad idea to allow type families in normal instance heads, it seems sensible to allow them in `SPECIALIZE instance`. This is rather like allowing expressions (instead of, say, bare variables) on the LHS of rules. ------------------- This ticket posting may be a little overly broad, but I'd love to know what others think about all of this. As we pick off the pieces that we decide are actually feasible, they should probably become separate tickets. But I think these are all of a piece and might benefit from some general thought about the whole `SPECIALIZE instance` pragma and how improvements here can make a big difference when we have dependent types. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 20:02:03 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 20:02:03 -0000 Subject: [GHC] #10906: `SPECIALIZE instance` could be better In-Reply-To: <047.543c3642e928cd31af650afc3fdc96ba@haskell.org> References: <047.543c3642e928cd31af650afc3fdc96ba@haskell.org> Message-ID: <062.df82ed649f5396caffe73de3d4113d3f@haskell.org> #10906: `SPECIALIZE instance` could be better -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * Attachment "HList.hs" added. full compiling example of the problem -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 20:04:58 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 20:04:58 -0000 Subject: [GHC] #7133: GHCi: strange behaviour after CTRL-C, followed by 'hPutChar: resource vanished (Broken Pipe)' when quitting In-Reply-To: <053.2b0536115707fa6b35bc3c14838eb88c@haskell.org> References: <053.2b0536115707fa6b35bc3c14838eb88c@haskell.org> Message-ID: <068.a50d92c75a9d192d68fb5c19bad861ab@haskell.org> #7133: GHCi: strange behaviour after CTRL-C, followed by 'hPutChar: resource vanished (Broken Pipe)' when quitting -------------------------------------+------------------------------------- Reporter: DuncanMortimer | Owner: tibbe Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.4.1 Resolution: worksforme | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: infoneeded => closed * resolution: => worksforme Comment: Replying to [comment:5 carter]: > I can't reproduce this in 7.8.3 on OS X 10.9 with the 10.9 terminal app Closing as worksforme. DuncanMortimer: Please reopen if this is still a problem with the latest release of GHC. Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 20:25:48 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 20:25:48 -0000 Subject: [GHC] #8010: Add forkOSUnmasked (patch) In-Reply-To: <048.eb7119d903e5adba0673b07e7cf0b9ea@haskell.org> References: <048.eb7119d903e5adba0673b07e7cf0b9ea@haskell.org> Message-ID: <063.6d78ce50b51ebeceba28c284d4e08729@haskell.org> #8010: Add forkOSUnmasked (patch) -------------------------------------+------------------------------------- Reporter: joeyadams | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: infoneeded => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 20:30:06 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 20:30:06 -0000 Subject: [GHC] #10906: `SPECIALIZE instance` could be better In-Reply-To: <047.543c3642e928cd31af650afc3fdc96ba@haskell.org> References: <047.543c3642e928cd31af650afc3fdc96ba@haskell.org> Message-ID: <062.60975e3a61983c1c089ddc4fb47b323f@haskell.org> #10906: `SPECIALIZE instance` could be better -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * failure: None/Unknown => Runtime performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 20:45:34 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 20:45:34 -0000 Subject: [GHC] #8213: Bad error message when using lazy IO to read from closed handle In-Reply-To: <042.5924f470797110e67b267f26b67ddb5f@haskell.org> References: <042.5924f470797110e67b267f26b67ddb5f@haskell.org> Message-ID: <057.e59a0a3decc022a0353fa8580451a34e@haskell.org> #8213: Bad error message when using lazy IO to read from closed handle -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 7.6.3 Resolution: worksforme | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: infoneeded => closed * cc: ekmett (added) * resolution: => worksforme Comment: Assuming this is fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 21:55:25 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 21:55:25 -0000 Subject: [GHC] #3990: UNPACK doesn't unbox data families In-Reply-To: <041.50e84dc9fb16fae63af270459584532c@haskell.org> References: <041.50e84dc9fb16fae63af270459584532c@haskell.org> Message-ID: <056.6b49ca963870e182e0f73c78ee6299a1@haskell.org> #3990: UNPACK doesn't unbox data families -------------------------------------+------------------------------------- Reporter: rl | Owner: Type: bug | Status: new Priority: low | Milestone: 8.0.1 Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by vagarenko): * cc: vagarenko (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 21:56:19 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 21:56:19 -0000 Subject: [GHC] #7647: UNPACK polymorphic fields In-Reply-To: <045.8091f80cf766b683cf12520609e77aee@haskell.org> References: <045.8091f80cf766b683cf12520609e77aee@haskell.org> Message-ID: <060.ffc6d5a8b96384fbb7178fbe56ffc54c@haskell.org> #7647: UNPACK polymorphic fields -------------------------------------+------------------------------------- Reporter: liyang | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #3990 #9655 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by vagarenko): * cc: vagarenko (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 21:58:28 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 21:58:28 -0000 Subject: [GHC] #10016: UNPACK support for existentials In-Reply-To: <046.c8a66a042094ff097eced717a1d59a97@haskell.org> References: <046.c8a66a042094ff097eced717a1d59a97@haskell.org> Message-ID: <061.b58dff21c60425dad6456970235e10b2@haskell.org> #10016: UNPACK support for existentials -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by vagarenko): * cc: vagarenko (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 22:02:32 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 22:02:32 -0000 Subject: [GHC] #9214: UNPACK support for sum types In-Reply-To: <047.5213ff1d75a2abd5ff04d6c7bb79813f@haskell.org> References: <047.5213ff1d75a2abd5ff04d6c7bb79813f@haskell.org> Message-ID: <062.d01522697267258ac6763f782f7eb447@haskell.org> #9214: UNPACK support for sum types -------------------------------------+------------------------------------- Reporter: mojojojo | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * failure: None/Unknown => Runtime performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 22:02:58 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 22:02:58 -0000 Subject: [GHC] #10016: UNPACK support for existentials In-Reply-To: <046.c8a66a042094ff097eced717a1d59a97@haskell.org> References: <046.c8a66a042094ff097eced717a1d59a97@haskell.org> Message-ID: <061.2ce2c938f1dda04a2255a19356f314b4@haskell.org> #10016: UNPACK support for existentials -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * failure: None/Unknown => Runtime performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 22:22:12 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 22:22:12 -0000 Subject: [GHC] #10905: Incorrect number of parameters in "role" errors In-Reply-To: <047.769c113cdba80683b91dbad9e4b88b4d@haskell.org> References: <047.769c113cdba80683b91dbad9e4b88b4d@haskell.org> Message-ID: <062.9861764abc833790325b71986d4b9d43@haskell.org> #10905: Incorrect number of parameters in "role" errors -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: roles Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): I don't think my reasoning was any deeper than the comment says. In the example in the Description, the roles are a distraction from the main point: the constructor isn't in scope. They just get in the way, and for most people will be mysterious and confusing. Do we even want to see these role, or perhaps the roles of type constructors we have decomposed on the way to getting this error? To put it another way, can you give an example of where they are useful? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 22:34:32 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 22:34:32 -0000 Subject: [GHC] #8645: Improper response from GHCI terminal after importing Gnuplot package In-Reply-To: <051.926a46b3cb70a08f679d592a060daaf2@haskell.org> References: <051.926a46b3cb70a08f679d592a060daaf2@haskell.org> Message-ID: <066.87bb2537cc8e872f70fe0bfffa3ff231@haskell.org> #8645: Improper response from GHCI terminal after importing Gnuplot package -------------------------------------+------------------------------------- Reporter: pankajsejwal | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: worksforme | Keywords: ghci, | gnuplot Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: infoneeded => closed * resolution: => worksforme Comment: Please reopen if this is still a problem with the latest release of GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 22:35:16 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 22:35:16 -0000 Subject: [GHC] #8665: RELEASE_LOCK: I do not own this lock In-Reply-To: <044.046fcc75b25880b48183ae432cde742a@haskell.org> References: <044.046fcc75b25880b48183ae432cde742a@haskell.org> Message-ID: <059.964131d5ba5cf722841e6e87c30ab590@haskell.org> #8665: RELEASE_LOCK: I do not own this lock -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: infoneeded => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 22:49:09 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 22:49:09 -0000 Subject: [GHC] Batch modify: #3034, #5188, #5780, #5941, #7109, #7763, #8426, ... Message-ID: <20150921224909.3E7843A2FF@ghc.haskell.org> Batch modification to #3034, #5188, #5780, #5941, #7109, #7763, #8426, #8572, #8594, #8910, #9009, #9043, #9089 by thomie: Action: provideinfo -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 23:13:55 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 23:13:55 -0000 Subject: [GHC] #2064: problems with duplicate modules In-Reply-To: <047.fdf7f2c34537ee71076b19d77bccf5a5@haskell.org> References: <047.fdf7f2c34537ee71076b19d77bccf5a5@haskell.org> Message-ID: <062.0ab1c88710ce48335184ff3bc75d9bd8@haskell.org> #2064: problems with duplicate modules -------------------------------------+------------------------------------- Reporter: Frederik | Owner: Type: bug | Status: closed Priority: lowest | Milestone: Component: Package system | Version: 6.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * failure: => None/Unknown * resolution: => fixed * milestone: 8.0.1 => Comment: Cabal checks for duplicate exposed-modules in .cabal files nowadays. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 23:18:32 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 23:18:32 -0000 Subject: [GHC] #2374: MutableByteArray# is slower than Addr# In-Reply-To: <044.46877f1bb530048ac22aec20e1b9d3f2@haskell.org> References: <044.46877f1bb530048ac22aec20e1b9d3f2@haskell.org> Message-ID: <059.d8403429bd82a9abb33f723ee1383777@haskell.org> #2374: MutableByteArray# is slower than Addr# -------------------------------------+------------------------------------- Reporter: dolio | Owner: Type: bug | Status: new Priority: lowest | Milestone: 8.0.1 Component: Compiler (NCG) | Version: 6.8.2 Resolution: | Keywords: | performance array Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * failure: => Runtime performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 21 23:30:57 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Sep 2015 23:30:57 -0000 Subject: [GHC] #2147: unhelpful error message for a misplaced DEPRECATED pragma In-Reply-To: <044.4706a1b0e36567a842f434c8ed45f7f6@haskell.org> References: <044.4706a1b0e36567a842f434c8ed45f7f6@haskell.org> Message-ID: <059.b4f81107048d26a4f3de4cf16f926f69@haskell.org> #2147: unhelpful error message for a misplaced DEPRECATED pragma -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: lowest | Milestone: 8.0.1 Component: Compiler | Version: 6.8.2 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * failure: => None/Unknown * component: Compiler => Compiler (Parser) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 22 00:30:10 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Sep 2015 00:30:10 -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.c3f67ef3764d1c12fd78ed0684d97839@haskell.org> #7947: Name conflict with DerivingDataTypeable, StandaloneDeriving and qualified imports -------------------------------------+------------------------------------- Reporter: a.ulrich | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.7 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | deriving/should_compile/T7947 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"d4d34a73aacc225a8f28d7138137bf548c9e51cc/ghc" d4d34a73/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d4d34a73aacc225a8f28d7138137bf548c9e51cc" Make derived names deterministic The names of auxiliary bindings end up in the interface file, and since uniques are nondeterministic, we end up with nondeterministic interface files. This uses the package and module name in the generated name, so I believe it should avoid problems from #7947 and be deterministic as well. The generated names look like this now: `$cLrlbmVwI3gpI8G2E6Hg3mO` and with `-ppr-debug`: `$c$aeson_70dylHtv1FFGeai1IoxcQr$Data.Aeson.Types.Internal$String`. Reviewed By: simonmar, austin, ezyang Differential Revision: https://phabricator.haskell.org/D1133 GHC Trac Issues: #4012 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 22 00:30:10 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Sep 2015 00:30:10 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.74cc22570eb9ea539e5dfafafaa14274@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"d4d34a73aacc225a8f28d7138137bf548c9e51cc/ghc" d4d34a73/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d4d34a73aacc225a8f28d7138137bf548c9e51cc" Make derived names deterministic The names of auxiliary bindings end up in the interface file, and since uniques are nondeterministic, we end up with nondeterministic interface files. This uses the package and module name in the generated name, so I believe it should avoid problems from #7947 and be deterministic as well. The generated names look like this now: `$cLrlbmVwI3gpI8G2E6Hg3mO` and with `-ppr-debug`: `$c$aeson_70dylHtv1FFGeai1IoxcQr$Data.Aeson.Types.Internal$String`. Reviewed By: simonmar, austin, ezyang Differential Revision: https://phabricator.haskell.org/D1133 GHC Trac Issues: #4012 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 22 02:01:44 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Sep 2015 02:01:44 -0000 Subject: [GHC] #9927: Should simplifier try more iterations? In-Reply-To: <047.578e70cae2a9663a3bc68c7bc786ce1f@haskell.org> References: <047.578e70cae2a9663a3bc68c7bc786ce1f@haskell.org> Message-ID: <062.7fea6a6e5176d23a0a10bfcc634b2b50@haskell.org> #9927: Should simplifier try more iterations? -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): What is the meaning of the bracketed list in the output? When I posted this ticket, I assumed they were the sizes of something... something which is getting remarkably small. Upon further reflection, they appear to be differences of sizes of something, in which case the simplifier really is petering out. But a quick look at the code doesn't answer the question. Does anyone know? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 22 02:49:13 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Sep 2015 02:49:13 -0000 Subject: [GHC] #1830: Automatic derivation of Lift In-Reply-To: <044.3eb409743bc4021eb94e63cb46f573bc@haskell.org> References: <044.3eb409743bc4021eb94e63cb46f573bc@haskell.org> Message-ID: <059.d8c7b247b5bcd30e3fd01fc8afa75e2c@haskell.org> #1830: Automatic derivation of Lift -------------------------------------+------------------------------------- Reporter: guest | Owner: | RyanGlScott Type: feature request | Status: new Priority: normal | Milestone: ? Component: Template Haskell | Version: 6.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1168 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"089b72f524a6a7564346baca9595fcd07081ec40/ghc" 089b72f5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="089b72f524a6a7564346baca9595fcd07081ec40" DeriveLift extension (#1830) Summary: This implements -XDeriveLift, which allows for automatic derivation of the Lift class from template-haskell. The implementation is based off of Ian Lynagh's th-lift library (http://hackage.haskell.org/package/th-lift). Test Plan: ./validate Reviewers: hvr, simonpj, bgamari, goldfire, austin Reviewed By: goldfire, austin Subscribers: osa1, thomie Differential Revision: https://phabricator.haskell.org/D1168 GHC Trac Issues: #1830 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 22 05:02:18 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Sep 2015 05:02:18 -0000 Subject: [GHC] #10375: arm: ghci hits an illegal instruction In-Reply-To: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> References: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> Message-ID: <059.ab63e5d39dc32b820f2cce60e969171c@haskell.org> #10375: arm: ghci hits an illegal instruction -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: Runtime System | Version: 7.10.1 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by erikd): Debugging with GDB was too un-reliable, even with Virtual Address randomization disabled in the Linux kernel and master tick timer disabled (`+RTS -V0 -RTS`). However, running with `+RTS -Da -RTS` I noticed that one of the last things the program did before crashing was to print out a `BCO` (Bycode compiled object). Unfortunately, the output with `-Ds` was simply way too verbose. Adding some custom debug which was only activated after the BCO was loaded showed that the crash (sometimes SIGILL, sometimes SIGSEGV) was happening some time after the call to `StgRun` in `rts/Schedule.c`. Since, the crash after calling `StgRun` happens immediately after loading the BCO, my suspicion is that the `StgRun` call is actually calling the recently loaded BCO. My custom debug shows something along the lines of (eliding irrelevant stuff): {{{ StgRun call 128 StgRun call 129 StgRun call 130 BCO 0: PUSH_ALTS 0xb39c2d08 2: PUSH_L 2 4: ENTER INSTRS: 6 0 2 2 46 PTRS: 0xb39c2d08 SthRun call 131 Segmentation fault }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 22 05:47:03 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Sep 2015 05:47:03 -0000 Subject: [GHC] #10375: arm: ghci hits an illegal instruction In-Reply-To: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> References: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> Message-ID: <059.4c9370a40cb5891cc0785b3688b65abf@haskell.org> #10375: arm: ghci hits an illegal instruction -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: Runtime System | Version: 7.10.1 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by erikd): Adding more custom debug just before the call to `StgRun` I find that `cap->r.rSp`, `rSpLim` and `rHp` are all null pointers and `rHpLim` is `0x1`, even on calls to `StgRun` that do not crash. Why? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 22 08:00:12 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Sep 2015 08:00:12 -0000 Subject: [GHC] #10904: C finalizer may be called on re-used memory In-Reply-To: <046.82d7a624ac5d38e3fd81c14129ab8c8d@haskell.org> References: <046.82d7a624ac5d38e3fd81c14129ab8c8d@haskell.org> Message-ID: <061.fabc88cca5bca0942e5315644614039d@haskell.org> #10904: C finalizer may be called on re-used memory -------------------------------------+------------------------------------- Reporter: bherzog | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.4.1 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonmar): I looked at the code, and I think you're right, there does seem to be a possibility that the finalizer will run after the memory has been reclaimed. As a workaround you can follow the suggestion you made, namely use `mallocBytes` and then `newForeignPtr`. I'll think about how this can be fixed. It's tricky, and we already have too much overhead for C finalizers (things got a lot more complicated during the recent changes to ensure ordering for finalizers, I think that's when the bug may have crept in). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 22 10:33:12 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Sep 2015 10:33:12 -0000 Subject: [GHC] #1012: ghc panic with mutually recursive modules and template haskell In-Reply-To: <044.e3ec0fd0938800cc6a7ce608eb8687c2@haskell.org> References: <044.e3ec0fd0938800cc6a7ce608eb8687c2@haskell.org> Message-ID: <059.af951daf3a1392d0876dd88dda49c21c@haskell.org> #1012: ghc panic with mutually recursive modules and template haskell -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: lowest | Milestone: 8.0.1 Component: Template Haskell | Version: 6.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | TH_import_loop Blocked By: | Blocking: Related Tickets: #9032 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): Replying to [comment:34 jstolarek]: > #9032 looks related (not sure if it's a duplicate or not). It's not a duplicate. #9032 is fixed, but `make test TEST=TH_import_loop` (this ticket) is still failing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 22 10:50:01 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Sep 2015 10:50:01 -0000 Subject: [GHC] #10830: maximumBy has a space leak In-Reply-To: <051.80712d357123f27d6467f28abef6100b@haskell.org> References: <051.80712d357123f27d6467f28abef6100b@haskell.org> Message-ID: <066.760e414325fd66ecb611cd9bafebab16@haskell.org> #10830: maximumBy has a space leak -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.3 Component: libraries/base | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1205 -------------------------------------+------------------------------------- Comment (by NeilMitchell): I'm a little confused. The diff fixes foldr1, I can't quite understand how any version based on foldr1 could ever avoid the space leak - although I agree that the inlining may reduce the space leak by a constant factor. I also note that the test has 100K of stack, while with GHC 7.8 it was fine in 1K of stack - perhaps the test bound should be significantly reduced? And finally, the code as currently written, maximumBy calls foldl not foldr, did that change after your patch went in? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 22 11:16:27 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Sep 2015 11:16:27 -0000 Subject: [GHC] #9927: Should simplifier try more iterations? In-Reply-To: <047.578e70cae2a9663a3bc68c7bc786ce1f@haskell.org> References: <047.578e70cae2a9663a3bc68c7bc786ce1f@haskell.org> Message-ID: <062.fb0b12acf2144fb81a23b2acd11738c8@haskell.org> #9927: Should simplifier try more iterations? -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): You mean this {{{ WARNING: file compiler/simplCore/SimplCore.hs, line 600 Simplifier bailing out after 4 iterations [2187, 49, 3, 1] }}} The numbers are the numbers of transformations carried out in each iteration. If you see `[blah, 1,1,1]` it's clue that maybe some transformation isn't making progress and is happening repeatedly, or generally that the cascade of transformations isn't working well. Increasing the iteration count can show this up even more vividly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 22 11:22:52 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Sep 2015 11:22:52 -0000 Subject: [GHC] #10906: `SPECIALIZE instance` could be better In-Reply-To: <047.543c3642e928cd31af650afc3fdc96ba@haskell.org> References: <047.543c3642e928cd31af650afc3fdc96ba@haskell.org> Message-ID: <062.335dfc8b752dd1c37fcf72bfb973412b@haskell.org> #10906: `SPECIALIZE instance` could be better -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): I'm out of bandwidth at the moment, but * There is no reason not to allow `{-# SPECIALISE instance ... #-}` in an importing module. As you say, to make sure that the methods got specialised (which is the whole point) you'd have to decorate each of them with `{-# INLINEABLE #-}`, but that's fair enough. * I don't understand why "one specialisation doesn't use another". * I don't understand the type-family restriction. Maybe it's accidental. Happy to advise. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 22 11:46:36 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Sep 2015 11:46:36 -0000 Subject: [GHC] #10830: maximumBy has a space leak In-Reply-To: <051.80712d357123f27d6467f28abef6100b@haskell.org> References: <051.80712d357123f27d6467f28abef6100b@haskell.org> Message-ID: <066.45d894052ce2ca1a032a029f773235d8@haskell.org> #10830: maximumBy has a space leak -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.3 Component: libraries/base | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1205 -------------------------------------+------------------------------------- Changes (by nomeata): * status: closed => new * resolution: fixed => Comment: > I'm a little confused. So am I :-) Looks like I modified `foldr1`, while the test case still tested `maximumBy` from `Data.OldList` which still goes via `foldl1`, and thus was always ok for the test case. The `maximumBy` that one gets from `Data.List` is the one from `Foldable`, which goes via `foldr1`, so it stills blows the stack. But I?m not sure what to do here. We might be able to special-case `Int` and `Integer`, but that does not seem to be a good solution... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 22 11:47:49 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Sep 2015 11:47:49 -0000 Subject: [GHC] #9927: Should simplifier try more iterations? In-Reply-To: <047.578e70cae2a9663a3bc68c7bc786ce1f@haskell.org> References: <047.578e70cae2a9663a3bc68c7bc786ce1f@haskell.org> Message-ID: <062.0229dda4fe594c6ab9fc459bfe1aed88@haskell.org> #9927: Should simplifier try more iterations? -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 7.11 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => invalid Comment: Ah -- I misunderstood. In this case, I think 4 is the right setting, as it often tails off to (or close to) `1`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 22 11:55:02 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Sep 2015 11:55:02 -0000 Subject: [GHC] #8990: Performance tests behave differently depending on presence of .hi file (even with -fforce-recomp) In-Reply-To: <045.abd2027873a2b9d9a2bc9aa2b4b749ea@haskell.org> References: <045.abd2027873a2b9d9a2bc9aa2b4b749ea@haskell.org> Message-ID: <060.26c50d5a2415ffd4b2d50b3b88b1783d@haskell.org> #8990: Performance tests behave differently depending on presence of .hi file (even with -fforce-recomp) -------------------------------------+------------------------------------- Reporter: ezyang | Owner: przembot Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Test Suite | Version: 7.9 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1267 -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch * differential: => Phab:D1267 * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 22 11:57:35 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Sep 2015 11:57:35 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.d3840be10fb5a8d6524803e2cbc193c0@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, | Phab:D1268 -------------------------------------+------------------------------------- Changes (by niteria): * differential: Phab:D910, Phab:D1073, Phab:D1133, Phab:D1192 => Phab:D910, Phab:D1073, Phab:D1133, Phab:D1192, Phab:D1268 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 22 12:20:50 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Sep 2015 12:20:50 -0000 Subject: [GHC] #2595: Implement record update for existential and GADT data types In-Reply-To: <046.4aca36ddfd3abd8f80e6714ed9319183@haskell.org> References: <046.4aca36ddfd3abd8f80e6714ed9319183@haskell.org> Message-ID: <061.113e694a6567ab3b1bea961f9cb66666@haskell.org> #2595: Implement record update for existential and GADT data types -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: tc244 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by jkarni): * cc: jkarni@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 22 13:04:51 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Sep 2015 13:04:51 -0000 Subject: [GHC] #10891: `reify` doesn't find associated type families In-Reply-To: <046.9e704f075dee9514291b5d5766834bf9@haskell.org> References: <046.9e704f075dee9514291b5d5766834bf9@haskell.org> Message-ID: <061.eab97849fb0d01f9a4053dfbdf983d6e@haskell.org> #10891: `reify` doesn't find associated type families -------------------------------------+------------------------------------- Reporter: antalsz | Owner: osa1 Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: type | families; newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:1254 -------------------------------------+------------------------------------- Changes (by osa1): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 22 13:05:23 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Sep 2015 13:05:23 -0000 Subject: [GHC] #10891: `reify` doesn't find associated type families In-Reply-To: <046.9e704f075dee9514291b5d5766834bf9@haskell.org> References: <046.9e704f075dee9514291b5d5766834bf9@haskell.org> Message-ID: <061.c1cdce92d4aaebdd7101b8b33219b97a@haskell.org> #10891: `reify` doesn't find associated type families -------------------------------------+------------------------------------- Reporter: antalsz | Owner: osa1 Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: type | families; newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1254 -------------------------------------+------------------------------------- Changes (by osa1): * differential: Phab:1254 => Phab:D1254 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 22 13:43:10 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Sep 2015 13:43:10 -0000 Subject: [GHC] #10830: maximumBy has a space leak In-Reply-To: <051.80712d357123f27d6467f28abef6100b@haskell.org> References: <051.80712d357123f27d6467f28abef6100b@haskell.org> Message-ID: <066.8b70295866f7d21e0111a6c3cd7ae33e@haskell.org> #10830: maximumBy has a space leak -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.3 Component: libraries/base | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1205 -------------------------------------+------------------------------------- Comment (by NeilMitchell): It's pretty rare that you are using `maximumBy` with a custom function and the result type is {{{Int}}} or {{{Integer}}} - typically you'd just use {{{minimum}}} or {{{maximum}}} directly - so I don't think special cases are likely to be of any benefit. I think using {{{foldl1}}} is the only way to reduce the space leak, which is what happened in base-4.7 for Data.List. The Foldable variants have always been foldr1, but maybe that's a bug in Foldable? It's certainly a BBP regression. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 22 13:47:46 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Sep 2015 13:47:46 -0000 Subject: [GHC] #10907: GHC fails to read file with byte-order mark when LANG=C Message-ID: <050.38d42c04556dad88e5087381da8b4d80@haskell.org> #10907: GHC fails to read file with byte-order mark when LANG=C -------------------------------------+------------------------------------- Reporter: | Owner: RyanGlScott | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: GHC doesn't work (amd64) | at all Test Case: | Blocked By: Blocking: | Related Tickets: #6016, #6037 Differential Revisions: | -------------------------------------+------------------------------------- I've attached a minimal example that causes the problem. Compiling `ByteOrderMark.hs` like so fails: {{{ $ LANG=C ghc ByteOrderMark.hs ByteOrderMark.hs: hLookAhead: invalid argument (invalid byte sequence) }}} I can reproduce this on x86_64 Linux using GHC 7.10.2 and HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 22 13:48:06 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Sep 2015 13:48:06 -0000 Subject: [GHC] #10907: GHC fails to read file with byte-order mark when LANG=C In-Reply-To: <050.38d42c04556dad88e5087381da8b4d80@haskell.org> References: <050.38d42c04556dad88e5087381da8b4d80@haskell.org> Message-ID: <065.3231cb2bd504006a0b608c6c40346540@haskell.org> #10907: GHC fails to read file with byte-order mark when LANG=C -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC doesn't work | (amd64) at all | Test Case: Blocked By: | Blocking: Related Tickets: #6016, #6037 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by RyanGlScott): * Attachment "ByteOrderMark.hs" added. Minimal example -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 22 13:48:50 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Sep 2015 13:48:50 -0000 Subject: [GHC] #10907: GHC fails to read file with byte-order mark when LANG=C In-Reply-To: <050.38d42c04556dad88e5087381da8b4d80@haskell.org> References: <050.38d42c04556dad88e5087381da8b4d80@haskell.org> Message-ID: <065.108bd773e441d8bf70c427a5b9d74d38@haskell.org> #10907: GHC fails to read file with byte-order mark when LANG=C -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC doesn't work | (amd64) at all | Test Case: Blocked By: | Blocking: Related Tickets: #6016, #6037 | Differential Revisions: -------------------------------------+------------------------------------- Description changed by RyanGlScott: Old description: > I've attached a minimal example that causes the problem. Compiling > `ByteOrderMark.hs` like so fails: > > {{{ > $ LANG=C ghc ByteOrderMark.hs > ByteOrderMark.hs: hLookAhead: invalid argument (invalid byte sequence) > }}} > > I can reproduce this on x86_64 Linux using GHC 7.10.2 and HEAD. New description: I've attached a minimal example that causes the problem. Compiling `ByteOrderMark.hs` like so fails: {{{ $ LANG=C ghc ByteOrderMark.hs ByteOrderMark.hs: hLookAhead: invalid argument (invalid byte sequence) }}} I can reproduce this on x86_64 Linux using GHC 7.10.2 and HEAD. Note that compiling it without `LANG=C` does work. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 22 13:49:08 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Sep 2015 13:49:08 -0000 Subject: [GHC] #10830: maximumBy has a space leak In-Reply-To: <051.80712d357123f27d6467f28abef6100b@haskell.org> References: <051.80712d357123f27d6467f28abef6100b@haskell.org> Message-ID: <066.6d122fb1ba7f62c32d60fb93720ddcf3@haskell.org> #10830: maximumBy has a space leak -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.3 Component: libraries/base | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1205 -------------------------------------+------------------------------------- Comment (by nomeata): Yes, ignore the comment about special-casing. That only works for `minimum` and `maximum`. I?ve prodded Herbert and Edward on IRC about this, as this is more a BBP design issue than a compiler bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 22 13:55:39 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Sep 2015 13:55:39 -0000 Subject: [GHC] #10365: Implement Semigroup as a superclass of Monoid Proposal (Phase 1) In-Reply-To: <044.91d55a6870e3dd391fca3990f924a9d5@haskell.org> References: <044.91d55a6870e3dd391fca3990f924a9d5@haskell.org> Message-ID: <059.32fdb24201dc640689d6f14cb3439a76@haskell.org> #10365: Implement Semigroup as a superclass of Monoid Proposal (Phase 1) -------------------------------------+------------------------------------- Reporter: gidyn | Owner: Type: feature request | Status: new Priority: high | Milestone: 8.0.1 Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: report- | impact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 22 14:09:04 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Sep 2015 14:09:04 -0000 Subject: [GHC] #10830: maximumBy has a space leak In-Reply-To: <051.80712d357123f27d6467f28abef6100b@haskell.org> References: <051.80712d357123f27d6467f28abef6100b@haskell.org> Message-ID: <066.55c1b1a2b2ff7ea96d269a37d59d2755@haskell.org> #10830: maximumBy has a space leak -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.3 Component: libraries/base | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1205 -------------------------------------+------------------------------------- Comment (by George): Replying to [comment:10 thoughtpolice]: > If 7.10.3 ever exists (no commitment!), then this should go in. Shouldn't priority be set to high if we want it in 7.10.3? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 22 14:46:12 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Sep 2015 14:46:12 -0000 Subject: [GHC] #10877: x86_64: dll-split: out of memory (requested 1099512676352 bytes) In-Reply-To: <050.ab3ee9d3ff60499476bc10d829ff13d9@haskell.org> References: <050.ab3ee9d3ff60499476bc10d829ff13d9@haskell.org> Message-ID: <065.31b3cba9af41c12fd79cb4f99f49285b@haskell.org> #10877: x86_64: dll-split: out of memory (requested 1099512676352 bytes) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: #10682 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * cc: simonmar (added) Comment: simonmar, perhaps we should be looking at the ulimit and adjust our allocation request downwards if necessary? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 22 16:06:16 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Sep 2015 16:06:16 -0000 Subject: [GHC] #10877: x86_64: dll-split: out of memory (requested 1099512676352 bytes) In-Reply-To: <050.ab3ee9d3ff60499476bc10d829ff13d9@haskell.org> References: <050.ab3ee9d3ff60499476bc10d829ff13d9@haskell.org> Message-ID: <065.e8984d095e7104cefc593299770e4304@haskell.org> #10877: x86_64: dll-split: out of memory (requested 1099512676352 bytes) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: #10682 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonmar): Urgh, the problem is that making the size of the area dynamic imposes a runtime cost - we have to read that value every time the GC visits an object. But I can't think of an alternative. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 22 16:12:00 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Sep 2015 16:12:00 -0000 Subject: [GHC] #8213: Bad error message when using lazy IO to read from closed handle In-Reply-To: <042.5924f470797110e67b267f26b67ddb5f@haskell.org> References: <042.5924f470797110e67b267f26b67ddb5f@haskell.org> Message-ID: <057.61cd8473af8f7ca7cca52893fc48dbb3@haskell.org> #8213: Bad error message when using lazy IO to read from closed handle -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 7.6.3 Resolution: worksforme | 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 nh2): Hmm, odd; when I now try to reproduce it, I also see `test: test.hs: hGetBufSome: illegal operation (handle is closed)`, even with 7.6.3 against I reported this bug; yes, I think it was on Linux. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 22 21:51:21 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Sep 2015 21:51:21 -0000 Subject: [GHC] #10599: Template Haskell doesn't allow `newName "type"` In-Reply-To: <048.829d4ff7778a587a956aa230325a65a0@haskell.org> References: <048.829d4ff7778a587a956aa230325a65a0@haskell.org> Message-ID: <063.f1accc6485c88ee0cc4e45b530511b75@haskell.org> #10599: Template Haskell doesn't allow `newName "type"` -------------------------------------+------------------------------------- Reporter: meteficha | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.2-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by k-bx): Just to mention that it affected our codebase, because we use {{{ $(makeLensesWith abbreviatedFields ''Geo) }}} And some fields happen to be named like "_fooType". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 22 23:45:14 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Sep 2015 23:45:14 -0000 Subject: [GHC] #10907: GHC fails to read file with byte-order mark when LANG=C In-Reply-To: <050.38d42c04556dad88e5087381da8b4d80@haskell.org> References: <050.38d42c04556dad88e5087381da8b4d80@haskell.org> Message-ID: <065.c9eb43072aeba317c8a4b7ba0a2789a8@haskell.org> #10907: GHC fails to read file with byte-order mark when LANG=C -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC doesn't work | (amd64) at all | Test Case: Blocked By: | Blocking: Related Tickets: #6016, #6037 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by osa1): Just tried this and it worked fine on my x86_64 Linux, with GHC 7.10.1 and HEAD. Is there anything else I need to set other than `LANG`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 22 23:47:26 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Sep 2015 23:47:26 -0000 Subject: [GHC] #10907: GHC fails to read file with byte-order mark when LANG=C In-Reply-To: <050.38d42c04556dad88e5087381da8b4d80@haskell.org> References: <050.38d42c04556dad88e5087381da8b4d80@haskell.org> Message-ID: <065.c95391143bc217f74ad476c8740f3e9e@haskell.org> #10907: GHC fails to read file with byte-order mark when LANG=C -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC doesn't work | (amd64) at all | Test Case: Blocked By: | Blocking: Related Tickets: #6016, #6037 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by osa1): Sorry, I had to unset `$LC_CTYPE`, now I can reproduce. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 00:28:04 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 00:28:04 -0000 Subject: [GHC] #10652: Better cache performance in Array# In-Reply-To: <050.29d287c6c00bdf49b58de908b0c4a371@haskell.org> References: <050.29d287c6c00bdf49b58de908b0c4a371@haskell.org> Message-ID: <065.c7f226e1cb2eb127c02d10f62f8bb735@haskell.org> #10652: Better cache performance in Array# -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by carter): This seems to overlap with the array tech that Edward Kmett has demoed for mutable data structures and the resulting conversations that ensured on the mailing lists and at icfp 2015. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 01:10:23 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 01:10:23 -0000 Subject: [GHC] #10908: -fwarn-missing-exported-sigs doesn't respect qualified names Message-ID: <047.8049acc3e53dbcc2c0ac7fc46b25d3cc@haskell.org> #10908: -fwarn-missing-exported-sigs doesn't respect qualified names -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Trying to help @mpickering with Phab:D1258, I looked at the code in `tcRnSrcDecls` and was surprised to see that exports are renamed after this function is complete. This didn't make any sense to me. And, indeed, it's wrong, witness by this example: {{{ {-# OPTIONS_GHC -fwarn-missing-exported-sigs #-} module Bug (Data.List.intercalate, x) where import qualified Data.List intercalate = True x :: Bool x = intercalate }}} This produces {{{ Bug.hs:7:1: Warning: Top-level binding with no type signature: intercalate :: Bool }}} This warning should not be emitted. I'm not all that concerned about this scenario biting in the wild, but it suggests that refactoring this code is a good thing, and not something Phab:D1258 should take pains to avoid. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 07:27:19 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 07:27:19 -0000 Subject: [GHC] #10907: GHC fails to read file with byte-order mark when LANG=C In-Reply-To: <050.38d42c04556dad88e5087381da8b4d80@haskell.org> References: <050.38d42c04556dad88e5087381da8b4d80@haskell.org> Message-ID: <065.b9ca724265c9d78c821506775cdd30a6@haskell.org> #10907: GHC fails to read file with byte-order mark when LANG=C -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC doesn't work | (amd64) at all | Test Case: Blocked By: | Blocking: Related Tickets: #6016, #6037 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): I can confirm as well. Furthermore it worked with 7.8, and it only seems to affect files with a BOM, files with other unicode characters, but no BOM, are read successfully. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 07:41:09 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 07:41:09 -0000 Subject: [GHC] #10907: GHC fails to read file with byte-order mark when LANG=C In-Reply-To: <050.38d42c04556dad88e5087381da8b4d80@haskell.org> References: <050.38d42c04556dad88e5087381da8b4d80@haskell.org> Message-ID: <065.d302eeb6df73f0464fe0af897a15c9a0@haskell.org> #10907: GHC fails to read file with byte-order mark when LANG=C -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC doesn't work | (amd64) at all | Test Case: Blocked By: | Blocking: Related Tickets: #6016, #6037 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): It's quite likely caused by my patch for #6016. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 07:41:48 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 07:41:48 -0000 Subject: [GHC] #10907: GHC fails to read file with byte-order mark when LANG=C In-Reply-To: <050.38d42c04556dad88e5087381da8b4d80@haskell.org> References: <050.38d42c04556dad88e5087381da8b4d80@haskell.org> Message-ID: <065.21b435d94c08d3138c78830592ef451e@haskell.org> #10907: GHC fails to read file with byte-order mark when LANG=C -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC doesn't work | (amd64) at all | Test Case: Blocked By: | Blocking: Related Tickets: #6016, #6037 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): The problem seems to be `skipBOM` in `StringUtils.hs`, which switches to text mode so that `hLookAhead` is able to consume the whole BOM, instead of just the first character. But in text mode we are locale dependent. At first I thought it would make sense to stay in binary mode, but then `hLookAhead` returns just one bytes, which is not enough to detect a bom. Using `hGetChar` twice would help, but if there is no BOM, we?d have to rewind. Are we sure we can `hSeek` on all buffers that we need to? A `Word16` encoding would help. Or maybe it works well enough to force utf8 for this single `hLookAhead`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 07:42:40 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 07:42:40 -0000 Subject: [GHC] #10907: GHC fails to read file with byte-order mark when LANG=C In-Reply-To: <050.38d42c04556dad88e5087381da8b4d80@haskell.org> References: <050.38d42c04556dad88e5087381da8b4d80@haskell.org> Message-ID: <065.27a79c780fc2166df91503ff88838287@haskell.org> #10907: GHC fails to read file with byte-order mark when LANG=C -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC doesn't work | (amd64) at all | Test Case: Blocked By: | Blocking: Related Tickets: #6016, #6037 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): > It's quite likely caused by my patch for #6016. I believe so as well. Since you have touched that last, shall I leave this to you? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 07:52:03 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 07:52:03 -0000 Subject: [GHC] #10907: GHC fails to read file with byte-order mark when LANG=C In-Reply-To: <050.38d42c04556dad88e5087381da8b4d80@haskell.org> References: <050.38d42c04556dad88e5087381da8b4d80@haskell.org> Message-ID: <065.8337c5365087cd29afb53c5a5d64940e@haskell.org> #10907: GHC fails to read file with byte-order mark when LANG=C -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC doesn't work | (amd64) at all | Test Case: Blocked By: | Blocking: Related Tickets: #6016, #6037 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): Please go ahead and fix it yourself if you know of a good solution. Otherwise I'll put it on my list. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 07:58:30 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 07:58:30 -0000 Subject: [GHC] #10908: -fwarn-missing-exported-sigs doesn't respect qualified names In-Reply-To: <047.8049acc3e53dbcc2c0ac7fc46b25d3cc@haskell.org> References: <047.8049acc3e53dbcc2c0ac7fc46b25d3cc@haskell.org> Message-ID: <062.aa05e9ccb68bbf434239dd2c3727024d@haskell.org> #10908: -fwarn-missing-exported-sigs doesn't respect qualified names -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * cc: gridaphobe (added) Comment: CC @gridaphobe as the author of `-fwarn-missing-exported-sigs`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 08:06:28 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 08:06:28 -0000 Subject: [GHC] #10342: Convert User Guide from DocBook to AsciiDoc In-Reply-To: <047.a035ea91c12271763d1f9dbbec183a42@haskell.org> References: <047.a035ea91c12271763d1f9dbbec183a42@haskell.org> Message-ID: <062.78b60de0be57dae6a9d5b73393d4c4f5@haskell.org> #10342: Convert User Guide from DocBook to AsciiDoc -------------------------------------+------------------------------------- Reporter: dmbergey | Owner: dmbergey Type: task | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): I have looked into this in the past and found that asciidoc has a few rough edges that make a * conversion of the users guide rather ugly. I recently tried a conversion to ReStructuredText and was happy to find that a mostly mechanical conversion got quite far. I've proposed moving to ReStructuredText in [[https://mail.haskell.org/pipermail/ghc-devs/2015-September/010001.html this mailing list thread]] (which references my preliminary conversion). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 08:06:56 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 08:06:56 -0000 Subject: [GHC] #10909: Test suite: Support non-utf8 locale Message-ID: <046.fa6aac9d3c2ea6a99e9e4dcd0986d398@haskell.org> #10909: Test suite: Support non-utf8 locale -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- In order to properly test #10907, it should be possible to specify a locale (or at least some representative values like ?non-utf8-locale? and ?utf8-locale? in the options of a test. Currently, the test suite runs completely in an utf8-locale. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 08:11:11 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 08:11:11 -0000 Subject: [GHC] #10907: GHC fails to read file with byte-order mark when LANG=C In-Reply-To: <050.38d42c04556dad88e5087381da8b4d80@haskell.org> References: <050.38d42c04556dad88e5087381da8b4d80@haskell.org> Message-ID: <065.d651ec4dfce516716e9618c6f9c648ee@haskell.org> #10907: GHC fails to read file with byte-order mark when LANG=C -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC doesn't work | (amd64) at all | Test Case: Blocked By: | Blocking: Related Tickets: #6016, #6037 | Differential Revisions: Phab:D1274 -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => patch * differential: => Phab:D1274 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 08:40:13 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 08:40:13 -0000 Subject: [GHC] #10910: Data families seem not to be "surely apart" from anything Message-ID: <045.25f21c423f9fc853791a3c760b81c7a5@haskell.org> #10910: Data families seem not to be "surely apart" from anything -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: data | Operating System: Unknown/Multiple families, closed type families | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- The following code is not compiling (GHC 7.10.2), it looks as if data families are not considered "surely apart" from any type, despite being injective. {{{#!hs {-# LANGUAGE TypeFamilies, DataKinds, GADTs #-} type family Equals x y where Equals x x = True Equals x y = False data Booly b where Truey :: Booly True Falsey :: Booly False data family ID a data instance ID Bool = IB test :: Booly (Equals (ID Bool) Int) test = Falsey }}} (Inspired and simplified from http://stackoverflow.com/questions/32733368 /type-inequalities-in-the-presence-of-data-families#32733368.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 08:46:00 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 08:46:00 -0000 Subject: [GHC] #10910: Data families seem not to be "surely apart" from anything In-Reply-To: <045.25f21c423f9fc853791a3c760b81c7a5@haskell.org> References: <045.25f21c423f9fc853791a3c760b81c7a5@haskell.org> Message-ID: <060.a86690dcdb8eb6df3548b6ef6d3e6101@haskell.org> #10910: Data families seem not to be "surely apart" from anything -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: data | families, closed type families Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by oerjan: Old description: > The following code is not compiling (GHC 7.10.2), it looks as if data > families are not considered "surely apart" from any type, despite being > injective. > > {{{#!hs > {-# LANGUAGE TypeFamilies, DataKinds, GADTs #-} > > type family Equals x y where > Equals x x = True > Equals x y = False > > data Booly b where > Truey :: Booly True > Falsey :: Booly False > > data family ID a > > data instance ID Bool = IB > > test :: Booly (Equals (ID Bool) Int) > test = Falsey > }}} > > (Inspired and simplified from http://stackoverflow.com/questions/32733368 > /type-inequalities-in-the-presence-of-data-families#32733368.) New description: The following code is not compiling (GHC 7.10.2), it looks as if data families are not considered "surely apart" from any type, despite being injective. {{{#!hs {-# LANGUAGE TypeFamilies, DataKinds, GADTs #-} type family Equals x y where Equals x x = True Equals x y = False data Booly b where Truey :: Booly True Falsey :: Booly False data family ID a data instance ID Bool = IB test :: Booly (Equals (ID Bool) Int) test = Falsey }}} This gives the error {{{ Test.hs:16:8: Warning: Couldn't match type ?Equals (ID Bool) Int? with ?'False? Expected type: Booly (Equals (ID Bool) Int) Actual type: Booly 'False In the expression: Falsey In an equation for ?test?: test = Falsey }}} This gives no error with an ordinary type instead of a data family. (Inspired and simplified from http://stackoverflow.com/questions/32733368 /type-inequalities-in-the-presence-of-data-families#32733368.) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 08:51:00 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 08:51:00 -0000 Subject: [GHC] #10910: Data families seem not to be "surely apart" from anything In-Reply-To: <045.25f21c423f9fc853791a3c760b81c7a5@haskell.org> References: <045.25f21c423f9fc853791a3c760b81c7a5@haskell.org> Message-ID: <060.176241e6362a7417efbafbba15a84ad0@haskell.org> #10910: Data families seem not to be "surely apart" from anything -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: data | families, closed type families Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by benjamin.hodgson): * cc: benjamin.hodgson (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 08:53:45 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 08:53:45 -0000 Subject: [GHC] #10910: Data families seem not to be "surely apart" from anything In-Reply-To: <045.25f21c423f9fc853791a3c760b81c7a5@haskell.org> References: <045.25f21c423f9fc853791a3c760b81c7a5@haskell.org> Message-ID: <060.a58c66b9d850418307c8790e588501d6@haskell.org> #10910: Data families seem not to be "surely apart" from anything -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Keywords: data Resolution: | families, closed type families Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * component: Compiler => Compiler (Type checker) Comment: Compiles fine with HEAD (ghc-7.11.20150909). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 09:10:15 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 09:10:15 -0000 Subject: [GHC] #10904: C finalizer may be called on re-used memory In-Reply-To: <046.82d7a624ac5d38e3fd81c14129ab8c8d@haskell.org> References: <046.82d7a624ac5d38e3fd81c14129ab8c8d@haskell.org> Message-ID: <061.15115fde5600d56692c2e3740a82ecd9@haskell.org> #10904: C finalizer may be called on re-used memory -------------------------------------+------------------------------------- Reporter: bherzog | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 7.4.1 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1275 -------------------------------------+------------------------------------- Changes (by simonmar): * status: new => patch * differential: => Phab:D1275 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 09:54:20 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 09:54:20 -0000 Subject: [GHC] #10867: Primop types should not mention () In-Reply-To: <046.c2e6159f1c64c1079ec9b781aa715970@haskell.org> References: <046.c2e6159f1c64c1079ec9b781aa715970@haskell.org> Message-ID: <061.83751f869bb98ae02247e9b29e630311@haskell.org> #10867: Primop types should not mention () -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"c6bdf4fb0b06ac55a7bb200f0ef31ea9a7a830ec/ghc" c6bdf4fb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c6bdf4fb0b06ac55a7bb200f0ef31ea9a7a830ec" Remove references to () from types of mkWeak# and friends Previously the types needlessly used (), which is defined ghc-prim, leading to unfortunate import cycles. See #10867 for details. Updates stm submodule. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 11:37:43 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 11:37:43 -0000 Subject: [GHC] #10376: arm/linux linking failure In-Reply-To: <044.29ac411aa184ff9b10d3766853c9a35d@haskell.org> References: <044.29ac411aa184ff9b10d3766853c9a35d@haskell.org> Message-ID: <059.9b9239378367b499c266f0752d3405a8@haskell.org> #10376: arm/linux linking failure -------------------------------------+-------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #10464 | Differential Revisions: -------------------------------------+-------------------------------- Comment (by thomie): I'm stuck at `cabal install text` {{{ # Get a $3.40/month ?dedicated ARM server (thanks for the tip) $ sudo add-apt-repository 'deb http://ftp.fr.debian.org/debian experimental main' # add keys from https://ftp-master.debian.org/keys.html $ sudo apt-get update $ sudo apt-get install ghc/experimental cabal-install/experimental $ cabal install text Resolving dependencies... Configuring text-1.2.1.3... Failed to install text-1.2.1.3 Build log ( /home/thomas/.cabal/logs/text-1.2.1.3.log ): cabal: Error: some packages failed to install: text-1.2.1.3 failed during the configure step. The exception was: ExitFailure (-4) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 12:02:05 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 12:02:05 -0000 Subject: [GHC] #10342: Convert User Guide from DocBook to AsciiDoc In-Reply-To: <047.a035ea91c12271763d1f9dbbec183a42@haskell.org> References: <047.a035ea91c12271763d1f9dbbec183a42@haskell.org> Message-ID: <062.f3fc995c7f68ba2f8b42225b1234f5d7@haskell.org> #10342: Convert User Guide from DocBook to AsciiDoc -------------------------------------+------------------------------------- Reporter: dmbergey | Owner: dmbergey Type: task | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): I have started a [[https://ghc.haskell.org/trac/ghc/wiki/UsersGuide/MoveFromDocBook|page]] to describe this change. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 12:03:38 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 12:03:38 -0000 Subject: [GHC] #10910: Data families seem not to be "surely apart" from anything In-Reply-To: <045.25f21c423f9fc853791a3c760b81c7a5@haskell.org> References: <045.25f21c423f9fc853791a3c760b81c7a5@haskell.org> Message-ID: <060.ad0e4c7d1f1b754e709359f075cff8b7@haskell.org> #10910: Data families seem not to be "surely apart" from anything -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Keywords: data Resolution: duplicate | families, closed type families Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => duplicate Comment: Replying to [comment:3 thomie]: > Compiles fine with HEAD (ghc-7.11.20150909). Yes. I believe this is a dup of #10713. Thanks for reporting! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 12:04:21 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 12:04:21 -0000 Subject: [GHC] #10342: Convert User Guide from DocBook to AsciiDoc In-Reply-To: <047.a035ea91c12271763d1f9dbbec183a42@haskell.org> References: <047.a035ea91c12271763d1f9dbbec183a42@haskell.org> Message-ID: <062.a640b8bd41453a21e799b8aac60ec4de@haskell.org> #10342: Convert User Guide from DocBook to AsciiDoc -------------------------------------+------------------------------------- Reporter: dmbergey | Owner: dmbergey Type: task | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): Don't forget to update `utils/mkUserGuidePart`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 12:54:47 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 12:54:47 -0000 Subject: [GHC] #10376: arm/linux linking failure In-Reply-To: <044.29ac411aa184ff9b10d3766853c9a35d@haskell.org> References: <044.29ac411aa184ff9b10d3766853c9a35d@haskell.org> Message-ID: <059.4511ae4bcb6f6c53d11ae81a37e9f35d@haskell.org> #10376: arm/linux linking failure -------------------------------------+-------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #10464 | Differential Revisions: -------------------------------------+-------------------------------- Comment (by k-bx): That's weird. Posting more-precise instructions I've just replicated (they're not very precise, but rather "almost", as I did few errors and fixes in them): {{{ ssh new-server, Ubuntu Vivid $ sudo apt-get update $ sudo apt-get dist-upgrade $ sudo apt-get install cabal-install zlib1g-dev $ wget http://ftp.de.debian.org/debian/pool/main/g/ghc/ghc_7.10.2-2_armhf.deb $ sudo dpkg -i ./ghc* $ cabal update $ cabal install cabal-install --ghc-options="-j" (crunch-crunch-crunch, including text installation) $ sudo apt-get install libghc-zlib-dev libghc-zlib-bindings-dev $ echo 'PATH=/root/.cabal/bin:$PATH' >> ~/.profile $ source ~/.profile root at arm2:~# cat TextTest.hs {-# LANGUAGE OverloadedStrings #-} import qualified Data.Text.IO as T main = T.putStrLn "Hell" $ ghc TextTest.hs (warnings here) }}} @thomie please send me your public key so that I could add it to this machine -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 17:36:16 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 17:36:16 -0000 Subject: [GHC] #10897: Incorrect ASSERT for buildPatSyn In-Reply-To: <045.72f9540a916b61c61568cdbdec70fba4@haskell.org> References: <045.72f9540a916b61c61568cdbdec70fba4@haskell.org> Message-ID: <060.48029ae925512f2be46b962cb28b2147@haskell.org> #10897: Incorrect ASSERT for buildPatSyn -------------------------------------+------------------------------------- Reporter: ezyang | Owner: cactus Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | 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 cactus): Without having looked at the details yet, I'd just like to mention that the reason I've put those `ASSERT`s in is because the plan, at one point, was to eventually get rid of most arguments to `buildPatSyn` and just reconstruct them from the `matcher`'s `idType`. Unfortunately, I can't remember off-hand why that wasn't feasible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 17:36:33 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 17:36:33 -0000 Subject: [GHC] #10897: Incorrect ASSERT for buildPatSyn In-Reply-To: <045.72f9540a916b61c61568cdbdec70fba4@haskell.org> References: <045.72f9540a916b61c61568cdbdec70fba4@haskell.org> Message-ID: <060.515c0e6fddd6391468bf0dcb5079a728@haskell.org> #10897: Incorrect ASSERT for buildPatSyn -------------------------------------+------------------------------------- Reporter: ezyang | Owner: cactus Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by cactus): * keywords: => PatternSynonyms -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 17:39:32 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 17:39:32 -0000 Subject: =?utf-8?b?W0dIQ10gIzEwOTExOiBBbGxvdyBsZWZ0IOKIqCAoKysrKSBhcyBt?= =?utf-8?q?inimal_definition_of_ArrowChoice_instance?= Message-ID: <052.96ba61f09e40ccdfa2181da25e7d4d5b@haskell.org> #10911: Allow left ? (+++) as minimal definition of ArrowChoice instance -------------------------------------+------------------------------------- Reporter: | Owner: mfdyck.google | Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Core | Version: 7.10.2 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Add default definitions of left, right in terms of (+++) to let one define an ArrowChoice instance in terms of (+++) rather than left, which is sometimes more elegant or convenient. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 17:39:51 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 17:39:51 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMDkxMTogQWxsb3cgbGVmdCDiiKggKCsrKykg?= =?utf-8?q?as_minimal_definition_of_ArrowChoice_instance?= In-Reply-To: <052.96ba61f09e40ccdfa2181da25e7d4d5b@haskell.org> References: <052.96ba61f09e40ccdfa2181da25e7d4d5b@haskell.org> Message-ID: <067.a105109c51bc557cd695009beaae8427@haskell.org> #10911: Allow left ? (+++) as minimal definition of ArrowChoice instance -------------------------------------+------------------------------------- Reporter: mfdyck.google | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by mfdyck.google): Patch written; awaiting its release -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 17:42:15 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 17:42:15 -0000 Subject: [GHC] #10897: Incorrect ASSERT for buildPatSyn In-Reply-To: <045.72f9540a916b61c61568cdbdec70fba4@haskell.org> References: <045.72f9540a916b61c61568cdbdec70fba4@haskell.org> Message-ID: <060.89d3dae1385bab5fae3615831b61dcc7@haskell.org> #10897: Incorrect ASSERT for buildPatSyn -------------------------------------+------------------------------------- Reporter: ezyang | Owner: cactus Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by cactus): Hmm, it's starting to come back -- all those `ifPat*` type fields of `IfacePatSyn` are needed so that we can implement `pprIfaceDecl` and `freeNamesIfDecl` without the ability to turn the `IfExtName` of `ifPatMatcher` into a proper `Id`. That suggests we should look into it a bit more to see if it's valid when these self-confessed redundant fields aren't actually the same as the types recovered from the `Id` of the matcher. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 17:49:44 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 17:49:44 -0000 Subject: [GHC] #10238: Update libffi shortly before first GHC 7.12.1 RC In-Reply-To: <042.27be62378f24cc29ae2d842288972a74@haskell.org> References: <042.27be62378f24cc29ae2d842288972a74@haskell.org> Message-ID: <057.3300353afce2dbab2c3b148ffda7a59c@haskell.org> #10238: Update libffi shortly before first GHC 7.12.1 RC -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: highest | Milestone: 8.0.1 Component: Runtime System | Version: Resolution: | Keywords: libffi Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by crb002): Anyway you could piggyback static libffi support on this? Not all environments have shared libraries. https://github.com/commercialhaskell/stack/issues/1032 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 18:12:50 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 18:12:50 -0000 Subject: [GHC] #8832: Constant-folding regression wrt `clearBit (bit 0) 0 ` In-Reply-To: <042.89bb0eec284b44a45a7b0586c22bb7a4@haskell.org> References: <042.89bb0eec284b44a45a7b0586c22bb7a4@haskell.org> Message-ID: <057.f017eef6ad0def4b4c25a7ffc44c48da@haskell.org> #8832: Constant-folding regression wrt `clearBit (bit 0) 0 ` -------------------------------------+------------------------------------- Reporter: hvr | Owner: bgamari Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Core Libraries | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | simplCore/should_compile/T8832 Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1255 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"cf90a1e14efb900f94a3824b242be1c38b16a563/ghc" cf90a1e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="cf90a1e14efb900f94a3824b242be1c38b16a563" Add constant-folding rule for Data.Bits.bit This adds a constant-folding rule for `Integer`'s implementation of `bit` and fixes the `T8832` testcase. Fixes #8832. Reviewed By: simonpj, austin Differential Revision: https://phabricator.haskell.org/D1255 GHC Trac Issues: #8832 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 18:12:50 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 18:12:50 -0000 Subject: [GHC] #1830: Automatic derivation of Lift In-Reply-To: <044.3eb409743bc4021eb94e63cb46f573bc@haskell.org> References: <044.3eb409743bc4021eb94e63cb46f573bc@haskell.org> Message-ID: <059.ab413415f6c689cfa3244517ce59c3d5@haskell.org> #1830: Automatic derivation of Lift -------------------------------------+------------------------------------- Reporter: guest | Owner: | RyanGlScott Type: feature request | Status: new Priority: normal | Milestone: ? Component: Template Haskell | Version: 6.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1168 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"73921df27cac0615d2272b8729381aa0f229a0c8/ghc" 73921df/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="73921df27cac0615d2272b8729381aa0f229a0c8" Update Cabal to recognize DeriveLift This should (1) fix the ./validate build, which I accidentally broke in D1168, and (2) update the Cabal submodule so that it recognizes `DeriveLift` as a GHC extension. Reviewed By: adamse, austin Differential Revision: https://phabricator.haskell.org/D1269 GHC Trac Issues: #1830 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 18:13:24 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 18:13:24 -0000 Subject: [GHC] #10912: Support for out of the box static linking Message-ID: <045.dd87a2c5256e85911413677e3011cd99@haskell.org> #10912: Support for out of the box static linking -------------------------------------+------------------------------------- Reporter: crb002 | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Package | Version: 7.10.2 system | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- When running in environments like AWS Lambda you don't have access to basic shared libraries Haskell needs like libgmp, libffi. Need good support for static linked libraries of anything included in a basic GHC distribution. https://github.com/commercialhaskell/stack/issues/1032 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 18:19:18 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 18:19:18 -0000 Subject: [GHC] #10891: `reify` doesn't find associated type families In-Reply-To: <046.9e704f075dee9514291b5d5766834bf9@haskell.org> References: <046.9e704f075dee9514291b5d5766834bf9@haskell.org> Message-ID: <061.7c38551c3b6d5499647ff457dfb410a1@haskell.org> #10891: `reify` doesn't find associated type families -------------------------------------+------------------------------------- Reporter: antalsz | Owner: osa1 Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: type | families; newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1254 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"5c115236fe795aa01f0c10106f1b1c959486a739/ghc" 5c115236/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5c115236fe795aa01f0c10106f1b1c959486a739" reify associated types when reifying typeclasses As reported in Trac #10891, Template Haskell's `reify` was not generating Decls for associated types. This patch fixes that. Note that even though `reifyTyCon` function used in this patch returns some type instances, I'm ignoring that. Here's an example of how associated types are encoded with this patch: (Simplified representation) class C a where type F a :: * --> OpenTypeFamilyD "F" ["a"] With default type instances: class C a where type F a :: * type F a = a --> OpenTypeFamilyD "F" ["a"] TySynInstD "F" (TySynEqn [VarT "a"] "a") Reviewed By: goldfire Differential Revision: https://phabricator.haskell.org/D1254 GHC Trac Issues: #10891 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 18:48:36 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 18:48:36 -0000 Subject: [GHC] #10912: Support for out of the box static linking In-Reply-To: <045.dd87a2c5256e85911413677e3011cd99@haskell.org> References: <045.dd87a2c5256e85911413677e3011cd99@haskell.org> Message-ID: <060.741f65a9f03ba41a6231be1f3ede8138@haskell.org> #10912: Support for out of the box static linking -------------------------------------+------------------------------------- Reporter: crb002 | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): Do you want GHC itself to be statically linked against C libraries, or the programs that GHC produces? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 20:14:05 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 20:14:05 -0000 Subject: [GHC] #10752: Print which warning-flag controls/enabled an emitted warning In-Reply-To: <042.f644641d9b90b7c893a460f85d1840e2@haskell.org> References: <042.f644641d9b90b7c893a460f85d1840e2@haskell.org> Message-ID: <057.43e25767f00cdf9e8a4843ead32c3fc8@haskell.org> #10752: Print which warning-flag controls/enabled an emitted warning -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by osa1): * cc: osa1 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 20:47:46 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 20:47:46 -0000 Subject: [GHC] #10752: Print which warning-flag controls/enabled an emitted warning In-Reply-To: <042.f644641d9b90b7c893a460f85d1840e2@haskell.org> References: <042.f644641d9b90b7c893a460f85d1840e2@haskell.org> Message-ID: <057.724e763658284ff806039497b36ce878@haskell.org> #10752: Print which warning-flag controls/enabled an emitted warning -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by osa1): This is a great idea and it should be just a straightforward refactoring: - Modify `ErrUtils.makeIntoWarning` to get a `Maybe WarningFlag` as argument. - Modify `ErrUtils.ErrMsg` to record a `WarningFlag`. - Since we want to show flags uniformly in messages, maybe modify `LogAction` to pass this `Maybe WarningFlag`. Then modify `DynFlags.defaultLogAction` to print these flags. - Fix all the compile errors by passing warning flags to `makeIntoWarning`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 20:54:06 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 20:54:06 -0000 Subject: [GHC] #10912: Support for out of the box static linking In-Reply-To: <045.dd87a2c5256e85911413677e3011cd99@haskell.org> References: <045.dd87a2c5256e85911413677e3011cd99@haskell.org> Message-ID: <060.3f87a094a7a57f9ec485deb41b538f74@haskell.org> #10912: Support for out of the box static linking -------------------------------------+------------------------------------- Reporter: crb002 | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by crb002): Emit static linked binaries, but yes if we wanted to run GHC on AWS Lambda we would need to static link GHC itself. I did this with Ruby1.8 for the BlueGene/L. Biggest pain was link order. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 20:58:14 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 20:58:14 -0000 Subject: [GHC] #10913: deprecate and then remove -fwarn-hi-shadowing Message-ID: <043.5271c7f4effd317ccfe2016268f0bde8@haskell.org> #10913: deprecate and then remove -fwarn-hi-shadowing -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.10.2 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- I realized that the flag is not used in the compiler at all, and @slyfox realized that the flag was last used in 2006. He also found out that there are 355 packages in the Hackage that use this useless flag. So we should maybe first deprecate it and remove it later. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 22:25:42 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 22:25:42 -0000 Subject: [GHC] #10877: x86_64: dll-split: out of memory (requested 1099512676352 bytes) In-Reply-To: <050.ab3ee9d3ff60499476bc10d829ff13d9@haskell.org> References: <050.ab3ee9d3ff60499476bc10d829ff13d9@haskell.org> Message-ID: <065.89cfbfb94dbe2e9a676dd76e916ee91d@haskell.org> #10877: x86_64: dll-split: out of memory (requested 1099512676352 bytes) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: #10682 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): Presumably it will sit in cache in this case, no? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 22:26:47 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 22:26:47 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMDkxMTogQWxsb3cgbGVmdCDiiKggKCsrKykg?= =?utf-8?q?as_minimal_definition_of_ArrowChoice_instance?= In-Reply-To: <052.96ba61f09e40ccdfa2181da25e7d4d5b@haskell.org> References: <052.96ba61f09e40ccdfa2181da25e7d4d5b@haskell.org> Message-ID: <067.ddcc592ad0b7a52cccc00c5559b88aae@haskell.org> #10911: Allow left ? (+++) as minimal definition of ArrowChoice instance -------------------------------------+------------------------------------- Reporter: mfdyck.google | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by mfdyck.google): * Attachment "0001-unbreak-Text.Read.Lex.lex.patch" added. Behave as GHC lexer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 22:28:02 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 22:28:02 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMDkxMTogQWxsb3cgbGVmdCDiiKggKCsrKykg?= =?utf-8?q?as_minimal_definition_of_ArrowChoice_instance?= In-Reply-To: <052.96ba61f09e40ccdfa2181da25e7d4d5b@haskell.org> References: <052.96ba61f09e40ccdfa2181da25e7d4d5b@haskell.org> Message-ID: <067.77a8a08abdfb22ac8e90fb44b7b7a2c2@haskell.org> #10911: Allow left ? (+++) as minimal definition of ArrowChoice instance -------------------------------------+------------------------------------- Reporter: mfdyck.google | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by mfdyck.google): Whoops, sorry, wrong patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 22:28:37 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 22:28:37 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMDkxMTogQWxsb3cgbGVmdCDiiKggKCsrKykg?= =?utf-8?q?as_minimal_definition_of_ArrowChoice_instance?= In-Reply-To: <052.96ba61f09e40ccdfa2181da25e7d4d5b@haskell.org> References: <052.96ba61f09e40ccdfa2181da25e7d4d5b@haskell.org> Message-ID: <067.7689de929c5c1dce71bcc553ead838cb@haskell.org> #10911: Allow left ? (+++) as minimal definition of ArrowChoice instance -------------------------------------+------------------------------------- Reporter: mfdyck.google | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by mfdyck.google): * Attachment "0001-Allow-left-as-minimal-definition-of-ArrowChoice- inst.patch" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 22:29:25 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 22:29:25 -0000 Subject: [GHC] #10444: Text.Read.Lex.lex broken In-Reply-To: <048.7d303af6bd6af366785c1d3e315fce90@haskell.org> References: <048.7d303af6bd6af366785c1d3e315fce90@haskell.org> Message-ID: <063.a311ccf302aefcdc206635417e5e2c78@haskell.org> #10444: Text.Read.Lex.lex broken -------------------------------------+------------------------------------- Reporter: strake888 | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: | Phab:D1122. -------------------------------------+------------------------------------- Changes (by mfdyck.google): * Attachment "0001-unbreak-Text.Read.Lex.lex.3.patch" added. Behave as GHC lexer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 22:30:27 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 22:30:27 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMDkxMTogQWxsb3cgbGVmdCDiiKggKCsrKykg?= =?utf-8?q?as_minimal_definition_of_ArrowChoice_instance?= In-Reply-To: <052.96ba61f09e40ccdfa2181da25e7d4d5b@haskell.org> References: <052.96ba61f09e40ccdfa2181da25e7d4d5b@haskell.org> Message-ID: <067.0ea888dcfb303d2a83bd7af3ca9a5d64@haskell.org> #10911: Allow left ? (+++) as minimal definition of ArrowChoice instance -------------------------------------+------------------------------------- Reporter: mfdyck.google | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by mfdyck.google): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 22:51:44 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 22:51:44 -0000 Subject: [GHC] #10826: [Security] Safe Haskell can be bypassed via annotations In-Reply-To: <045.6042fe6f9f535df81b6d3e710bdd3ea9@haskell.org> References: <045.6042fe6f9f535df81b6d3e710bdd3ea9@haskell.org> Message-ID: <060.70ffe7a57228b3ee136502541d685592@haskell.org> #10826: [Security] Safe Haskell can be bypassed via annotations -------------------------------------+------------------------------------- Reporter: spinda | Owner: kanetw Type: bug | Status: closed Priority: highest | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: phab:D1226 -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Committed to `ghc-7.10` as d73a8ec -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 22:52:39 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 22:52:39 -0000 Subject: [GHC] #10438: GHC 7.10.1 panic due to PartialTypeSignatures, TypeFamilies, and local bindings In-Reply-To: <049.41b7d0833f2869d11544c1b4baf6f0c5@haskell.org> References: <049.41b7d0833f2869d11544c1b4baf6f0c5@haskell.org> Message-ID: <064.579449cc9264285e5ab0680dc07c9c97@haskell.org> #10438: GHC 7.10.1 panic due to PartialTypeSignatures, TypeFamilies, and local bindings -------------------------------------+------------------------------------- Reporter: rpglover64 | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Compile-time | Test Case: partial- crash | sigs/should_compile/T10438 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-7.10` as 0e1c983 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 22:58:17 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 22:58:17 -0000 Subject: [GHC] #10528: compile time performance regression with OverloadedStrings and Text In-Reply-To: <048.98ab82d16d4bd14b388cfa4fc2b927d4@haskell.org> References: <048.98ab82d16d4bd14b388cfa4fc2b927d4@haskell.org> Message-ID: <063.40354d5c937f223d80756ca34bd66422@haskell.org> #10528: compile time performance regression with OverloadedStrings and Text -------------------------------------+------------------------------------- Reporter: jakewheat | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2-rc2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: "Do not inline or apply rules on LHS of rules" has been merged to `ghc-7.10` as 30d1b53. This closes this issue. Rewriting of rule RHSs is being tracked in #10829. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 23:01:31 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 23:01:31 -0000 Subject: [GHC] #6037: Compile-time crash with sources with non-representable unicode characters In-Reply-To: <043.7207ef363a1d98123424aaa571c817fa@haskell.org> References: <043.7207ef363a1d98123424aaa571c817fa@haskell.org> Message-ID: <058.617e728f9a2c5cd670c35785c22476a6@haskell.org> #6037: Compile-time crash with sources with non-representable unicode characters -------------------------------------+------------------------------------- Reporter: akio | Owner: snoyberg Type: bug | Status: closed Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.4.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: T6037 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: This was merged to `ghc-7.10` as bbd6730f64a47d6fd4c831b78a3bbcd7a929ce4a. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 23:02:16 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 23:02:16 -0000 Subject: [GHC] #6037: Compile-time crash with sources with non-representable unicode characters In-Reply-To: <043.7207ef363a1d98123424aaa571c817fa@haskell.org> References: <043.7207ef363a1d98123424aaa571c817fa@haskell.org> Message-ID: <058.17fdccbd7527754175ceb719fcf455c6@haskell.org> #6037: Compile-time crash with sources with non-representable unicode characters -------------------------------------+------------------------------------- Reporter: akio | Owner: snoyberg Type: bug | Status: closed Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.4.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: T6037 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): The testsuite update was merged to `ghc-7.10` as a399888. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 23:02:38 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 23:02:38 -0000 Subject: [GHC] #9861: ghc readme provides out of date git clone directions In-Reply-To: <045.ee10b522121d648c9ddb8fa0d461111b@haskell.org> References: <045.ee10b522121d648c9ddb8fa0d461111b@haskell.org> Message-ID: <060.65c29727836bfcf0e8e5ace18e93e9f8@haskell.org> #9861: ghc readme provides out of date git clone directions -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: phab:D555 -------------------------------------+------------------------------------- Comment (by bgamari): This was merged to `ghc-7.10` as 4f8b873. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 23:02:45 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 23:02:45 -0000 Subject: [GHC] #9861: ghc readme provides out of date git clone directions In-Reply-To: <045.ee10b522121d648c9ddb8fa0d461111b@haskell.org> References: <045.ee10b522121d648c9ddb8fa0d461111b@haskell.org> Message-ID: <060.fc5225bf23a465b1b7d4af00eaccd485@haskell.org> #9861: ghc readme provides out of date git clone directions -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: phab:D555 -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 23:06:50 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 23:06:50 -0000 Subject: [GHC] #9970: Export more types in GHC.RTS.Flags In-Reply-To: <050.a5b7a1426f78715d4c9bb9384727144d@haskell.org> References: <050.a5b7a1426f78715d4c9bb9384727144d@haskell.org> Message-ID: <065.b0286c809ace381441b85ebb25969055@haskell.org> #9970: Export more types in GHC.RTS.Flags -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: | RyanGlScott Type: feature request | Status: closed Priority: normal | Milestone: 7.10.3 Component: libraries/base | Version: 7.10.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1030 -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed Comment: Merged to `ghc-7.10` as e435b0a. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 23:07:02 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 23:07:02 -0000 Subject: [GHC] #10689: compiling singletons-1.1.2.1 as -O1 -fspec-constr fails as 'Template variable unbound in rewrite rule' In-Reply-To: <045.743fe21fa784fce71ea539681c963bac@haskell.org> References: <045.743fe21fa784fce71ea539681c963bac@haskell.org> Message-ID: <060.cc8feaab221bc201e23ad6d729302b0c@haskell.org> #10689: compiling singletons-1.1.2.1 as -O1 -fspec-constr fails as 'Template variable unbound in rewrite rule' -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: merge Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | simplCore/should_compile/T10689, | T10689a Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): This has been merged to `ghc-7.10` as c289c689d697b69145dbd3e9e773fc5e780414ad. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 23:08:20 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 23:08:20 -0000 Subject: [GHC] #10493: Inaccessible code might be accessible with newtypes and Coercible In-Reply-To: <047.2c11d0767c97fbdfa43aeb457c1a28e7@haskell.org> References: <047.2c11d0767c97fbdfa43aeb457c1a28e7@haskell.org> Message-ID: <062.55df292bf71807fab4a77af17df52083@haskell.org> #10493: Inaccessible code might be accessible with newtypes and Coercible -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T10493 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: This has been merged to `ghc-7.10` as 5df26ae. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 23:16:15 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 23:16:15 -0000 Subject: [GHC] #10495: Poor error message for Coercible constraint unsatisfiability In-Reply-To: <047.88be9b06528fbf6e5c30196ecacf3fe5@haskell.org> References: <047.88be9b06528fbf6e5c30196ecacf3fe5@haskell.org> Message-ID: <062.37298b3f15a064711e6a36c6e868b217@haskell.org> #10495: Poor error message for Coercible constraint unsatisfiability -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T10495 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: This was merged to `ghc-7.10` as d02954efebbff51a7292bf60ea83db4d35dc3476. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 23:19:16 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 23:19:16 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2310520=3A_RecordWildCards_causes_?= =?utf-8?q?=E2=80=9Cis_not_a_=28visible=29_field_of_constructor?= =?utf-8?b?4oCdIGluIGdoY2k=?= In-Reply-To: <043.c857f67e883ef833a204da9e13d91bc2@haskell.org> References: <043.c857f67e883ef833a204da9e13d91bc2@haskell.org> Message-ID: <058.839adff6696a1319fe9b1b01c5e7f3fb@haskell.org> #10520: RecordWildCards causes ?is not a (visible) field of constructor? in ghci -------------------------------------+------------------------------------- Reporter: ion1 | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.3 Component: GHCi | Version: 7.10.1 Resolution: fixed | Keywords: | RecordWildCards Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: This was merged to `ghc-7.10` as f71f770. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 23:20:58 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 23:20:58 -0000 Subject: [GHC] #10668: Missing brackets in import hint with TypeOperators In-Reply-To: <047.60a52fd2422f834202b3d782885a3356@haskell.org> References: <047.60a52fd2422f834202b3d782885a3356@haskell.org> Message-ID: <062.262dc4a4cc6f121bdc9a7222084c1656@haskell.org> #10668: Missing brackets in import hint with TypeOperators -------------------------------------+------------------------------------- Reporter: bjmprice | Owner: thomasw Type: bug | Status: closed Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: T10668 Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1093 -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-7.10` as 9cab391. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 23:35:44 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 23:35:44 -0000 Subject: [GHC] #10665: INLINE breaks rewrite rules when '-g' is used In-Reply-To: <045.95657d2fca941df9621daef19a7fe710@haskell.org> References: <045.95657d2fca941df9621daef19a7fe710@haskell.org> Message-ID: <060.207f89cd5e9b56f8bb24887727d08c0c@haskell.org> #10665: INLINE breaks rewrite rules when '-g' is used -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2-rc2 (CodeGen) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: This was merged to `ghc-7.10` as mentioned in #10528. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 23:38:09 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 23:38:09 -0000 Subject: [GHC] #10772: Type operator variable in prefix notation fails In-Reply-To: <046.ab9a1e8aa534bcd6d1b2f12748c0ce5a@haskell.org> References: <046.ab9a1e8aa534bcd6d1b2f12748c0ce5a@haskell.org> Message-ID: <061.ba994ca9cc7a0ddff0f142157f583963@haskell.org> #10772: Type operator variable in prefix notation fails -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.3 Component: Documentation | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 23:42:32 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 23:42:32 -0000 Subject: [GHC] #10713: Type family not reducing over data family In-Reply-To: <046.5ef44ab91bf829939e28ffc1eb7fff9f@haskell.org> References: <046.5ef44ab91bf829939e28ffc1eb7fff9f@haskell.org> Message-ID: <061.7900776c1db1b48ad416e4c2055cab01@haskell.org> #10713: Type family not reducing over data family -------------------------------------+------------------------------------- Reporter: acowley | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 7.10.3 Component: Compiler (Type | Version: 7.8.4 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_compile/T10713 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 23:46:32 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 23:46:32 -0000 Subject: [GHC] #10715: Possible regression in Coercible a (X a) between 7.8 and 7.10 In-Reply-To: <044.cc1e9df1bbafaf4fb6388749f2b76941@haskell.org> References: <044.cc1e9df1bbafaf4fb6388749f2b76941@haskell.org> Message-ID: <059.911e3fbb564efe9fa2f48fd95c04edb6@haskell.org> #10715: Possible regression in Coercible a (X a) between 7.8 and 7.10 -------------------------------------+------------------------------------- Reporter: inaki | Owner: goldfire Type: bug | Status: merge Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_fail/T10715{,b} Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1263 -------------------------------------+------------------------------------- Comment (by bgamari): Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 23:47:10 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 23:47:10 -0000 Subject: [GHC] #10879: base is not included in the haddock index In-Reply-To: <048.8713266ddcd63f131d79fa94bba781e8@haskell.org> References: <048.8713266ddcd63f131d79fa94bba781e8@haskell.org> Message-ID: <063.cae231e349d01ba88d2a2ab10209ee12@haskell.org> #10879: base is not included in the haddock index -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.3 Component: Build System | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1247 -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 23:47:20 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 23:47:20 -0000 Subject: [GHC] #10715: Possible regression in Coercible a (X a) between 7.8 and 7.10 In-Reply-To: <044.cc1e9df1bbafaf4fb6388749f2b76941@haskell.org> References: <044.cc1e9df1bbafaf4fb6388749f2b76941@haskell.org> Message-ID: <059.1483e98b7eb348c4da43908044111886@haskell.org> #10715: Possible regression in Coercible a (X a) between 7.8 and 7.10 -------------------------------------+------------------------------------- Reporter: inaki | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_fail/T10715{,b} Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1263 -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 23:47:59 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 23:47:59 -0000 Subject: [GHC] #10413: Incorrect offsets for array size indexing In-Reply-To: <048.fb282c815f959019fb8541a09f28e9ea@haskell.org> References: <048.fb282c815f959019fb8541a09f28e9ea@haskell.org> Message-ID: <063.35f71f333f1a2657c569d45cdcb10a95@haskell.org> #10413: Incorrect offsets for array size indexing -------------------------------------+------------------------------------- Reporter: fryguybob | Owner: fryguybob Type: task | Status: closed Priority: low | Milestone: 7.10.3 Component: Compiler | Version: 7.10.1 (CodeGen) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1194 -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 23:49:17 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 23:49:17 -0000 Subject: [GHC] #10476: Wrong ar during cross-compilation In-Reply-To: <046.928a748c0b21fd917210dee4be8c618c@haskell.org> References: <046.928a748c0b21fd917210dee4be8c618c@haskell.org> Message-ID: <061.52403ceca4d4b9657f010e3151ce8ff6@haskell.org> #10476: Wrong ar during cross-compilation -------------------------------------+------------------------------------- Reporter: jakzale | Owner: thomie Type: bug | Status: closed Priority: low | Milestone: 7.10.3 Component: Build System | Version: 7.11 Resolution: fixed | Keywords: cross- | compiling Operating System: MacOS X | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: Phab:D1231 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-7.10`. Someone speak up before release if we suspect that Xcode 4.3 is still something we need to worry about. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 23:50:32 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 23:50:32 -0000 Subject: [GHC] #10689: compiling singletons-1.1.2.1 as -O1 -fspec-constr fails as 'Template variable unbound in rewrite rule' In-Reply-To: <045.743fe21fa784fce71ea539681c963bac@haskell.org> References: <045.743fe21fa784fce71ea539681c963bac@haskell.org> Message-ID: <060.c8bd2dafb98b7b14cb187dc84a0d626e@haskell.org> #10689: compiling singletons-1.1.2.1 as -O1 -fspec-constr fails as 'Template variable unbound in rewrite rule' -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | simplCore/should_compile/T10689, | T10689a Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 23:51:42 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 23:51:42 -0000 Subject: [GHC] #10660: .dyn_o isn't generated for .hsig files with -dynamic-too In-Reply-To: <045.56b69c19eb1cb2d0ece6f18980e16b58@haskell.org> References: <045.56b69c19eb1cb2d0ece6f18980e16b58@haskell.org> Message-ID: <060.4327284c78268dcf0b2bd3973c73b610@haskell.org> #10660: .dyn_o isn't generated for .hsig files with -dynamic-too -------------------------------------+------------------------------------- Reporter: spinda | Owner: spinda Type: bug | Status: closed Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1084 -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 23:52:49 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 23:52:49 -0000 Subject: [GHC] #10590: RTS failing with removeThreadFromDeQueue: not found message In-Reply-To: <045.1d70a7521e31b555660aa59499823ca1@haskell.org> References: <045.1d70a7521e31b555660aa59499823ca1@haskell.org> Message-ID: <060.8b207ddf7b89ff9062aa213c6552e74c@haskell.org> #10590: RTS failing with removeThreadFromDeQueue: not found message -------------------------------------+------------------------------------- Reporter: qnikst | Owner: slyfox Type: bug | Status: closed Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1024 -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed Comment: This has been merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 23:54:10 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 23:54:10 -0000 Subject: [GHC] #10815: Need more kind inference in associated type instances In-Reply-To: <047.d8bc1a4461bf2f49e829557a2b73313c@haskell.org> References: <047.d8bc1a4461bf2f49e829557a2b73313c@haskell.org> Message-ID: <062.741f3a12fa6a9fe529b9aafc2261266a@haskell.org> #10815: Need more kind inference in associated type instances -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.3 Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_compile/T10815 Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1195 -------------------------------------+------------------------------------- Changes (by bgamari): * owner: goldfire => * status: merge => new Comment: It doesn't look like this will be terribly convenient. Punting. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 23:54:17 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 23:54:17 -0000 Subject: [GHC] #10815: Need more kind inference in associated type instances In-Reply-To: <047.d8bc1a4461bf2f49e829557a2b73313c@haskell.org> References: <047.d8bc1a4461bf2f49e829557a2b73313c@haskell.org> Message-ID: <062.61849d3bb85a3442c6b7222180d54ca3@haskell.org> #10815: Need more kind inference in associated type instances -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.3 Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_compile/T10815 Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1195 -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 23:55:47 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 23:55:47 -0000 Subject: [GHC] #10596: Template Haskell : getQ and putQ doesn't work In-Reply-To: <046.c146d1bd7b74286ed3cadc42554eb201@haskell.org> References: <046.c146d1bd7b74286ed3cadc42554eb201@haskell.org> Message-ID: <061.c3cde0972ad0f744cbeeab5d35780d86@haskell.org> #10596: Template Haskell : getQ and putQ doesn't work -------------------------------------+------------------------------------- Reporter: kiripon | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.3 Component: Template Haskell | Version: 7.10.1 Resolution: fixed | Keywords: getQ putQ Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: th/T10596 Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1026 -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 23 23:56:13 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Sep 2015 23:56:13 -0000 Subject: [GHC] #10855: GHC rejects code that Haskell 2010 report accepts In-Reply-To: <047.18e6e77fdcbdaa2d5abe96a152166a71@haskell.org> References: <047.18e6e77fdcbdaa2d5abe96a152166a71@haskell.org> Message-ID: <062.b0dfe75ff8a29a2bed3778ef9b395845@haskell.org> #10855: GHC rejects code that Haskell 2010 report accepts -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 (Parser) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 24 00:49:46 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Sep 2015 00:49:46 -0000 Subject: [GHC] #10829: Simplification in the RHS of rules In-Reply-To: <046.7ca7c028ab82ec2d7ad263cb88680067@haskell.org> References: <046.7ca7c028ab82ec2d7ad263cb88680067@haskell.org> Message-ID: <061.82e2da217a2a23b30183539741281e56@haskell.org> #10829: Simplification in the RHS of rules -------------------------------------+------------------------------------- Reporter: afarmer | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10528 | Differential Revisions: Phab:D1246 -------------------------------------+------------------------------------- Changes (by Roboguy): * cc: Roboguy (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 24 01:00:48 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Sep 2015 01:00:48 -0000 Subject: [GHC] #10752: Print which warning-flag controls/enabled an emitted warning In-Reply-To: <042.f644641d9b90b7c893a460f85d1840e2@haskell.org> References: <042.f644641d9b90b7c893a460f85d1840e2@haskell.org> Message-ID: <057.37371e2bb77ed98a683b0376f7f4f700@haskell.org> #10752: Print which warning-flag controls/enabled an emitted warning -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): +1 from me. I look these up with some frequency. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 24 07:42:14 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Sep 2015 07:42:14 -0000 Subject: [GHC] #10904: C finalizer may be called on re-used memory In-Reply-To: <046.82d7a624ac5d38e3fd81c14129ab8c8d@haskell.org> References: <046.82d7a624ac5d38e3fd81c14129ab8c8d@haskell.org> Message-ID: <061.fb1bdd26372603b841b518ee25e17ca3@haskell.org> #10904: C finalizer may be called on re-used memory -------------------------------------+------------------------------------- Reporter: bherzog | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 7.4.1 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1275 -------------------------------------+------------------------------------- Comment (by Simon Marlow ): In [changeset:"2440e3c6b479ac532e2660374a78c8482e903bed/ghc" 2440e3c6/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2440e3c6b479ac532e2660374a78c8482e903bed" Fix a bug with mallocForeignPtr and finalizers (#10904) Summary: See Note [MallocPtr finalizers] Test Plan: validate; new test T10904 Reviewers: ezyang, bgamari, austin, hvr, rwbarton Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1275 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 24 07:43:34 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Sep 2015 07:43:34 -0000 Subject: [GHC] #10904: C finalizer may be called on re-used memory In-Reply-To: <046.82d7a624ac5d38e3fd81c14129ab8c8d@haskell.org> References: <046.82d7a624ac5d38e3fd81c14129ab8c8d@haskell.org> Message-ID: <061.027973611006f9d634f52723fd9a19ae@haskell.org> #10904: C finalizer may be called on re-used memory -------------------------------------+------------------------------------- Reporter: bherzog | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Runtime System | Version: 7.4.1 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1275 -------------------------------------+------------------------------------- Changes (by simonmar): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 24 07:43:51 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Sep 2015 07:43:51 -0000 Subject: [GHC] #10904: C finalizer may be called on re-used memory In-Reply-To: <046.82d7a624ac5d38e3fd81c14129ab8c8d@haskell.org> References: <046.82d7a624ac5d38e3fd81c14129ab8c8d@haskell.org> Message-ID: <061.ae52b29e7ad45b396b485bd0b2af2cb2@haskell.org> #10904: C finalizer may be called on re-used memory -------------------------------------+------------------------------------- Reporter: bherzog | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.3 Component: Runtime System | Version: 7.4.1 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1275 -------------------------------------+------------------------------------- Changes (by simonmar): * milestone: => 7.10.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 24 07:50:29 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Sep 2015 07:50:29 -0000 Subject: [GHC] #10487: DeriveGeneric breaks when the same data name is used in different modules In-Reply-To: <051.f823b016355f38c348182e98da9d4ae1@haskell.org> References: <051.f823b016355f38c348182e98da9d4ae1@haskell.org> Message-ID: <066.b3dc61da0e6e80fe4773857c6f7fe290@haskell.org> #10487: DeriveGeneric breaks when the same data name is used in different modules -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: osa1 Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1081 -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"b08a533dc87423a75bce037eb403d7828d3330d3/ghc" b08a533/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b08a533dc87423a75bce037eb403d7828d3330d3" Fix DeriveGeneric for types with same OccName (#10487) Summary: DeriveGeneric generates some data types (for data type constructors and for selectors of those constructors) and instances for those types. This patch changes name generation for these new types to make it working with data types with same names imported from different modules and with data types with same names imported from same modules(using module imports). Bonus content: - Some refactoring in `TcGenGenerics.metaTyConsToDerivStuff` to remove some redundant partial function applications and to remove a duplicated function. - Remove some unused names from `OccName`. (those were used for an old implementation of `DeriveGeneric`) Reviewers: kosmikus, simonpj, dreixel, ezyang, bgamari, austin Reviewed By: bgamari, austin Subscribers: ezyang, thomie Differential Revision: https://phabricator.haskell.org/D1081 GHC Trac Issues: #10487 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 24 07:51:05 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Sep 2015 07:51:05 -0000 Subject: [GHC] #10487: DeriveGeneric breaks when the same data name is used in different modules In-Reply-To: <051.f823b016355f38c348182e98da9d4ae1@haskell.org> References: <051.f823b016355f38c348182e98da9d4ae1@haskell.org> Message-ID: <066.aff5943af5188901ea5a65928e89ef02@haskell.org> #10487: DeriveGeneric breaks when the same data name is used in different modules -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: osa1 Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1081 -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => fixed Comment: Pushed. I assume we aren't backporting to 7.10? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 24 09:00:03 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Sep 2015 09:00:03 -0000 Subject: [GHC] #10904: C finalizer may be called on re-used memory In-Reply-To: <046.82d7a624ac5d38e3fd81c14129ab8c8d@haskell.org> References: <046.82d7a624ac5d38e3fd81c14129ab8c8d@haskell.org> Message-ID: <061.082d430f31a25bc5da2b42e3489e900d@haskell.org> #10904: C finalizer may be called on re-used memory -------------------------------------+------------------------------------- Reporter: bherzog | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.3 Component: Runtime System | Version: 7.4.1 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1275 -------------------------------------+------------------------------------- Comment (by bgamari): Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 24 09:00:11 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Sep 2015 09:00:11 -0000 Subject: [GHC] #10904: C finalizer may be called on re-used memory In-Reply-To: <046.82d7a624ac5d38e3fd81c14129ab8c8d@haskell.org> References: <046.82d7a624ac5d38e3fd81c14129ab8c8d@haskell.org> Message-ID: <061.092d9ef95af1d0eef55cdad3f3059208@haskell.org> #10904: C finalizer may be called on re-used memory -------------------------------------+------------------------------------- Reporter: bherzog | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.3 Component: Runtime System | Version: 7.4.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1275 -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 24 10:03:56 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Sep 2015 10:03:56 -0000 Subject: [GHC] #8832: Constant-folding regression wrt `clearBit (bit 0) 0 ` In-Reply-To: <042.89bb0eec284b44a45a7b0586c22bb7a4@haskell.org> References: <042.89bb0eec284b44a45a7b0586c22bb7a4@haskell.org> Message-ID: <057.e3b0a0fd20229a35547bcea39f6a16d7@haskell.org> #8832: Constant-folding regression wrt `clearBit (bit 0) 0 ` -------------------------------------+------------------------------------- Reporter: hvr | Owner: bgamari Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Core Libraries | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | simplCore/should_compile/T8832 Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1255 -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"4f9ee91303be9c122af6e91e5e599f589e3f196f/ghc" 4f9ee91/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4f9ee91303be9c122af6e91e5e599f589e3f196f" Testsuite: update expected output for T8832 on 32-bit systems (#8832) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 24 10:04:22 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Sep 2015 10:04:22 -0000 Subject: [GHC] #8832: Constant-folding regression wrt `clearBit (bit 0) 0 ` In-Reply-To: <042.89bb0eec284b44a45a7b0586c22bb7a4@haskell.org> References: <042.89bb0eec284b44a45a7b0586c22bb7a4@haskell.org> Message-ID: <057.b3246b0a36a4b25ff425dda4b9ee6b98@haskell.org> #8832: Constant-folding regression wrt `clearBit (bit 0) 0 ` -------------------------------------+------------------------------------- Reporter: hvr | Owner: bgamari Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Core Libraries | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | simplCore/should_compile/T8832 Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1255 -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 24 10:08:49 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Sep 2015 10:08:49 -0000 Subject: [GHC] #8832: Constant-folding regression wrt `clearBit (bit 0) 0 ` In-Reply-To: <042.89bb0eec284b44a45a7b0586c22bb7a4@haskell.org> References: <042.89bb0eec284b44a45a7b0586c22bb7a4@haskell.org> Message-ID: <057.a5e1a16ca4a2df46b8ed4568745f5273@haskell.org> #8832: Constant-folding regression wrt `clearBit (bit 0) 0 ` -------------------------------------+------------------------------------- Reporter: hvr | Owner: bgamari Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Core Libraries | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | simplCore/should_compile/T8832 Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1255 -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"5883b5665860ed5f3199c59dc0d843a66408741b/ghc" 5883b56/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5883b5665860ed5f3199c59dc0d843a66408741b" Testsuite: properly fix T8832.stdout-ws-32 (#8832) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 24 10:14:08 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Sep 2015 10:14:08 -0000 Subject: [GHC] #10891: `reify` doesn't find associated type families In-Reply-To: <046.9e704f075dee9514291b5d5766834bf9@haskell.org> References: <046.9e704f075dee9514291b5d5766834bf9@haskell.org> Message-ID: <061.af90a2f41afa5e87ad07344e9ca08c9e@haskell.org> #10891: `reify` doesn't find associated type families -------------------------------------+------------------------------------- Reporter: antalsz | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: type | families; newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1254 -------------------------------------+------------------------------------- Changes (by thomie): * owner: osa1 => * status: merge => new Comment: This commit was reverted in 39a262e53bab3b7cf827fa9f22226da5fca055be. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 24 10:52:38 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Sep 2015 10:52:38 -0000 Subject: [GHC] #10771: Installation of Ivory - Static flags have not been initialised In-Reply-To: <045.799f67bd688340da6719146f693d4e1e@haskell.org> References: <045.799f67bd688340da6719146f693d4e1e@haskell.org> Message-ID: <060.75cca152723c6c531eb703ceeacec1d2@haskell.org> #10771: Installation of Ivory - Static flags have not been initialised -------------------------------------+------------------------------------- Reporter: stiege | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): Thank you for the report. * The [https://github.com/GaloisInc/ivory ivory README] says: "It is known to work with with GHC 7.6.2, 7.6.3, and the 7.8.x series." You are using 7.10.2, so that might not work yet. * ivory is using GHC as a libary (https://github.com/GaloisInc/ivory/blob/master/ivory/ivory.cabal contains `build-depends: ghc`). So this is most likely a problem with ivory itself, not with GHC. Please also open a ticket with ivory. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 24 11:36:54 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Sep 2015 11:36:54 -0000 Subject: [GHC] #10383: AArch64: get GHC Calling convention working In-Reply-To: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> References: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> Message-ID: <059.f13adb4a1bc074115aeafafc1405dade@haskell.org> #10383: AArch64: get GHC Calling convention working ----------------------------------------+---------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------------+---------------------------------- Comment (by edmund): A couple of questions: Does the build always fail at the same point? What happens if you restrict everything to a single CPU (taskset 0x02 command...)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 24 12:47:46 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Sep 2015 12:47:46 -0000 Subject: [GHC] #10894: In users_guide/profiling.xml : -prof flag not to be used with cabal/stack In-Reply-To: <051.b9d67c5f210cc06a555ca9241f326e69@haskell.org> References: <051.b9d67c5f210cc06a555ca9241f326e69@haskell.org> Message-ID: <066.1dcf4a293f0b8251473fa41c1ecf307b@haskell.org> #10894: In users_guide/profiling.xml : -prof flag not to be used with cabal/stack -------------------------------------+------------------------------------- Reporter: robstewartuk | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Documentation | Version: 7.10.2 Resolution: | Keywords: user | guide, profiling Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by robstewartuk): Indeed, these cabal and stack github tickets have been (stack) or are being (cabal) addressed, as a concern of their compile time flags. See the discussions in the respective links in [https://ghc.haskell.org/trac/ghc/ticket/10894#comment:2]. Closing this GHC ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 24 12:48:31 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Sep 2015 12:48:31 -0000 Subject: [GHC] #10894: In users_guide/profiling.xml : -prof flag not to be used with cabal/stack In-Reply-To: <051.b9d67c5f210cc06a555ca9241f326e69@haskell.org> References: <051.b9d67c5f210cc06a555ca9241f326e69@haskell.org> Message-ID: <066.4028d84a7f00ff5d486e6a15c7ca3a80@haskell.org> #10894: In users_guide/profiling.xml : -prof flag not to be used with cabal/stack -------------------------------------+------------------------------------- Reporter: robstewartuk | Owner: Type: bug | Status: closed Priority: lowest | Milestone: Component: Documentation | Version: 7.10.2 Resolution: wontfix | Keywords: user | guide, profiling Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by robstewartuk): * status: new => closed * resolution: => wontfix -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 24 12:56:51 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Sep 2015 12:56:51 -0000 Subject: [GHC] #10767: SPECIALIZE generates warning but works fine In-Reply-To: <043.4ebd25de1b3c74f2b23206d88f108b5f@haskell.org> References: <043.4ebd25de1b3c74f2b23206d88f108b5f@haskell.org> Message-ID: <058.e42047f2272753d4f63c59df781dff3d@haskell.org> #10767: SPECIALIZE generates warning but works fine -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"1395185f56cda4774d27ae419b10f570276b674d/ghc" 1395185f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1395185f56cda4774d27ae419b10f570276b674d" Testsuite: add test for #10767 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 24 12:58:06 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Sep 2015 12:58:06 -0000 Subject: [GHC] #10767: SPECIALIZE generates warning but works fine In-Reply-To: <043.4ebd25de1b3c74f2b23206d88f108b5f@haskell.org> References: <043.4ebd25de1b3c74f2b23206d88f108b5f@haskell.org> Message-ID: <058.8c4865add3edcfeb6054542068214313@haskell.org> #10767: SPECIALIZE generates warning but works fine -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deSugar/should_compile/T10767 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * testcase: => deSugar/should_compile/T10767 * status: new => closed * resolution: => fixed * milestone: => 8.0.1 Comment: Fixed in HEAD. I added a test. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 24 13:18:31 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Sep 2015 13:18:31 -0000 Subject: [GHC] #10555: RULE left-hand side too complicated to desugar In-Reply-To: <046.f79ed2aea9404c40727abba6768bec30@haskell.org> References: <046.f79ed2aea9404c40727abba6768bec30@haskell.org> Message-ID: <061.9d55021a74f3e3ecb298325319772853@haskell.org> #10555: RULE left-hand side too complicated to desugar -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.0.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: yes Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * related: #10699 => Old description: > GHC reports the following warnings for the `fast-math` package. To > reproduce, run `cabal install fast-math==1.0 --with-ghc=ghc-7.10.1` > (ghc-7.10.2 panics on this package, see #10699). > > {{{ > > Numeric/FastMath/Approximation.hs:60:1: Warning: > RULE left-hand side too complicated to desugar > Optimised lhs: case /## y2 x of wild_00 { __DEFAULT -> > (case /## y1 x of wild_X2 { __DEFAULT -> +## wild_X2 > }) wild_00 > } > Orig lhs: case /## y2 x of wild_00 { __DEFAULT -> > (case /## y1 x of wild_00 { __DEFAULT -> +## wild_00 }) > wild_00 > } > > Numeric/FastMath/Approximation.hs:63:1: Warning: > RULE left-hand side too complicated to desugar > Optimised lhs: case /## y2 x of wild_00 { __DEFAULT -> > (case /## y1 x of wild_X2 { __DEFAULT -> -## wild_X2 > }) wild_00 > } > Orig lhs: case /## y2 x of wild_00 { __DEFAULT -> > (case /## y1 x of wild_00 { __DEFAULT -> -## wild_00 }) > wild_00 > } > > Numeric/FastMath/Approximation.hs:103:1: Warning: > RULE left-hand side too complicated to desugar > Optimised lhs: case divideFloat# y2 x of wild_00 { __DEFAULT -> > (case divideFloat# y1 x of wild_X2 { __DEFAULT -> > minusFloat# wild_X2 > }) > wild_00 > } > Orig lhs: case divideFloat# y2 x of wild_00 { __DEFAULT -> > (case divideFloat# y1 x of wild_00 { __DEFAULT -> > minusFloat# wild_00 > }) > wild_00 > } > }}} New description: GHC reports multiple "RULE left-hand side too complicated to desugar" warnings for the `fast-math` package. Here is an testcase, extracted from `fast- math/Numeric/FastMath/Approximation.hs`: {{{ {-# LANGUAGE MagicHash #-} module T10555 where import GHC.Exts {-# RULES "double /,+ distribute" forall x y1 y2. (y1 /## x) +## (y2 /## x) = (y1 +## y2) /## x "double /,- distribute" forall x y1 y2. (y1 /## x) -## (y2 /## x) = (y1 -## y2) /## x "float /,- distribute" forall x y1 y2. (y1 `divideFloat#` x) `minusFloat#` (y2 `divideFloat#` x) = (y1 `minusFloat#` y2) `divideFloat#` x #-} }}} {{{ 2$ ghc-7.10.2 T10555.hs -fforce-recomp [1 of 1] Compiling T10555 ( T10555.hs, T10555.o ) T10555.hs:8:1: Warning: RULE left-hand side too complicated to desugar Optimised lhs: case /## y2 x of wild_00 { __DEFAULT -> (case /## y1 x of wild_X2 { __DEFAULT -> +## wild_X2 }) wild_00 } Orig lhs: case /## y2 x of wild_00 { __DEFAULT -> (case /## y1 x of wild_00 { __DEFAULT -> +## wild_00 }) wild_00 } T10555.hs:11:1: Warning: RULE left-hand side too complicated to desugar Optimised lhs: case /## y2 x of wild_00 { __DEFAULT -> (case /## y1 x of wild_X2 { __DEFAULT -> -## wild_X2 }) wild_00 } Orig lhs: case /## y2 x of wild_00 { __DEFAULT -> (case /## y1 x of wild_00 { __DEFAULT -> -## wild_00 }) wild_00 } T10555.hs:14:1: Warning: RULE left-hand side too complicated to desugar Optimised lhs: case divideFloat# y2 x of wild_00 { __DEFAULT -> (case divideFloat# y1 x of wild_X2 { __DEFAULT -> minusFloat# wild_X2 }) wild_00 } Orig lhs: case divideFloat# y2 x of wild_00 { __DEFAULT -> (case divideFloat# y1 x of wild_00 { __DEFAULT -> minusFloat# wild_00 }) wild_00 } }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 24 13:28:15 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Sep 2015 13:28:15 -0000 Subject: [GHC] #10747: Infix pattern synonyms fail to parse (regression) In-Reply-To: <048.dc77b17374ac8b11e33228cc9dd19430@haskell.org> References: <048.dc77b17374ac8b11e33228cc9dd19430@haskell.org> Message-ID: <063.5d6172e6b4732835bf6a69bbe6768fe1@haskell.org> #10747: Infix pattern synonyms fail to parse (regression) -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * cc: cactus, mpickering (added) * keywords: => PatternSynonyms * component: Compiler => Compiler (Parser) * milestone: => 7.10.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 24 13:33:51 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Sep 2015 13:33:51 -0000 Subject: [GHC] #10738: Make Exception datatypes into newtypes In-Reply-To: <050.5d465a0cdfbff2328b1c7589102aa667@haskell.org> References: <050.5d465a0cdfbff2328b1c7589102aa667@haskell.org> Message-ID: <065.6ea77e43c6e65aabdfcc2d5d286f8eb4@haskell.org> #10738: Make Exception datatypes into newtypes -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: libraries/base | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4961 | Differential Revisions: Phab:D1131 -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed * milestone: => 8.0.1 Comment: That benchmark isn't very stable. perf.haskell.org/ghc reports reports 0.385 seconds currently, and it jumps up and down quite a bit. Let's close this. https://perf.haskell.org/ghc/#graph/nofib/time/cryptarithm1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 24 13:41:33 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Sep 2015 13:41:33 -0000 Subject: [GHC] #10771: Installation of Ivory - Static flags have not been initialised In-Reply-To: <045.799f67bd688340da6719146f693d4e1e@haskell.org> References: <045.799f67bd688340da6719146f693d4e1e@haskell.org> Message-ID: <060.09553f7d154a5e3aa5c65fe6c09a1308@haskell.org> #10771: Installation of Ivory - Static flags have not been initialised -------------------------------------+------------------------------------- Reporter: stiege | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): Hmm, I tried reproducing your problem, but 'make all' inside the ivory directory installed ivory-examples-0.1.0.2 successfully for me. The command that comes next (running the tests) did fail, but that is probably unrelated: {{{ ./.cabal-sandbox/bin/ivory-c-clang-test test-dir-c-files **** Warning: the following files will be written multiple times during codegen! **** test-dir-c-files/Overflow.c test-dir-c-files/ivory_stdlib_string.c test-dir-c-files/Overflow.h test-dir-c-files/ivory_stdlib_string.h cd test-dir-c-files && gcc -Wall -Wextra -I. -std=c99 -c *.c *.h -Wno- missing-field-initializers -Wno-unused-parameter -Wno-unused-variable -DIVORY_DEPLOY ./ivory-model-check/dist/dist-sandbox-fa32d86d/build/test/test Tests should be safe foo2: FAIL Exception: cvc4: createProcess: runInteractiveProcess: exec: does not exist (No such file or directory) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 24 13:51:09 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Sep 2015 13:51:09 -0000 Subject: [GHC] #10737: GHC panic durring MVar operation In-Reply-To: <049.580b198cd1c514601e30fc759ca3d8fa@haskell.org> References: <049.580b198cd1c514601e30fc759ca3d8fa@haskell.org> Message-ID: <064.a1f1bdd0c0dcc995e5cd573dcbc032d9@haskell.org> #10737: GHC panic durring MVar operation -------------------------------------+------------------------------------- Reporter: dohaqatar7 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: #4245 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * related: => #4245 Comment: Might be the same underlying cause as #4245, although that ticket deals mostly with control-C in GHCi on Windows and Mac resulting in the same error message. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 24 13:51:31 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Sep 2015 13:51:31 -0000 Subject: [GHC] #10737: GHC panic durring MVar operation In-Reply-To: <049.580b198cd1c514601e30fc759ca3d8fa@haskell.org> References: <049.580b198cd1c514601e30fc759ca3d8fa@haskell.org> Message-ID: <064.dd712817847324e1a61a274b8bfaf305@haskell.org> #10737: GHC panic durring MVar operation -------------------------------------+------------------------------------- Reporter: dohaqatar7 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: #4245 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * component: Compiler => GHCi -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 24 13:54:33 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Sep 2015 13:54:33 -0000 Subject: [GHC] #10736: threadWaitRead/registerFd unusable In-Reply-To: <044.a96ce04f26395251bc71867625bc2939@haskell.org> References: <044.a96ce04f26395251bc71867625bc2939@haskell.org> Message-ID: <059.f58381f22048ee85fda989e6b6ebea9f@haskell.org> #10736: threadWaitRead/registerFd unusable -------------------------------------+------------------------------------- Reporter: mboes | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.10.2 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 thomie): * owner: => bgamari * failure: None/Unknown => Documentation bug * component: Compiler => Documentation -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 24 13:57:57 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Sep 2015 13:57:57 -0000 Subject: [GHC] #10767: SPECIALIZE generates warning but works fine In-Reply-To: <043.4ebd25de1b3c74f2b23206d88f108b5f@haskell.org> References: <043.4ebd25de1b3c74f2b23206d88f108b5f@haskell.org> Message-ID: <058.4b7ba3ec93b26e8454b2c97724ff6b3d@haskell.org> #10767: SPECIALIZE generates warning but works fine -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deSugar/should_compile/T10767 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by osa1): Interesting, I spent some time debugging this myself so I was wondering what fixed this. @thomie do you have any ideas? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 24 14:20:40 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Sep 2015 14:20:40 -0000 Subject: [GHC] #10767: SPECIALIZE generates warning but works fine In-Reply-To: <043.4ebd25de1b3c74f2b23206d88f108b5f@haskell.org> References: <043.4ebd25de1b3c74f2b23206d88f108b5f@haskell.org> Message-ID: <058.5b45d638485d8d3378f1f69d7105bbbf@haskell.org> #10767: SPECIALIZE generates warning but works fine -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deSugar/should_compile/T10767 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): I have no idea what fixed it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 24 14:27:18 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Sep 2015 14:27:18 -0000 Subject: [GHC] #10710: More self-explanatory pragmas for inlining phase control In-Reply-To: <046.f56ee656c180387739bfbd9da62ea521@haskell.org> References: <046.f56ee656c180387739bfbd9da62ea521@haskell.org> Message-ID: <061.d7c118477e36ac20d044b80a4ca4b825@haskell.org> #10710: More self-explanatory pragmas for inlining phase control -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): See also this mailinglist thread: https://www.mail-archive.com/ghc- devs at haskell.org/msg09238.html. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 24 14:32:12 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Sep 2015 14:32:12 -0000 Subject: [GHC] #10692: Replace (SourceText, FastString) with WithSourceText data type In-Reply-To: <044.c56d65db37c6df403dcc678377793b55@haskell.org> References: <044.c56d65db37c6df403dcc678377793b55@haskell.org> Message-ID: <059.4bc39b92f6029d17d27d1bc37206df83@haskell.org> #10692: Replace (SourceText,FastString) with WithSourceText data type -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1101 -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * differential: => Phab:D1101 * resolution: => fixed * milestone: => 8.0.1 Comment: This was only a refactoring. No testcases added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 24 14:35:51 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Sep 2015 14:35:51 -0000 Subject: [GHC] #10686: Process stops responding to sigINT In-Reply-To: <045.4331532de44ba06680224cb60774d4c5@haskell.org> References: <045.4331532de44ba06680224cb60774d4c5@haskell.org> Message-ID: <060.a132fdebe488a797146c4d13695815df@haskell.org> #10686: Process stops responding to sigINT -------------------------------------+------------------------------------- Reporter: hamish | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * cc: simonmar (added) * component: Compiler => Runtime System -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 24 14:41:03 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Sep 2015 14:41:03 -0000 Subject: [GHC] #10674: Expose OSThreadID and assorted functions from Haskell In-Reply-To: <047.35673a1245c9e2068498a881d95a8afe@haskell.org> References: <047.35673a1245c9e2068498a881d95a8afe@haskell.org> Message-ID: <062.a55c37fc5021cf7107f3dfbfa997c734@haskell.org> #10674: Expose OSThreadID and assorted functions from Haskell -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * cc: simonmar (added) * component: Compiler => Runtime System -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 24 14:49:26 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Sep 2015 14:49:26 -0000 Subject: [GHC] #10662: GHC warning shows technical summary of AST instead of the user's code In-Reply-To: <047.fe5b14891f46efc740c72fc5c88bcc32@haskell.org> References: <047.fe5b14891f46efc740c72fc5c88bcc32@haskell.org> Message-ID: <062.67c99aebd3298fde23516ddefe746c90@haskell.org> #10662: GHC warning shows technical summary of AST instead of the user's code -------------------------------------+------------------------------------- Reporter: kolmodin | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2-rc2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 24 15:12:13 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Sep 2015 15:12:13 -0000 Subject: [GHC] #10611: Runtime crash while running psc In-Reply-To: <044.6711fcf2994b3fa4d0ff74f3c08bc1a4@haskell.org> References: <044.6711fcf2994b3fa4d0ff74f3c08bc1a4@haskell.org> Message-ID: <059.37fa444e541f1056f1aa32ff538ce9aa@haskell.org> #10611: Runtime crash while running psc -------------------------------------+------------------------------------- Reporter: qxjit | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => infoneeded Comment: Can you try to reproduce this problem with the latest GHC release? Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 24 15:13:58 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Sep 2015 15:13:58 -0000 Subject: [GHC] #10625: Spurious unused quantified type variable warning with ExistentialQuantification In-Reply-To: <050.bcfa2a8486244e674e467da363afe987@haskell.org> References: <050.bcfa2a8486244e674e467da363afe987@haskell.org> Message-ID: <065.e027b902f48d367ff796538f5413c20d@haskell.org> #10625: Spurious unused quantified type variable warning with ExistentialQuantification -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: | ExistentialQuantification Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #5331 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * keywords: => ExistentialQuantification * component: Compiler => Compiler (Type checker) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 24 15:14:58 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Sep 2015 15:14:58 -0000 Subject: [GHC] #10631: Report of GHC Panic In-Reply-To: <048.0d7915ea1be06d70aee5e73f020551d8@haskell.org> References: <048.0d7915ea1be06d70aee5e73f020551d8@haskell.org> Message-ID: <063.755f6d54ef4a1e6ce2daa5a422ae683b@haskell.org> #10631: Report of GHC Panic -------------------------------------+------------------------------------- Reporter: seewalker | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.1 (Linking) | Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * component: Compiler => Compiler (Linking) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 24 15:17:45 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Sep 2015 15:17:45 -0000 Subject: [GHC] #10631: Report of GHC Panic In-Reply-To: <048.0d7915ea1be06d70aee5e73f020551d8@haskell.org> References: <048.0d7915ea1be06d70aee5e73f020551d8@haskell.org> Message-ID: <063.06770f8d343626275b511d066012cb00@haskell.org> #10631: Report of GHC Panic -------------------------------------+------------------------------------- Reporter: seewalker | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.1 (Linking) | Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > I'll just copy here the error message; I wouldn't say I have the > judgement to interpret it: > > ''ghc: panic! (the 'impossible' happened) > (GHC version 7.10.1 for x86_64-apple-darwin): > Loading temp shared object failed: > dlopen(/var/folders/84/5rj51n8x70g4km60lfh_ds1m0000gt/T/ghc22694_0/libghc22694_107.dylib, > 5): Symbol not found: > _AlexSzuELoZZpfyhWUk8IXGTl3Kiel_ModulesziDBTypes_zdfPersistFieldLinkTag_closure > Referenced from: > /var/folders/84/5rj51n8x70g4km60lfh_ds1m0000gt/T/ghc22694_0/libghc22694_107.dylib > Expected in: flat namespace > in > /var/folders/84/5rj51n8x70g4km60lfh_ds1m0000gt/T/ghc22694_0/libghc22694_107.dylib > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug'' > > This occurred while interactively developing a website with "yesod > devel". After the compiler crashed, I killed the program, invoked "yesod > devel" again without changing anything in my source code. This next time, > no error occurred. New description: I'll just copy here the error message; I wouldn't say I have the judgement to interpret it: {{{ ''ghc: panic! (the 'impossible' happened) (GHC version 7.10.1 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/84/5rj51n8x70g4km60lfh_ds1m0000gt/T/ghc22694_0/libghc22694_107.dylib, 5): Symbol not found: _AlexSzuELoZZpfyhWUk8IXGTl3Kiel_ModulesziDBTypes_zdfPersistFieldLinkTag_closure Referenced from: /var/folders/84/5rj51n8x70g4km60lfh_ds1m0000gt/T/ghc22694_0/libghc22694_107.dylib Expected in: flat namespace in /var/folders/84/5rj51n8x70g4km60lfh_ds1m0000gt/T/ghc22694_0/libghc22694_107.dylib Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug'' }}} This occurred while interactively developing a website with "yesod devel". After the compiler crashed, I killed the program, invoked "yesod devel" again without changing anything in my source code. This next time, no error occurred. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 24 15:20:39 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Sep 2015 15:20:39 -0000 Subject: [GHC] #10600: -fwarn-incomplete-patterns doesn't work with -fno-code In-Reply-To: <043.972d3170891da80a4e96bca7b675a836@haskell.org> References: <043.972d3170891da80a4e96bca7b675a836@haskell.org> Message-ID: <058.ab582cee09fa6a53763c1aaf988074f5@haskell.org> #10600: -fwarn-incomplete-patterns doesn't work with -fno-code -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | driver/T8101b Blocked By: | Blocking: Related Tickets: #8101 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 24 15:24:13 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Sep 2015 15:24:13 -0000 Subject: [GHC] #10700: include/stg/Prim.h isn't C++ compatible In-Reply-To: <045.8e82f2e96f7b839c9a73a7c13e4442bc@haskell.org> References: <045.8e82f2e96f7b839c9a73a7c13e4442bc@haskell.org> Message-ID: <060.0ee3e0327acaf8e6fd040d296ae32615@haskell.org> #10700: include/stg/Prim.h isn't C++ compatible -------------------------------------+------------------------------------- Reporter: Fabian | Owner: rasen Type: bug | Status: merge Priority: normal | Milestone: 7.10.3 Component: Compiler (FFI) | Version: 7.10.1 Resolution: fixed | Keywords: FFI, | newcomers Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1107 -------------------------------------+------------------------------------- Changes (by simonmar): * status: closed => merge * milestone: => 7.10.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 24 15:34:06 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Sep 2015 15:34:06 -0000 Subject: [GHC] #10800: vector-0.11 compile time increased substantially with 7.10.1 In-Reply-To: <046.b08e48c7e3091b06d4d1122f9be87efe@haskell.org> References: <046.b08e48c7e3091b06d4d1122f9be87efe@haskell.org> Message-ID: <061.8de7d651fe55a64fc226316552f79054@haskell.org> #10800: vector-0.11 compile time increased substantially with 7.10.1 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): `-ddump-inlinings` reveals that there are indeed 7.10 is doing a great deal more inlining than 7.8. Right off the bat 7.10 inlines a variety of methods from the `Applicative` et al. which never appear to be inlined under 7.8, {{{ Inlining done: Data.Vector.Fusion.Util.$fApplicativeId_$cpure Inlining done: Data.Vector.Fusion.Util.$fApplicativeId4 Inlining done: Data.Vector.Fusion.Util.$fApplicativeId_$cpure Inlining done: Data.Vector.Fusion.Util.$fApplicativeId4 Inlining done: Data.Vector.Fusion.Util.$fApplicativeId_$cpure Inlining done: Data.Vector.Fusion.Util.$fApplicativeId4 Inlining done: Data.Vector.Fusion.Util.$fApplicativeId_$cpure Inlining done: Data.Vector.Fusion.Util.$fApplicativeId4 Inlining done: GHC.Show.$fShow(,,)_$cshowList Inlining done: GHC.Show.$fShow(,,)_$cshow Inlining done: Test.QuickCheck.Arbitrary.$fArbitrary(,,)_$cshrink Inlining done: Test.QuickCheck.Arbitrary.$fArbitrary(,,)_$carbitrary Inlining done: Utilities.$fTestDataVector2_$cequal }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 24 15:40:13 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Sep 2015 15:40:13 -0000 Subject: [GHC] #9173: Better type error messages In-Reply-To: <046.f8f24aa2ddaa3d579bc40f0b6f04f6b7@haskell.org> References: <046.f8f24aa2ddaa3d579bc40f0b6f04f6b7@haskell.org> Message-ID: <061.0cde2ce0af468c691449f122ec157739@haskell.org> #9173: Better type error messages -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): Reddit user physicologist [https://www.reddit.com/r/haskell/comments/3m2iiv/ghc_error_messages/cvckb3c writes]: While I love the the proposal in the ticket, I feel that a purely textual change to the error message could be a great boon without changing a single line of code. "Expected" versus "actual" don't really the nature of the problem. For example, what is the type of foo in the following {{{ foo :: Int foo = "Howdy!" }}} Is foo actually an Int, since that was declared? Did the compiler expect foo to be a String, since that's what we passed it? Or is foo actually a "String", since that's what it contained, but the compiler expected a Int, since that's what we told it would be contained? Perhaps just changing {{{ Couldn't match expected type 'Foo' with actual type 'Bar' }}} to {{{ Couldn't match declared type 'Foo' against a value of type `Bar' }}} might make things clearer? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 24 16:43:48 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Sep 2015 16:43:48 -0000 Subject: [GHC] #10487: DeriveGeneric breaks when the same data name is used in different modules In-Reply-To: <051.f823b016355f38c348182e98da9d4ae1@haskell.org> References: <051.f823b016355f38c348182e98da9d4ae1@haskell.org> Message-ID: <066.69709bbf22940427de086fb550f26780@haskell.org> #10487: DeriveGeneric breaks when the same data name is used in different modules -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: osa1 Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T10487 Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1081 -------------------------------------+------------------------------------- Changes (by osa1): * testcase: => T10487 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 24 17:48:42 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Sep 2015 17:48:42 -0000 Subject: [GHC] #10600: -fwarn-incomplete-patterns doesn't work with -fno-code In-Reply-To: <043.972d3170891da80a4e96bca7b675a836@haskell.org> References: <043.972d3170891da80a4e96bca7b675a836@haskell.org> Message-ID: <058.84098656901673e12e506c5949ed32fb@haskell.org> #10600: -fwarn-incomplete-patterns doesn't work with -fno-code -------------------------------------+------------------------------------- Reporter: akio | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | driver/T8101b Blocked By: | Blocking: Related Tickets: #8101 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * owner: => ezyang -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 24 18:43:00 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Sep 2015 18:43:00 -0000 Subject: [GHC] #10600: -fwarn-incomplete-patterns doesn't work with -fno-code In-Reply-To: <043.972d3170891da80a4e96bca7b675a836@haskell.org> References: <043.972d3170891da80a4e96bca7b675a836@haskell.org> Message-ID: <058.d77ba8eb4d1fc510a7d451842d1800aa@haskell.org> #10600: -fwarn-incomplete-patterns doesn't work with -fno-code -------------------------------------+------------------------------------- Reporter: akio | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | driver/T8101b Blocked By: | Blocking: Related Tickets: #8101 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): So... I implemented this. But then I got a lint error! {{{ "/home/hs01/ezyang/ghc-validate/inplace/bin/haddock" --verbosity=0 --odir="libraries/ghc-prim/dist-install/doc/html/ghc-prim" --no-tmp-comp- dir --dump-interface=libraries/ghc-prim/dist-install/doc/html/ghc-prim /ghc-prim.haddock --html --hoogle --title="ghc-prim-0.4.0.0: GHC primitives" --prologue="libraries/ghc-prim/dist-install/haddock- prologue.txt" --optghc=-hisuf --optghc=dyn_hi --optghc=-osuf --optghc=dyn_o --optghc=-hcsuf --optghc=dyn_hc --optghc=-fPIC --optghc=-dynamic --optghc=-O0 --optghc=-H64m --optghc=-Werror --optghc =-this-package-key --optghc=8TmvWUcS1U1IKHT0levwg3 --optghc=-hide-all- packages --optghc=-i --optghc=-ilibraries/ghc-prim/. --optghc=-ilibraries /ghc-prim/dist-install/build --optghc=-ilibraries/ghc-prim/dist- install/build/autogen --optghc=-Ilibraries/ghc-prim/dist-install/build --optghc=-Ilibraries/ghc-prim/dist-install/build/autogen --optghc=-Ilibraries/ghc-prim/. --optghc=-optP-include --optghc=-optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h --optghc=-package-id --optghc=builtin_rts --optghc=-this-package-key --optghc=ghc-prim --optghc=-XHaskell2010 --optghc=-O --optghc=-dcore-lint --optghc=-no-user-package-db --optghc=-rtsopts --optghc=-fno-warn- trustworthy-safe --optghc=-fno-warn-deprecated-flags --optghc=-fno-warn- tabs --optghc=-odir --optghc=libraries/ghc-prim/dist-install/build --optghc=-hidir --optghc=libraries/ghc-prim/dist-install/build --optghc=-stubdir --optghc=libraries/ghc-prim/dist-install/build --source- module=src/%{MODULE/./-}.html --source- entity=src/%{MODULE/./-}.html#%{NAME} libraries/ghc- prim/./GHC/CString.hs libraries/ghc-prim/./GHC/Classes.hs libraries/ghc- prim/./GHC/Debug.hs libraries/ghc-prim/./GHC/IntWord64.hs libraries/ghc- prim/./GHC/Magic.hs libraries/ghc-prim/dist- install/build/GHC/PrimopWrappers.hs libraries/ghc-prim/./GHC/Tuple.hs libraries/ghc-prim/./GHC/Types.hs libraries/ghc-prim/dist- install/build/autogen/GHC/Prim.hs +RTS -t"libraries/ghc-prim/dist- install/haddock.t" --machine-readable *** Core Lint errors : in result of Desugar (after optimization) *** : warning: [RHS of proxy# :: forall a_a3EW. Proxy# a_a3EW] The type of this binder is primitive: proxy# Binder's type: forall a_a3EW. Proxy# a_a3EW }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 24 21:56:45 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Sep 2015 21:56:45 -0000 Subject: [GHC] #9173: Better type error messages In-Reply-To: <046.f8f24aa2ddaa3d579bc40f0b6f04f6b7@haskell.org> References: <046.f8f24aa2ddaa3d579bc40f0b6f04f6b7@haskell.org> Message-ID: <061.5c5dc24714e1ca6ae0d08d6dc78a6a57@haskell.org> #9173: Better type error messages -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by chreekat): thomie, that gets to the root of my problem with the message precisely! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 24 23:24:24 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Sep 2015 23:24:24 -0000 Subject: [GHC] #10383: AArch64: get GHC Calling convention working In-Reply-To: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> References: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> Message-ID: <059.02e84e62a2b84147ae2fe7e9b6b828ec@haskell.org> #10383: AArch64: get GHC Calling convention working ----------------------------------------+---------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------------+---------------------------------- Comment (by erikd): Yes, the build always fails the first time it tries to use the `ghc- stage2` binary. In fact that binary will also fail the same way when building the most trivial "hello world" program. It fails in exactly the same way when run as `taskset 0x02 inplace/bin /ghc-stage2 hello.hs -o hello`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 25 03:08:57 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Sep 2015 03:08:57 -0000 Subject: [GHC] #10168: generalize filterM, mapAndUnzipM, zipWithM, zipWithM_, replicateM, replicateM_ In-Reply-To: <048.86721c518b657437564df331356981ea@haskell.org> References: <048.86721c518b657437564df331356981ea@haskell.org> Message-ID: <063.29087a65f18e79d39a13e65dbd981918@haskell.org> #10168: generalize filterM, mapAndUnzipM, zipWithM, zipWithM_, replicateM, replicateM_ -------------------------------------+------------------------------------- Reporter: strake888 | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: ekmett (added) Comment: It might be nice to take the opportunity to define `replicateM` directly, rather than doing so in terms of `sequenceA` and `replicate`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 25 03:33:15 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Sep 2015 03:33:15 -0000 Subject: [GHC] #10168: generalize filterM, mapAndUnzipM, zipWithM, zipWithM_, replicateM, replicateM_ In-Reply-To: <048.86721c518b657437564df331356981ea@haskell.org> References: <048.86721c518b657437564df331356981ea@haskell.org> Message-ID: <063.65f9e9777b5b59626427d6cc0ff60e27@haskell.org> #10168: generalize filterM, mapAndUnzipM, zipWithM, zipWithM_, replicateM, replicateM_ -------------------------------------+------------------------------------- Reporter: strake888 | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ekmett): For the record there is no objection here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 25 04:56:00 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Sep 2015 04:56:00 -0000 Subject: [GHC] #9173: Better type error messages In-Reply-To: <046.f8f24aa2ddaa3d579bc40f0b6f04f6b7@haskell.org> References: <046.f8f24aa2ddaa3d579bc40f0b6f04f6b7@haskell.org> Message-ID: <061.d3ada59952b7f1e524188d1b1442bbc9@haskell.org> #9173: Better type error messages -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): The error there would not be about the type of `foo`, though. It would be about the type of `"Howdy!"`. {{{ Foo.hs:4:7: Couldn't match expected type ?Int? with actual type ?[Char]? In the expression: "Howdy!" In an equation for ?foo?: foo = "Howdy!" }}} The "actual type" is ... the actual type of the expression `"Howdy!"` that the compiler points out. The "expected type" is the type expected from the context, that is, the type the expression would have to have for the whole thing to type check. I know lots of people find this confusing but I have never been able to understand why... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 25 05:06:37 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Sep 2015 05:06:37 -0000 Subject: [GHC] #9173: Better type error messages In-Reply-To: <046.f8f24aa2ddaa3d579bc40f0b6f04f6b7@haskell.org> References: <046.f8f24aa2ddaa3d579bc40f0b6f04f6b7@haskell.org> Message-ID: <061.679a7a2b3fd5d0564037a4a619f81b91@haskell.org> #9173: Better type error messages -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): I wonder if it would help at all to just reverse the order of the two, that is, {{{ Couldn't match actual type ?[Char]? with expected type ?Int? In the expression: "Howdy!" }}} Presumably the programmer has a strong association between the expression and its (actual) type, and then can work out what "expected type" refers to by elimination. I'm also not that attached to the phrase "expected type". We could be more explicit and say something like "type ?Int? expected from context". I think the phrase "actual type" is quite good, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 25 05:51:39 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Sep 2015 05:51:39 -0000 Subject: [GHC] #10168: generalize filterM, mapAndUnzipM, zipWithM, zipWithM_, replicateM, replicateM_ In-Reply-To: <048.86721c518b657437564df331356981ea@haskell.org> References: <048.86721c518b657437564df331356981ea@haskell.org> Message-ID: <063.814ad4a594239d635119801f77a573fa@haskell.org> #10168: generalize filterM, mapAndUnzipM, zipWithM, zipWithM_, replicateM, replicateM_ -------------------------------------+------------------------------------- Reporter: strake888 | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by strake888): You mean {{{#!hs replicateM 0 _ = pure [] replicateM n x = liftA2 (:) x (replicateM (n-1) x) }}} ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 25 07:16:18 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Sep 2015 07:16:18 -0000 Subject: [GHC] #9173: Better type error messages In-Reply-To: <046.f8f24aa2ddaa3d579bc40f0b6f04f6b7@haskell.org> References: <046.f8f24aa2ddaa3d579bc40f0b6f04f6b7@haskell.org> Message-ID: <061.3ff002007b2ae7ce7bdae3740525b1a2@haskell.org> #9173: Better type error messages -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): The trouble with "declared type" is that it often isn't declared. Consider {{{ not 'c' }}} The actual type of `'c'` is `Char`, but the type expected by the context (the call of `not`) is `Bool`. But it'd be confusing to say that `Bool` was the "declared" type! Switching the order as Reid suggests in comment:11 would be easy, and I can see that it might help. Do others like that? I'd also be ok with saying "type expected by the context" instead of just "expected". That longer phrase would also suggest putting it second. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 25 08:12:59 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Sep 2015 08:12:59 -0000 Subject: [GHC] #10914: Bad symbol resolution on Darwin when using DYLD_FORCE_FLAT_NAMESPACE=1 Message-ID: <047.9268eb7f03934b85eb39681f4890afc7@haskell.org> #10914: Bad symbol resolution on Darwin when using DYLD_FORCE_FLAT_NAMESPACE=1 -----------------------------------------+------------------------------- Reporter: jacereda | Owner: Type: bug | Status: new Priority: high | Milestone: Component: GHCi | Version: 7.10.2 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -----------------------------------------+------------------------------- Starting ghci as: {{{ env DYLD_FORCE_FLAT_NAMESPACE=1 ghci }}} can cause symbol resolution to fail. I tried with Data.Hashable as follows: {{{ import Data.Hashable main = putStrLn $ show $ hashWithSalt 0 "foo" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 25 08:14:02 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Sep 2015 08:14:02 -0000 Subject: [GHC] #10914: Bad symbol resolution on Darwin when using DYLD_FORCE_FLAT_NAMESPACE=1 In-Reply-To: <047.9268eb7f03934b85eb39681f4890afc7@haskell.org> References: <047.9268eb7f03934b85eb39681f4890afc7@haskell.org> Message-ID: <062.239e37ec1aabd5a80187b5c28c20258e@haskell.org> #10914: Bad symbol resolution on Darwin when using DYLD_FORCE_FLAT_NAMESPACE=1 -------------------------------+----------------------------------------- Reporter: jacereda | Owner: Type: bug | Status: new Priority: high | Milestone: Component: GHCi | Version: 7.10.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+----------------------------------------- Changes (by jacereda): * Attachment "0001-Fix-for-improper-name-resolution-on-Darwin-when- usin.patch" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 25 08:15:31 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Sep 2015 08:15:31 -0000 Subject: [GHC] #10914: Bad symbol resolution on Darwin when using DYLD_FORCE_FLAT_NAMESPACE=1 In-Reply-To: <047.9268eb7f03934b85eb39681f4890afc7@haskell.org> References: <047.9268eb7f03934b85eb39681f4890afc7@haskell.org> Message-ID: <062.2b21f860b29c6047303c3233c003f762@haskell.org> #10914: Bad symbol resolution on Darwin when using DYLD_FORCE_FLAT_NAMESPACE=1 -------------------------------+----------------------------------------- Reporter: jacereda | Owner: Type: bug | Status: patch Priority: high | Milestone: Component: GHCi | Version: 7.10.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+----------------------------------------- Changes (by jacereda): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 25 10:46:38 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Sep 2015 10:46:38 -0000 Subject: [GHC] #10867: Primop types should not mention () In-Reply-To: <046.c2e6159f1c64c1079ec9b781aa715970@haskell.org> References: <046.c2e6159f1c64c1079ec9b781aa715970@haskell.org> Message-ID: <061.ec85fc09e75d8a3d58faa6186fa73b95@haskell.org> #10867: Primop types should not mention () -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: | Phab:D1276, Phab:D1272 -------------------------------------+------------------------------------- Changes (by bgamari): * differential: => Phab:D1276, Phab:D1272 Comment: Simon Marlow suggested that wrapping finalizers to peel off the return value from the returned unboxed tuple is unnecessary. fb4092642f057f258d07cd6979925f4e2579eda6 reverts changes the type from Simon PJ's suggestion of (implemented in Phab:D1271), {{{#!hs mkWeak# :: o -> b -> (State# RealWorld -> State# RealWorld) -> State# RealWorld -> (# State# RealWorld, Weak# b #) }}} to, {{{#!hs mkWeak# :: o -> b -> (State# RealWorld -> (# State# RealWorld, c #)) -> State# RealWorld -> (# State# RealWorld, Weak# b #) }}} This was done in Phab:D1276. Note that the return type `c` is now fully polymorphic. It is the user's responsibility to ignore this value. This is explained in a comment. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 25 10:46:44 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Sep 2015 10:46:44 -0000 Subject: [GHC] #10867: Primop types should not mention () In-Reply-To: <046.c2e6159f1c64c1079ec9b781aa715970@haskell.org> References: <046.c2e6159f1c64c1079ec9b781aa715970@haskell.org> Message-ID: <061.cd7fdace244c437756c3e74a678d395c@haskell.org> #10867: Primop types should not mention () -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: | Phab:D1276, Phab:D1272 -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 25 11:07:51 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Sep 2015 11:07:51 -0000 Subject: [GHC] #10907: GHC fails to read file with byte-order mark when LANG=C In-Reply-To: <050.38d42c04556dad88e5087381da8b4d80@haskell.org> References: <050.38d42c04556dad88e5087381da8b4d80@haskell.org> Message-ID: <065.94faf5531b4be65a2e69159b1e4275c1@haskell.org> #10907: GHC fails to read file with byte-order mark when LANG=C -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC doesn't work | (amd64) at all | Test Case: Blocked By: | Blocking: Related Tickets: #6016, #6037 | Differential Revisions: Phab:D1274 -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"f7fd864ce6d41cf22d25f18a0cdc5e2e9db71304/ghc" f7fd864c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f7fd864ce6d41cf22d25f18a0cdc5e2e9db71304" Skip a possible BOM in utf8 encoding and not the system locale, which might be something else. This fixes bug #10907. A test is added, but less useful than it could be until task #10909 is done. Differential Revision: D1274 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 25 11:07:51 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Sep 2015 11:07:51 -0000 Subject: [GHC] #10909: Test suite: Support non-utf8 locale In-Reply-To: <046.fa6aac9d3c2ea6a99e9e4dcd0986d398@haskell.org> References: <046.fa6aac9d3c2ea6a99e9e4dcd0986d398@haskell.org> Message-ID: <061.2a5075247d957de755eda3d954382251@haskell.org> #10909: Test suite: Support non-utf8 locale -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"f7fd864ce6d41cf22d25f18a0cdc5e2e9db71304/ghc" f7fd864c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f7fd864ce6d41cf22d25f18a0cdc5e2e9db71304" Skip a possible BOM in utf8 encoding and not the system locale, which might be something else. This fixes bug #10907. A test is added, but less useful than it could be until task #10909 is done. Differential Revision: D1274 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 25 11:08:09 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Sep 2015 11:08:09 -0000 Subject: [GHC] #10907: GHC fails to read file with byte-order mark when LANG=C In-Reply-To: <050.38d42c04556dad88e5087381da8b4d80@haskell.org> References: <050.38d42c04556dad88e5087381da8b4d80@haskell.org> Message-ID: <065.aa5d2a385b6a0b82d798fd207b8a7ccd@haskell.org> #10907: GHC fails to read file with byte-order mark when LANG=C -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC doesn't work | (amd64) at all | Test Case: Blocked By: | Blocking: Related Tickets: #6016, #6037 | Differential Revisions: Phab:D1274 -------------------------------------+------------------------------------- Changes (by nomeata): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 25 13:58:23 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Sep 2015 13:58:23 -0000 Subject: [GHC] #10869: Option to dump preprocessed source In-Reply-To: <046.34bba2c2c1e4ccec0498d1f1e04c25f9@haskell.org> References: <046.34bba2c2c1e4ccec0498d1f1e04c25f9@haskell.org> Message-ID: <061.a8ff2508c035199075b126ff6c7a7d97@haskell.org> #10869: Option to dump preprocessed source -------------------------------------+------------------------------------- Reporter: phischu | Owner: Type: feature request | Status: closed Priority: low | Milestone: Component: Driver | Version: 7.10.2 Resolution: invalid | Keywords: easy Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by phischu): I am sorry that the request was not clear. `-E` stops ghc after preprocessing. But I want ghc to work normally but in addition dump the preprocessed source files. So, yes, I kinda want `--make` and `-E` to work together. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 25 14:40:34 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Sep 2015 14:40:34 -0000 Subject: [GHC] #9865: Comonads in base library In-Reply-To: <050.1aeed8f93bd414fa38dcb5213e8076cb@haskell.org> References: <050.1aeed8f93bd414fa38dcb5213e8076cb@haskell.org> Message-ID: <065.887842c0e82a71b84b45e13ad6f8d87a@haskell.org> #9865: Comonads in base library -------------------------------------+------------------------------------- Reporter: spacekitteh | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by strake888): * cc: ekmett (added) Comment: I think we ought to not simply copy ekmett's comonad thoughtlessly. In particular, we ought to consider how this would interact with such other base classes as Applicative, as we may want Apply which ought to be a superclass of Applicative; and the names of the Comonadic methods, as I much prefer (copure, cobind, cojoin) as (extract, extend, duplicate) seem a little random and are mnemonically poor in comparison if one already knows Applicative and Monad. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 25 14:52:00 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Sep 2015 14:52:00 -0000 Subject: [GHC] #10914: Bad symbol resolution on Darwin when using DYLD_FORCE_FLAT_NAMESPACE=1 In-Reply-To: <047.9268eb7f03934b85eb39681f4890afc7@haskell.org> References: <047.9268eb7f03934b85eb39681f4890afc7@haskell.org> Message-ID: <062.420bd7da353a9c6c671f5837e079c9b8@haskell.org> #10914: Bad symbol resolution on Darwin when using DYLD_FORCE_FLAT_NAMESPACE=1 -------------------------------------+------------------------------------- Reporter: jacereda | Owner: Type: bug | Status: patch Priority: high | Milestone: Component: Runtime System | Version: 7.10.2 (Linker) | Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by jacereda): * failure: GHCi crash => Runtime crash * component: GHCi => Runtime System (Linker) Old description: > Starting ghci as: > > {{{ > env DYLD_FORCE_FLAT_NAMESPACE=1 ghci > }}} > > can cause symbol resolution to fail. I tried with Data.Hashable as > follows: > > {{{ > import Data.Hashable > main = putStrLn $ show $ hashWithSalt 0 "foo" > }}} New description: The following command: {{{ env DYLD_FORCE_FLAT_NAMESPACE=1 ghc -e 'Data.Hashable.hashWithSalt 0 "foo"' }}} causes symbol resolution to fail. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 26 16:02:15 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Sep 2015 16:02:15 -0000 Subject: [GHC] #10915: Statistical profiling support in the RTS Message-ID: <046.7220ccda33e87c4faaaf43cf13abd1b6@haskell.org> #10915: Statistical profiling support in the RTS -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: feature | Status: new request | Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D1215, | Phab:D1214 | -------------------------------------+------------------------------------- Now since GHC can produce useful debugging information (e.g. DWARF annotations and source notes) in compiled objects, it would great if we could leverage this for more efficient profiling. While ideally we would be able to rely on external tools like `perf` for this task, this would require that the STG stack be walkable like a standard C stack. A more feasible alternative is to incorporate a simple statistical profiler into the RTS. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 26 16:11:33 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Sep 2015 16:11:33 -0000 Subject: [GHC] #10915: Statistical profiling support in the RTS In-Reply-To: <046.7220ccda33e87c4faaaf43cf13abd1b6@haskell.org> References: <046.7220ccda33e87c4faaaf43cf13abd1b6@haskell.org> Message-ID: <061.c006aba2666d103520fa5fedc949de99@haskell.org> #10915: Statistical profiling support in the RTS -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1215, | Phab:D1214 -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > Now since GHC can produce useful debugging information (e.g. DWARF > annotations and source notes) in compiled objects, it would great if we > could leverage this for more efficient profiling. > > While ideally we would be able to rely on external tools like `perf` for > this task, this would require that the STG stack be walkable like a > standard C stack. > > A more feasible alternative is to incorporate a simple statistical > profiler into the RTS. New description: Now since GHC can produce useful debugging information (e.g. DWARF annotations and source notes) in compiled objects, it would great if we could leverage this for more efficient profiling. While ideally we would be able to rely on external tools like `perf` for this task, this would require that the STG stack be walkable like a standard C stack. A more feasible alternative is to incorporate a simple statistical profiler into the RTS. Profiling is defined loosely here as the collection of information describing the current state of evaluation in response to certain triggers. In practice this will be the collection of the current symbol being evaluated triggered on a few events of interest, * Memory allocation * Periodic timers for time-based profiling * Blackhole blocking for locating performance problems due to sharing in parallel programs -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 26 16:43:02 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Sep 2015 16:43:02 -0000 Subject: [GHC] #9910: ghc's dwarf (-g) output does not like Unicode (Char.intToDigit: not a digit 136) In-Reply-To: <045.2bab4361f44b745c3385fb704805cc5b@haskell.org> References: <045.2bab4361f44b745c3385fb704805cc5b@haskell.org> Message-ID: <060.84137794cf16fe1d5ab10c362dd2d778@haskell.org> #9910: ghc's dwarf (-g) output does not like Unicode (Char.intToDigit: not a digit 136) -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * failure: None/Unknown => Compile-time crash * resolution: => fixed * milestone: => 8.0.1 Comment: I believe this is fixed in `master`, {{{ $ inplace/bin/ghc-stage2 -fforce-recomp -g2 testsuite/tests/parser/unicode/utf8_024.hs [1 of 1] Compiling Main ( testsuite/tests/parser/unicode/utf8_024.hs, testsuite/tests/parser/unicode/utf8_024.o ) testsuite/tests/parser/unicode/utf8_024.hs:174:6: warning: Tab character found here, and in 15 further locations. Please use spaces instead. Linking testsuite/tests/parser/unicode/utf8_024 ... $ testsuite/tests/parser/unicode/utf8_024 29 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 26 17:10:31 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Sep 2015 17:10:31 -0000 Subject: [GHC] #10915: Statistical profiling support in the RTS In-Reply-To: <046.7220ccda33e87c4faaaf43cf13abd1b6@haskell.org> References: <046.7220ccda33e87c4faaaf43cf13abd1b6@haskell.org> Message-ID: <061.24d4e409dc31904f5e984f8bae71a9f3@haskell.org> #10915: Statistical profiling support in the RTS -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1215, | Phab:D1214 -------------------------------------+------------------------------------- Changes (by osa1): * cc: osa1 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 26 17:21:15 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Sep 2015 17:21:15 -0000 Subject: [GHC] #10916: PATH in Windows corrupt after 2nd install og GHC Message-ID: <045.d72183e3656d1293df593cae21c559a8@haskell.org> #10916: PATH in Windows corrupt after 2nd install og GHC ------------------------------------+--------------------------------- Reporter: ambusy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: None | Version: 7.10.2 Keywords: installation | Operating System: Windows Architecture: Other | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | ------------------------------------+--------------------------------- Installed (absolute beginner!) Haskell default on windows X64: on the C:\ disk. Leads to problems with UAC rights when starting a tutorial with ghci. Disinstalled, and reinstalled on F:. In the path one reference to C:\Program Files\Haskell\bin remains, and ghci does not start. Below the output of my PATH. F:\>path PATH=C:\Program Files\Haskell\bin;F:\Haskell\lib\extralibs\bin;F:\Haskell\bin;C: \Program Files\Common Files\Microsoft Shared\Windows Live;C:\Program Files (x86) \Common Files\Microsoft Shared\Windows Live;C:\Windows\system32;C:\Windows;C:\Wi ndows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\Windows Live\Shared;C:\Program Files\Microsoft SQL Server\110\Tools\Binn\ ;F:\Haskell\mingw\bin;C:\Users\ambusy\AppData\Roaming\cabal\bin -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 26 17:23:16 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Sep 2015 17:23:16 -0000 Subject: [GHC] #8920: Alternative GADT syntax In-Reply-To: <044.aac5121bf5758b0193e2f09652955ddf@haskell.org> References: <044.aac5121bf5758b0193e2f09652955ddf@haskell.org> Message-ID: <059.8027244edf7a0210f47f0eca16b6ef8f@haskell.org> #8920: Alternative GADT syntax -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.8.1-rc2 (Parser) | Resolution: | Keywords: gadts Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by strake888): why? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 26 17:48:38 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Sep 2015 17:48:38 -0000 Subject: [GHC] #10916: PATH in Windows corrupt after 2nd install og GHC In-Reply-To: <045.d72183e3656d1293df593cae21c559a8@haskell.org> References: <045.d72183e3656d1293df593cae21c559a8@haskell.org> Message-ID: <060.573e55144ebb034443f5e2fedb633f1a@haskell.org> #10916: PATH in Windows corrupt after 2nd install og GHC ---------------------------------+------------------------------------ Reporter: ambusy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: None | Version: 7.10.2 Resolution: | Keywords: installation Operating System: Windows | Architecture: Other Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): ---------------------------------+------------------------------------ Comment (by thomie): What method did you use to install GHC? Did you download the Haskell Platform, or GHC directly, or some other installer? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 26 18:00:58 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Sep 2015 18:00:58 -0000 Subject: [GHC] #10916: PATH in Windows corrupt after 2nd install og GHC In-Reply-To: <045.d72183e3656d1293df593cae21c559a8@haskell.org> References: <045.d72183e3656d1293df593cae21c559a8@haskell.org> Message-ID: <060.c95b16078a5b389a1fd5aa452f291774@haskell.org> #10916: PATH in Windows corrupt after 2nd install og GHC ---------------------------------+------------------------------------ Reporter: ambusy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: None | Version: 7.10.2 Resolution: | Keywords: installation Operating System: Windows | Architecture: Other Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): ---------------------------------+------------------------------------ Comment (by ambusy): from https://downloads.haskell.org/~platform/7.10.2/HaskellPlatform-7.10.2-a-x86_64-setup.exe and installed it without making any change. Uninstalled from the Control panel of Windows. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 26 18:18:50 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Sep 2015 18:18:50 -0000 Subject: [GHC] #9342: Branchless arithmetic operations In-Reply-To: <042.f67bcd0b7fa4756968d496283e13dc83@haskell.org> References: <042.f67bcd0b7fa4756968d496283e13dc83@haskell.org> Message-ID: <057.64c314f300ea97f7f2a363334587d4cc@haskell.org> #9342: Branchless arithmetic operations -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.8.3 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by strake888): * Attachment "bench.hs" added. benchmark code -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 26 18:22:53 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Sep 2015 18:22:53 -0000 Subject: [GHC] #9342: Branchless arithmetic operations In-Reply-To: <042.f67bcd0b7fa4756968d496283e13dc83@haskell.org> References: <042.f67bcd0b7fa4756968d496283e13dc83@haskell.org> Message-ID: <057.1de597519f3e2ed6d5e506fec510ffd5@haskell.org> #9342: Branchless arithmetic operations -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.8.3 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by strake888): On my AMD FX-8320, branchless `abs` and `sgn` seem speedier but branchless `cmp` seems slower: {{{ $ ./bench 'abs ' benchmarking abs time 37.06 ms (36.60 ms .. 37.56 ms) 1.000 R? (0.999 R? .. 1.000 R?) mean 37.99 ms (37.68 ms .. 38.37 ms) std dev 676.9 ?s (490.1 ?s .. 926.6 ?s) $ ./bench 'abs''' benchmarking abs' time 34.41 ms (33.97 ms .. 34.77 ms) 1.000 R? (0.999 R? .. 1.000 R?) mean 34.08 ms (33.95 ms .. 34.25 ms) std dev 307.3 ?s (243.0 ?s .. 418.2 ?s) $ ./bench 'sgn ' benchmarking sgn time 36.70 ms (36.33 ms .. 37.10 ms) 1.000 R? (0.999 R? .. 1.000 R?) mean 36.93 ms (36.79 ms .. 37.03 ms) std dev 216.7 ?s (127.8 ?s .. 343.1 ?s) $ ./bench 'sgn''' benchmarking sgn' time 34.60 ms (34.24 ms .. 34.92 ms) 1.000 R? (0.999 R? .. 1.000 R?) mean 34.18 ms (34.02 ms .. 34.36 ms) std dev 348.1 ?s (263.4 ?s .. 461.5 ?s) $ ./bench 'cmp ' benchmarking cmp time 35.80 ms (35.04 ms .. 36.80 ms) 0.998 R? (0.996 R? .. 0.999 R?) mean 36.79 ms (36.32 ms .. 37.15 ms) std dev 875.3 ?s (665.6 ?s .. 1.178 ms) $ ./bench 'cmp''' benchmarking cmp' time 36.41 ms (35.72 ms .. 37.08 ms) 0.999 R? (0.998 R? .. 1.000 R?) mean 36.44 ms (35.96 ms .. 36.74 ms) std dev 726.9 ?s (513.8 ?s .. 1.044 ms) $ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 26 19:27:06 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Sep 2015 19:27:06 -0000 Subject: [GHC] #10891: `reify` doesn't find associated type families In-Reply-To: <046.9e704f075dee9514291b5d5766834bf9@haskell.org> References: <046.9e704f075dee9514291b5d5766834bf9@haskell.org> Message-ID: <061.7732f46f8874959a69f80a465d0be578@haskell.org> #10891: `reify` doesn't find associated type families -------------------------------------+------------------------------------- Reporter: antalsz | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: type | families; newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1254 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"b4d43b4e9f4f4fba068ab1e132113c4cd305dfe3/ghc" b4d43b4e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b4d43b4e9f4f4fba068ab1e132113c4cd305dfe3" reify associated types when reifying typeclasses(#10891) As reported in Trac #10891, Template Haskell's `reify` was not generating Decls for associated types. This patch fixes that. Note that even though `reifyTyCon` function used in this patch returns some type instances, I'm ignoring that. Here's an example of how associated types are encoded with this patch: (Simplified representation) class C a where type F a :: * --> OpenTypeFamilyD "F" ["a"] With default type instances: class C a where type F a :: * type F a = a --> OpenTypeFamilyD "F" ["a"] TySynInstD "F" (TySynEqn [VarT "a"] "a") Test Plan: This patch was already reviewed and even merged. The patch is later reverted because apparently it broke the build some time between the validation of this patch and merge. Creating this new ticket to fix the validation. Reviewers: goldfire, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1277 GHC Trac Issues: #10891 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 26 22:33:45 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Sep 2015 22:33:45 -0000 Subject: [GHC] #10365: Implement Semigroup as a superclass of Monoid Proposal (Phase 1) In-Reply-To: <044.91d55a6870e3dd391fca3990f924a9d5@haskell.org> References: <044.91d55a6870e3dd391fca3990f924a9d5@haskell.org> Message-ID: <059.b3d3725bb9cdd8b11457b932e49afb8e@haskell.org> #10365: Implement Semigroup as a superclass of Monoid Proposal (Phase 1) -------------------------------------+------------------------------------- Reporter: gidyn | Owner: Type: feature request | Status: new Priority: high | Milestone: 8.0.1 Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: report-impact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by strake888): * Attachment "0001-add-Semigroup.patch" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 26 22:34:24 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Sep 2015 22:34:24 -0000 Subject: [GHC] #10365: Implement Semigroup as a superclass of Monoid Proposal (Phase 1) In-Reply-To: <044.91d55a6870e3dd391fca3990f924a9d5@haskell.org> References: <044.91d55a6870e3dd391fca3990f924a9d5@haskell.org> Message-ID: <059.0b23bb5c35d352cb5a4b4ff67f154d43@haskell.org> #10365: Implement Semigroup as a superclass of Monoid Proposal (Phase 1) -------------------------------------+------------------------------------- Reporter: gidyn | Owner: strake888 Type: feature request | Status: new Priority: high | Milestone: 8.0.1 Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: report-impact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by strake888): * owner: => strake888 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 27 02:23:18 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Sep 2015 02:23:18 -0000 Subject: [GHC] #10361: DeriveAnyClass does not fill in associated type defaults In-Reply-To: <047.18f32bb2aaf0fd43551e26193c9cadf9@haskell.org> References: <047.18f32bb2aaf0fd43551e26193c9cadf9@haskell.org> Message-ID: <062.aafd5334c952cc284411a6c876e88c32@haskell.org> #10361: DeriveAnyClass does not fill in associated type defaults -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: dreixel Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1283 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * differential: => Phab:D1283 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 27 07:38:19 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Sep 2015 07:38:19 -0000 Subject: [GHC] #10365: Implement Semigroup as a superclass of Monoid Proposal (Phase 1) In-Reply-To: <044.91d55a6870e3dd391fca3990f924a9d5@haskell.org> References: <044.91d55a6870e3dd391fca3990f924a9d5@haskell.org> Message-ID: <059.ae7407a76a9643bcf9dd62fae6c46627@haskell.org> #10365: Implement Semigroup as a superclass of Monoid Proposal (Phase 1) -------------------------------------+------------------------------------- Reporter: gidyn | Owner: strake888 Type: feature request | Status: new Priority: high | Milestone: 8.0.1 Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: report-impact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by hvr): I don't recognize the implementation, is this actually based on the the latest `semigroups` package release? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 27 07:44:37 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Sep 2015 07:44:37 -0000 Subject: [GHC] #10365: Implement Semigroup as a superclass of Monoid Proposal (Phase 1) In-Reply-To: <044.91d55a6870e3dd391fca3990f924a9d5@haskell.org> References: <044.91d55a6870e3dd391fca3990f924a9d5@haskell.org> Message-ID: <059.5f7cb3cfa2d952c8d45aff37360201f6@haskell.org> #10365: Implement Semigroup as a superclass of Monoid Proposal (Phase 1) -------------------------------------+------------------------------------- Reporter: gidyn | Owner: strake888 Type: feature request | Status: patch Priority: high | Milestone: 8.0.1 Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: report-impact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by hvr): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 27 08:04:54 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Sep 2015 08:04:54 -0000 Subject: [GHC] #10365: Implement Semigroup as a superclass of Monoid Proposal (Phase 1) In-Reply-To: <044.91d55a6870e3dd391fca3990f924a9d5@haskell.org> References: <044.91d55a6870e3dd391fca3990f924a9d5@haskell.org> Message-ID: <059.ece3a07ea8454b279b0f66039649efa0@haskell.org> #10365: Implement Semigroup as a superclass of Monoid Proposal (Phase 1) -------------------------------------+------------------------------------- Reporter: gidyn | Owner: strake888 Type: feature request | Status: patch Priority: high | Milestone: 8.0.1 Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: report-impact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by ekmett): I'm not sure what is going on here with this patch. When I last checked we were looking at more or less porting the state of `semigroups` 0.17.0.1 directly into `base`. In fact that eas the reason for the 0.17 release, to get it into a state suitable for direct inclusion with a longer ramp-up period. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 27 09:22:43 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Sep 2015 09:22:43 -0000 Subject: [GHC] #10600: -fwarn-incomplete-patterns doesn't work with -fno-code In-Reply-To: <043.972d3170891da80a4e96bca7b675a836@haskell.org> References: <043.972d3170891da80a4e96bca7b675a836@haskell.org> Message-ID: <058.6e76b61396bd376dcfab4ed24083dc94@haskell.org> #10600: -fwarn-incomplete-patterns doesn't work with -fno-code -------------------------------------+------------------------------------- Reporter: akio | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: driver/T8101b Blocked By: | Blocking: Related Tickets: #8101 | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by bgamari): Either we could explicitly blacklist `GHC.Prim` from desugaring or we could forego Core linting when we aren't going to codegen. Neither option seems terribly great although the first seems a bit more straightforward. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 27 09:57:35 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Sep 2015 09:57:35 -0000 Subject: [GHC] #10916: PATH in Windows corrupt after 2nd install og GHC In-Reply-To: <045.d72183e3656d1293df593cae21c559a8@haskell.org> References: <045.d72183e3656d1293df593cae21c559a8@haskell.org> Message-ID: <060.3b5c17659ead25b0fcdac75397bcac1f@haskell.org> #10916: PATH in Windows corrupt after 2nd install og GHC ---------------------------------+------------------------------------ Reporter: ambusy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: None | Version: 7.10.2 Resolution: | Keywords: installation Operating System: Windows | Architecture: Other Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): ---------------------------------+------------------------------------ Comment (by thomie): Ok. Can you also report this problem to the Haskell Platform issue tracker please: https://github.com/haskell/haskell-platform/issues, and leave a link here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 27 10:12:17 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Sep 2015 10:12:17 -0000 Subject: [GHC] #1883: GHC can't find library using "short" name In-Reply-To: <045.76e5dee1da7bd3e6c3d26431d4641cce@haskell.org> References: <045.76e5dee1da7bd3e6c3d26431d4641cce@haskell.org> Message-ID: <060.a690fc9adf95961f59b4e28e0240a664@haskell.org> #1883: GHC can't find library using "short" name -------------------------------------+------------------------------------- Reporter: m4dc4p | Owner: Phyx- Type: bug | Status: new Priority: lowest | Milestone: 8.0.1 Component: Compiler | Version: 6.6.1 Resolution: | Keywords: link library | windows Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: 3658 | Blocking: Related Tickets: #2283 #3242 | Differential Rev(s): #1883 #7097 | -------------------------------------+------------------------------------- Changes (by Phyx-): * owner: => Phyx- Comment: Assigning this to myself as this will be fixed once the fix for the test in #9907 or Phab:D1244 is pushed. The reason this still doesn't work is that the code that Simon added won't be called in a few cases. This code was added in `Linker.c` which is called from `Linker.hs`. `Linker.hs` itself tries to find the library by just appending ".dll" to the name. Eventually none of the methods will be able to find the DLL and we then the code assumes the `Linker.c` can find it, so it passes the short name to the `addDLL` function. Eventually `addDLL` tries `lib%s.DLL` but this will most of the time fail since `LoadLibrary` won't be able to find it because the `extra-lib-dirs` paths are never used by it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 27 10:16:01 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Sep 2015 10:16:01 -0000 Subject: [GHC] #10365: Implement Semigroup as a superclass of Monoid Proposal (Phase 1) In-Reply-To: <044.91d55a6870e3dd391fca3990f924a9d5@haskell.org> References: <044.91d55a6870e3dd391fca3990f924a9d5@haskell.org> Message-ID: <059.2b04210718e2d00f1087ba7da95c8471@haskell.org> #10365: Implement Semigroup as a superclass of Monoid Proposal (Phase 1) -------------------------------------+------------------------------------- Reporter: gidyn | Owner: hvr Type: feature request | Status: patch Priority: high | Milestone: 8.0.1 Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: report-impact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by hvr): * owner: strake888 => hvr Comment: @strake888, thanks for preparing the patch, but we had already planned out a much more elaborate patch (which I've just completed and published as Phab:D1284). I have to apologize as this was a miscommunication error on our end to remove the owner from this ticket and make it appear as if this task was looking for a volunteer. To be on the safe side in the future, please give a short heads-up notice if you see another task you may be interested in tackling, especially if the task description seems incomplete or still in work-in-progress state (as for this ticket). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 27 10:16:36 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Sep 2015 10:16:36 -0000 Subject: [GHC] #10365: Implement Semigroup as a superclass of Monoid Proposal (Phase 1) In-Reply-To: <044.91d55a6870e3dd391fca3990f924a9d5@haskell.org> References: <044.91d55a6870e3dd391fca3990f924a9d5@haskell.org> Message-ID: <059.53d834f31ce414b06971ed8d048f7060@haskell.org> #10365: Implement Semigroup as a superclass of Monoid Proposal (Phase 1) -------------------------------------+------------------------------------- Reporter: gidyn | Owner: hvr Type: feature request | Status: patch Priority: high | Milestone: 8.0.1 Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: report-impact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1284 -------------------------------------+------------------------------------- Changes (by hvr): * differential: => Phab:D1284 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 27 10:56:45 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Sep 2015 10:56:45 -0000 Subject: [GHC] #10773: Add Control.Monad.IO.Class from transformers to base In-Reply-To: <050.fa78270471b5c8a35c327e5b8e6838d1@haskell.org> References: <050.fa78270471b5c8a35c327e5b8e6838d1@haskell.org> Message-ID: <065.dac9932e1b98faf5c24f8d8bf47c160c@haskell.org> #10773: Add Control.Monad.IO.Class from transformers to base -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: feature request | Status: patch Priority: high | Milestone: 8.0.1 Component: Core Libraries | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1147 -------------------------------------+------------------------------------- Changes (by hvr): * priority: normal => high * owner: => RyanGlScott * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 27 11:01:44 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Sep 2015 11:01:44 -0000 Subject: [GHC] #9079: Foreign.C.Types in haskell2010 In-Reply-To: <046.0c2f3309095eee33947f42c0af9aa93f@haskell.org> References: <046.0c2f3309095eee33947f42c0af9aa93f@haskell.org> Message-ID: <061.0911da8766f80a5db7d870ad80ad40fb@haskell.org> #9079: Foreign.C.Types in haskell2010 -------------------------------------+------------------------------------- Reporter: tensor5 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #PRIME156 | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by hvr): * cc: ekmett (added) * related: => #PRIME156 Comment: See also #PRIME156 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 27 11:18:15 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Sep 2015 11:18:15 -0000 Subject: [GHC] #10726: Upgrade MingW-w64 distributions for windows In-Reply-To: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> References: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> Message-ID: <059.72fdb8fc4ab1f7abd6ec9cc03c86ed43@haskell.org> #10726: Upgrade MingW-w64 distributions for windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: task | Status: merge Priority: normal | Milestone: 7.10.3 Component: Build System | Version: 7.11 Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9218 #9014 | Differential Rev(s): Phab:D1123 #10435 | -------------------------------------+------------------------------------- Comment (by Phyx-): If this is merged back, it's important to merge e415369e91347d23f149a1a750b267da2ee5d74c as well, as that switches the URL to a Haskell.org location from the msys2.org site in this patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 27 12:32:49 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Sep 2015 12:32:49 -0000 Subject: [GHC] #10916: PATH in Windows corrupt after 2nd install og GHC In-Reply-To: <045.d72183e3656d1293df593cae21c559a8@haskell.org> References: <045.d72183e3656d1293df593cae21c559a8@haskell.org> Message-ID: <060.28b6f1bd2049f98d26a84292a03e13b5@haskell.org> #10916: PATH in Windows corrupt after 2nd install og GHC ---------------------------------+------------------------------------ Reporter: ambusy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: None | Version: 7.10.2 Resolution: | Keywords: installation Operating System: Windows | Architecture: Other Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): ---------------------------------+------------------------------------ Comment (by ambusy): transferred to https://github.com/haskell/haskell-platform/issues/219 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 27 13:10:38 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Sep 2015 13:10:38 -0000 Subject: [GHC] #7883: enable GHC LLVM backend to use LLVM provided CAS / Atomicity primitives? In-Reply-To: <045.ccd82245c78d0eab2e30b4e2bcec2782@haskell.org> References: <045.ccd82245c78d0eab2e30b4e2bcec2782@haskell.org> Message-ID: <060.39551c62181dd3670aee987b0a8bcdf1@haskell.org> #7883: enable GHC LLVM backend to use LLVM provided CAS / Atomicity primitives? -------------------------------------+------------------------------------- Reporter: carter | Owner: carter Type: task | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1282 -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D1282 Comment: I have Phab:D1282 up on Phabricator covering this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 27 14:07:33 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Sep 2015 14:07:33 -0000 Subject: [GHC] #10832: Generalize injective type families In-Reply-To: <048.1487f224b00112fe37d31a1812a748a4@haskell.org> References: <048.1487f224b00112fe37d31a1812a748a4@haskell.org> Message-ID: <063.be45874c0f73c6936c2c555d1d40cd8f@haskell.org> #10832: Generalize injective type families -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #6018 | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by jstolarek): For anyone interested, the development of this feature is happening here: https://github.com/jstolarek/ghc/tree/T10832-generalized-injectivity At the moment it just compiles but I hope this implementation becomes usable Real Soon Now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 27 15:55:50 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Sep 2015 15:55:50 -0000 Subject: [GHC] #10914: Bad symbol resolution on Darwin when using DYLD_FORCE_FLAT_NAMESPACE=1 In-Reply-To: <047.9268eb7f03934b85eb39681f4890afc7@haskell.org> References: <047.9268eb7f03934b85eb39681f4890afc7@haskell.org> Message-ID: <062.cacb5a5782dcff153b81306fd07f7d14@haskell.org> #10914: Bad symbol resolution on Darwin when using DYLD_FORCE_FLAT_NAMESPACE=1 -------------------------------------+------------------------------------- Reporter: jacereda | Owner: Type: bug | Status: patch Priority: high | Milestone: Component: Runtime System | Version: 7.10.2 (Linker) | Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by jacereda): * Attachment "0002-Test-failed-to-compile-due-to-use-of-non-standard- he.patch" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 27 16:18:16 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Sep 2015 16:18:16 -0000 Subject: [GHC] #10061: Remove fun_infix from Funbind, as it is now in Match In-Reply-To: <044.5c8cbdfae3d19825dd1ca995401c55be@haskell.org> References: <044.5c8cbdfae3d19825dd1ca995401c55be@haskell.org> Message-ID: <059.21bce476dffd27e29b0fa2912e53dbef@haskell.org> #10061: Remove fun_infix from Funbind, as it is now in Match -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9988 | Differential Rev(s): Phab:D1285 -------------------------------------+------------------------------------- Changes (by alanz): * differential: => Phab:D1285 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 27 16:46:12 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Sep 2015 16:46:12 -0000 Subject: [GHC] #10365: Implement Semigroup as a superclass of Monoid Proposal (Phase 1) In-Reply-To: <044.91d55a6870e3dd391fca3990f924a9d5@haskell.org> References: <044.91d55a6870e3dd391fca3990f924a9d5@haskell.org> Message-ID: <059.076c2ccc84886985e234456dac0c58c5@haskell.org> #10365: Implement Semigroup as a superclass of Monoid Proposal (Phase 1) -------------------------------------+------------------------------------- Reporter: gidyn | Owner: hvr Type: feature request | Status: patch Priority: high | Milestone: 8.0.1 Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: report-impact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1284 -------------------------------------+------------------------------------- Comment (by strake888): Ah, cool. I merely saw this unowned with no patch and panicked cuz I '''seriously''' want this to happen this year. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 27 16:50:37 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Sep 2015 16:50:37 -0000 Subject: [GHC] #10917: Provide a utility to check API Annotations Message-ID: <044.180158552b685611f17d6b8a8773714f@haskell.org> #10917: Provide a utility to check API Annotations -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple ApiAnnotations | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- At the moment it is difficult for GHC developers to know if they have broken the API Annotations. Provide a utility that can be used as a test to show up errors in the API Annotations. This is to be based on the current tests for ghc-api/annotations which can parse a file using the just-built GHC API, and check that no annotations are disconnected from the ParsedSource in the output. In addition, it should be able to dump the annotations to a file, so a new feature developer can check that all changes to the parser do provide annotations. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 28 03:55:09 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Sep 2015 03:55:09 -0000 Subject: [GHC] #10365: Implement Semigroup as a superclass of Monoid Proposal (Phase 1) In-Reply-To: <044.91d55a6870e3dd391fca3990f924a9d5@haskell.org> References: <044.91d55a6870e3dd391fca3990f924a9d5@haskell.org> Message-ID: <059.20ae1bc4a2cabb3d749baaf38b51f10e@haskell.org> #10365: Implement Semigroup as a superclass of Monoid Proposal (Phase 1) -------------------------------------+------------------------------------- Reporter: gidyn | Owner: hvr Type: feature request | Status: patch Priority: high | Milestone: 8.0.1 Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: report-impact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1284 -------------------------------------+------------------------------------- Comment (by ekmett): All good. This served as a forcing function, driving us to flesh out the plan from start to finish and to get something ready for release. =) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 28 07:10:13 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Sep 2015 07:10:13 -0000 Subject: [GHC] #10061: Remove fun_infix from Funbind, as it is now in Match In-Reply-To: <044.5c8cbdfae3d19825dd1ca995401c55be@haskell.org> References: <044.5c8cbdfae3d19825dd1ca995401c55be@haskell.org> Message-ID: <059.93ffd20786c73775d2f45c228a7ef2e1@haskell.org> #10061: Remove fun_infix from Funbind, as it is now in Match -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9988 | Differential Rev(s): Phab:D1285 -------------------------------------+------------------------------------- Changes (by alanz): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 28 07:42:47 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Sep 2015 07:42:47 -0000 Subject: [GHC] #10653: PatternSynonyms should be imported/exported as part of the wildcard notation In-Reply-To: <049.0e5a3c33a167308dc99ecaed5730df14@haskell.org> References: <049.0e5a3c33a167308dc99ecaed5730df14@haskell.org> Message-ID: <064.d377605ac0714c16dc8a29af4d8319c0@haskell.org> #10653: PatternSynonyms should be imported/exported as part of the wildcard notation -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: mpickering Type: feature request | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: | PatternSynonyms, pattern synonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1258 -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > Suppose I have the following two modules. > > {{{#!hs > {-# LANGUAGE PatternSynonyms #-} > module A where > > data A = A2 Int Int > > pattern A1 a <- A2 a _ where > A1 a = A2 a 0 > }}} > {{{#!hs > module B where > > import A ( A(..) ) > > a = A1 0 > }}} > > When I try to compile `B.hs` I get an error because `A1` is unbound in > module `B`. > > {{{ > $ ghc --make B.hs > [1 of 2] Compiling A ( A.hs, A.o ) > [2 of 2] Compiling B ( B.hs, B.o ) > > B.hs:5:5: > Not in scope: data constructor ?A1? > Perhaps you meant ?A2? (imported from A) > }}} > > The issue is that the import `A(..)` brings all of `A`s data constructors > and accessors into scope, but not any associated pattern synonyms. > Instead I have to enable `PatternSynonyms` in module `B` (or just import > everything from `A`). > > {{{#!hs > {-# LANGUAGE PatternSynonyms #-} > module B where > > import A ( A(..), pattern A1 ) > > a = A1 0 > }}} > > I'd like to propose that we extend the semantics of the `A(..)` > import/export notation to include any associated pattern synonyms. I > think this is in line with the spirit of `PatternSynonyms`, that the > extension should allow internal refactoring without causing API breakage, > and that the extension should only need to be enabled to *define* pattern > synonyms. > > FYI, this issue does appear in the wild, I ran into it while working on > https://phabricator.haskell.org/D861 and had to modify two import lists > in Cabal. New description: Suppose I have the following two modules. {{{#!hs {-# LANGUAGE PatternSynonyms #-} module A where data A = A2 Int Int pattern A1 a <- A2 a _ where A1 a = A2 a 0 }}} {{{#!hs module B where import A ( A(..) ) a = A1 0 }}} When I try to compile `B.hs` I get an error because `A1` is unbound in module `B`. {{{ $ ghc --make B.hs [1 of 2] Compiling A ( A.hs, A.o ) [2 of 2] Compiling B ( B.hs, B.o ) B.hs:5:5: Not in scope: data constructor ?A1? Perhaps you meant ?A2? (imported from A) }}} The issue is that the import `A(..)` brings all of `A`s data constructors and accessors into scope, but not any associated pattern synonyms. Instead I have to enable `PatternSynonyms` in module `B` (or just import everything from `A`). {{{#!hs {-# LANGUAGE PatternSynonyms #-} module B where import A ( A(..), pattern A1 ) a = A1 0 }}} I'd like to propose that we extend the semantics of the `A(..)` import/export notation to include any associated pattern synonyms. I think this is in line with the spirit of `PatternSynonyms`, that the extension should allow internal refactoring without causing API breakage, and that the extension should only need to be enabled to *define* pattern synonyms. FYI, this issue does appear in the wild, I ran into it while working on https://phabricator.haskell.org/D861 and had to modify two import lists in Cabal. There is a specification and discussion of this feature on the wiki page [wiki:PatternSynonyms/AssociatingSynonyms]. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 28 07:49:33 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Sep 2015 07:49:33 -0000 Subject: [GHC] #10653: PatternSynonyms should be imported/exported as part of the wildcard notation In-Reply-To: <049.0e5a3c33a167308dc99ecaed5730df14@haskell.org> References: <049.0e5a3c33a167308dc99ecaed5730df14@haskell.org> Message-ID: <064.de45ab97d0a0d8afc084a33ecfef7a23@haskell.org> #10653: PatternSynonyms should be imported/exported as part of the wildcard notation -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: mpickering Type: feature request | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: | PatternSynonyms, pattern synonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1258 -------------------------------------+------------------------------------- Comment (by simonpj): I've added a pointer to the new specification page to the ticket Description. Personally I think we should Keep It Simple. All this talk of satisfiability makes me shiver. I suggest this: allow T( P ) in all situations except where `P`'s type is ''visibly incompatible'' with `T`. What does "visibly incompatible" mean? `P` is visibly incompatible with `T` if * `P`'s type is of form `... -> S t1 t2` * `S` is a data/newtype constructor distinct from `T` Nothing harmful happens if we allow `P` to be exported with a type it can't possibly be useful for, but specifying a tighter relationship is very awkward as you have discovered. BTW, you'd better say that `T( P )` is ''not'' ok if `T` is a type synonym. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 28 08:27:59 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Sep 2015 08:27:59 -0000 Subject: [GHC] #10844: CallStack should not be inlined In-Reply-To: <046.c5d6c4205be9804afd3acc1b71ee4c7b@haskell.org> References: <046.c5d6c4205be9804afd3acc1b71ee4c7b@haskell.org> Message-ID: <061.10881be6ab64fb53b2d17aa1c7c26664@haskell.org> #10844: CallStack should not be inlined -------------------------------------+------------------------------------- Reporter: nomeata | Owner: gridaphobe Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1259 -------------------------------------+------------------------------------- Comment (by simonpj): Eric, I'm very suspicious of this. Making the desugarer more complicated to fix a single instance of what is presumably a generic shortcoming in the float-out machinery, seems entirely wrong to me. So you fix `CallStacks`, but what about other instances of the same problem? I would far rather characterise the problem more carefully and fix it at source. It's possible that it is Truly Hard to do that, in which case a more ad-hoc fix would be justifiable; but then it would need a careful Note to explain why it could not be done generically. Could you instead characterise the problem? You don't need to use call- stacks; just write source code that generates the same pattern and lets look at it. Thanks! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 28 08:30:35 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Sep 2015 08:30:35 -0000 Subject: [GHC] #10483: Refactor HsForAllTy In-Reply-To: <046.9d853f4d4b58831f7571afd11de45120@haskell.org> References: <046.9d853f4d4b58831f7571afd11de45120@haskell.org> Message-ID: <061.05843d988bd0fdbfc00f99657ad7fd59@haskell.org> #10483: Refactor HsForAllTy -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D953 -------------------------------------+------------------------------------- Comment (by simonpj): Please don't look at this any more! I've been working on an alternative. Very sorry, should have mentioned this. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 28 09:18:55 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Sep 2015 09:18:55 -0000 Subject: [GHC] #10832: Generalize injective type families In-Reply-To: <048.1487f224b00112fe37d31a1812a748a4@haskell.org> References: <048.1487f224b00112fe37d31a1812a748a4@haskell.org> Message-ID: <063.bd23396558ea4efcdda7feeb0f4088fc@haskell.org> #10832: Generalize injective type families -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #6018 | Differential Rev(s): D1287 -------------------------------------+------------------------------------- Changes (by jstolarek): * differential: => D1287 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 28 11:02:43 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Sep 2015 11:02:43 -0000 Subject: [GHC] #10832: Generalize injective type families In-Reply-To: <048.1487f224b00112fe37d31a1812a748a4@haskell.org> References: <048.1487f224b00112fe37d31a1812a748a4@haskell.org> Message-ID: <063.c6beabde469c34f3fe7430235276a2bb@haskell.org> #10832: Generalize injective type families -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #6018 | Differential Rev(s): Phab:D1287 -------------------------------------+------------------------------------- Changes (by jstolarek): * differential: D1287 => Phab:D1287 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 28 11:44:24 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Sep 2015 11:44:24 -0000 Subject: [GHC] #10918: Float once-used let binding into a recursive function Message-ID: <046.57a8bfaf928dc1d6c0d53688bcdd3dbd@haskell.org> #10918: Float once-used let binding into a recursive function -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- Consider this code {{{#!hs let x = f x0 in let go 10 = x go i = go (i+1) in go (0::Int) }}} Currently, this is pretty much the core that comes out at the end. But what we want to see instead is {{{#!hs let go 10 = let x = f x 0 in x go i = go (i+1) in go (0::Int) }}} In general, we do not want to float a binding into a recursive function, because we would risk doing the allocation and/or evaluation of it multiple times. But in this case, we can see that it is going to be used at most once, so it is safe to do so. Even more: In the slightly less contrived examples that I was looking at, the call to `x` was happening in the a less likely code path, so this way we?d avoid doing the allocation in most cases, a clear win. It might be enough to simply make `CallArity` (or rather the cardinality analysis done by call arity) tell the rest of the compiler that it found that `x` is called at most once, and hopefully the simplifier knows what to make of that information. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 28 12:13:59 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Sep 2015 12:13:59 -0000 Subject: [GHC] #9342: Branchless arithmetic operations In-Reply-To: <042.f67bcd0b7fa4756968d496283e13dc83@haskell.org> References: <042.f67bcd0b7fa4756968d496283e13dc83@haskell.org> Message-ID: <057.0524e648ed7ea241ffc2903089be7049@haskell.org> #9342: Branchless arithmetic operations -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.8.3 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by svenpanne): I'd like to point out my previous email on a similar topic: https://mail.haskell.org/pipermail/ghc-devs/2015-April/008858.html In a nutshell: It's far from clear that code with branches is "sub- optimal", toy benchmarks are totally meaningless (they don't stress e.g. the very limited number of shifting units in CPUs), and benchmarks on a single (micro-)architecture are even less meaningful (what's good for one HW makes things worse on another HW). Applying rules of thumb from previous decades doesn't really work anymore today, this has already been learned the hard way in several other compilers/JITs, I just wanted to warn about this again... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 28 12:20:18 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Sep 2015 12:20:18 -0000 Subject: [GHC] #9342: Branchless arithmetic operations In-Reply-To: <042.f67bcd0b7fa4756968d496283e13dc83@haskell.org> References: <042.f67bcd0b7fa4756968d496283e13dc83@haskell.org> Message-ID: <057.e8b75e489d7036d5163654411b6e7a34@haskell.org> #9342: Branchless arithmetic operations -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.8.3 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by tibbe): As a data point the hashtables package makes effective use of branchless code in practice: https://github.com/gregorycollins/hashtables/search?utf8=%E2%9C%93&q=branchless -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 28 12:45:59 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Sep 2015 12:45:59 -0000 Subject: [GHC] #10918: Float once-used let binding into a recursive function In-Reply-To: <046.57a8bfaf928dc1d6c0d53688bcdd3dbd@haskell.org> References: <046.57a8bfaf928dc1d6c0d53688bcdd3dbd@haskell.org> Message-ID: <061.2ea428dc152b82b1be659743a2459100@haskell.org> #10918: Float once-used let binding into a recursive function -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by nomeata): Looking at the code, maybe this is a viable course of action: In `FloatIn`, in the equation of `fiExpr` for recursive bindings, where `extra_fvs` are calculated, exclude any variables that are free variables of a right-hand-side of the binding if they have a Dmd signature that indicates that they are used at most once. This allows them to float inside the `let` Then we still need to ensure that they pass past the lambda. So the lambda case of `fiExpr` needs to be improved to separate the used-once floats from the others and float only those in. I?m not sure if the float in pass is the right place to do this, though. Shouldn?t the simplifier be able to do these things? So maybe `simplRecBind` should not zap all floats, but rather distinguish between those that may float into a recursive group and the others? This needs advise from one of the experts on the simplifier. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 28 15:18:38 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Sep 2015 15:18:38 -0000 Subject: [GHC] #10842: "Reactive" Template Haskell In-Reply-To: <050.6f7bb562017372f9e5bba0241a40c1a7@haskell.org> References: <050.6f7bb562017372f9e5bba0241a40c1a7@haskell.org> Message-ID: <065.16aa019ac741db8ddff39beb717b5e8e@haskell.org> #10842: "Reactive" Template Haskell -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9699, #10391 | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by kanetw): This does sound interesting! If you can flesh out the spec, I'll take a closer look at this. Extending the compiler plugin interface seems more appropriate considering how invasive this could be. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 28 16:03:11 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Sep 2015 16:03:11 -0000 Subject: [GHC] #10916: PATH in Windows corrupt after 2nd install og GHC In-Reply-To: <045.d72183e3656d1293df593cae21c559a8@haskell.org> References: <045.d72183e3656d1293df593cae21c559a8@haskell.org> Message-ID: <060.e15db55e767035b16b0ae86c69dccfc9@haskell.org> #10916: PATH in Windows corrupt after 2nd install og GHC ---------------------------------+------------------------------------ Reporter: ambusy | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: None | Version: 7.10.2 Resolution: duplicate | Keywords: installation Operating System: Windows | Architecture: Other Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): ---------------------------------+------------------------------------ Changes (by thomie): * status: new => closed * resolution: => duplicate Comment: Thanks. Let's close this one then. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 28 16:04:19 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Sep 2015 16:04:19 -0000 Subject: [GHC] #10891: `reify` doesn't find associated type families In-Reply-To: <046.9e704f075dee9514291b5d5766834bf9@haskell.org> References: <046.9e704f075dee9514291b5d5766834bf9@haskell.org> Message-ID: <061.bbfbdf1bec5488b04d69486477b665f8@haskell.org> #10891: `reify` doesn't find associated type families -------------------------------------+------------------------------------- Reporter: antalsz | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: type | families; newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1254 -------------------------------------+------------------------------------- Comment (by thomie): Should this be merged to 7.10? Or can this ticket be closed? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 28 16:06:19 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Sep 2015 16:06:19 -0000 Subject: [GHC] #10869: Option to dump preprocessed source In-Reply-To: <046.34bba2c2c1e4ccec0498d1f1e04c25f9@haskell.org> References: <046.34bba2c2c1e4ccec0498d1f1e04c25f9@haskell.org> Message-ID: <061.5320d7ac25bfccfadf283bfff494efcc@haskell.org> #10869: Option to dump preprocessed source -------------------------------------+------------------------------------- Reporter: phischu | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Driver | Version: 7.10.2 Resolution: | Keywords: easy Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by thomie): * status: closed => new * resolution: invalid => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 28 16:13:57 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Sep 2015 16:13:57 -0000 Subject: [GHC] #9342: Branchless arithmetic operations In-Reply-To: <042.f67bcd0b7fa4756968d496283e13dc83@haskell.org> References: <042.f67bcd0b7fa4756968d496283e13dc83@haskell.org> Message-ID: <057.9062f37144020c49993d208fcc435931@haskell.org> #9342: Branchless arithmetic operations -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.8.3 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by svenpanne): Re #7: Do we have real-world benchmarks for Atom/i3/i7/Xeon in ia32/x64 modes? ARM? ARM64? With and without branches? Without that, it's unclear if that's "effective use". My point (again) is: Being branchless in itself is a non-goal. Picking e.g. just https://github.com/gregorycollins/hashtables/blob/9e477b825a98e4f574a0e889e5c7955a1015a430/src/Data/HashTable/Internal/CacheLine.hs#L165 : This is a perfect example which will probably make things *slower*, depending on the availability of spare registers. It uses a handful of intermediate values, while the branching code uses none, and a single spill caused by the higher register pressure will be much, much more costly than anything else, especially ia32 sucks here. Furthermore, if surrounding code uses shifts and/or complicated addressing modes a lot, one will have to wait for the shifting unit to become available. This is all not theoretical, we had to revert to the straightforward code with branches in Chrome's V8 JavaScript JIT on some platforms/CPUs in similar places. Perhaps the code patterns in GHC-generated code are different, but the only way to know is to do benchmarking on wide variety of benchmarks and CPUs. Yes, that's a lot of work and needs some infrastructure, but without that, changes like this are just a shot in the dark. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 28 16:14:03 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Sep 2015 16:14:03 -0000 Subject: [GHC] #10914: Bad symbol resolution on Darwin when using DYLD_FORCE_FLAT_NAMESPACE=1 In-Reply-To: <047.9268eb7f03934b85eb39681f4890afc7@haskell.org> References: <047.9268eb7f03934b85eb39681f4890afc7@haskell.org> Message-ID: <062.fb0b21654158761008c8852b71d5b336@haskell.org> #10914: Bad symbol resolution on Darwin when using DYLD_FORCE_FLAT_NAMESPACE=1 -------------------------------------+------------------------------------- Reporter: jacereda | Owner: Type: bug | Status: patch Priority: high | Milestone: Component: Runtime System | Version: 7.10.2 (Linker) | Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by thomie): Thanks for the patch. Please note: * Patches should be made relative to ghc HEAD (master). * Your first patch doesn't have a test. See https://ghc.haskell.org/trac/ghc/wiki/Building/RunningTests/Adding * Your second patch isn't needed for ghc HEAD, see #10211. * Patches are preferably sent to [wiki:Phabricator]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 28 19:25:24 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Sep 2015 19:25:24 -0000 Subject: [GHC] #10913: deprecate and then remove -fwarn-hi-shadowing In-Reply-To: <043.5271c7f4effd317ccfe2016268f0bde8@haskell.org> References: <043.5271c7f4effd317ccfe2016268f0bde8@haskell.org> Message-ID: <058.7f818a608fbfa851e2b58ea8cecd7228@haskell.org> #10913: deprecate and then remove -fwarn-hi-shadowing -------------------------------------+------------------------------------- Reporter: osa1 | Owner: ChrisU Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by ChrisU): * owner: => ChrisU Comment: The deprecate message will be a generic "does not work, will be taken out soon" message, because I don't know ''why'' it hasn't been used since 2006. (I.e. is the behavior subsumed, always done?, no longer implemented? Not implementable?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 28 20:22:05 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Sep 2015 20:22:05 -0000 Subject: [GHC] #9342: Branchless arithmetic operations In-Reply-To: <042.f67bcd0b7fa4756968d496283e13dc83@haskell.org> References: <042.f67bcd0b7fa4756968d496283e13dc83@haskell.org> Message-ID: <057.7f674da2809ff9e98f3fffb5d93fffe8@haskell.org> #9342: Branchless arithmetic operations -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.8.3 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by tibbe): * cc: greg@? (added) Comment: I'm sure Greg measured. I've CCed him. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 28 20:42:30 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Sep 2015 20:42:30 -0000 Subject: [GHC] #10913: deprecate and then remove -fwarn-hi-shadowing In-Reply-To: <043.5271c7f4effd317ccfe2016268f0bde8@haskell.org> References: <043.5271c7f4effd317ccfe2016268f0bde8@haskell.org> Message-ID: <058.a4ab92c3d12fafaab865182858b2a28a@haskell.org> #10913: deprecate and then remove -fwarn-hi-shadowing -------------------------------------+------------------------------------- Reporter: osa1 | Owner: ChrisU Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by ChrisU): This maybe shouldn't be deprecated as we can actually get a situation where such a warning would be useful. Its a bit pathological in nature, which might be why this has been left nonworking for 15 years. {{{ ~/test$ ghc --make Test -ia -ib -fforce-recomp -fwarn-hi-shadowing [1 of 2] Compiling B ( a/B.hs, a/B.o ) [2 of 2] Compiling Main ( Test.hs, Test.o ) Linking Test ... ~/test$ find . . ./b ./b/B.hi ./b/B.hs ./b/B.o ./Test.hi ./Test.hs ./Test ./Test.o ./a ./a/B.hi ./a/B.hs ./a/B.o ~/test$ ./Test a ~/test$ cat b/B.hs module B where main' = putStrLn "b" ~/test$ cat a/B.hs module B where main' = putStrLn "a" }}} A warning that b/B.hi is getting ignored would be useful. On the other hand if this turned up too often, we would have gotten complaints/requests over the last 15 years. (It was removed between 4.02 and 5.0, presumably because hierarchical modules made shadowed .hi files much rarer and harder to test for.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 28 20:48:59 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Sep 2015 20:48:59 -0000 Subject: [GHC] #9342: Branchless arithmetic operations In-Reply-To: <042.f67bcd0b7fa4756968d496283e13dc83@haskell.org> References: <042.f67bcd0b7fa4756968d496283e13dc83@haskell.org> Message-ID: <057.3e9a329f2b00e59324d15109dd19bbdb@haskell.org> #9342: Branchless arithmetic operations -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.8.3 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by gregorycollins): I measured, yes, but not across processors: when I was working on this I optimized for 64-bit i7 (probably Sandy Bridge IIRC). The version of mask you linked to with the funky branchless code was definitively faster on that chip vs. the simpler alternative: {{{ mask# :: Int# -> Int# -> Int# mask# !a# !b# = let !(I# z#) = fromEnum (a# ==# b#) !q# = negateInt# z# in q# }}} (of course this is from when `==#` returned `Bool` rather than `Int#`). The difference was about 15-20% IIRC. Unfortunately I've lost the raw numbers, sorry, but as Sven points out they'd be useless anyways towards determining how good the change is in aggregate. Quite willing to believe that code could be a pessimization on ia32. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 28 21:57:36 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Sep 2015 21:57:36 -0000 Subject: [GHC] #9173: Better type error messages In-Reply-To: <046.f8f24aa2ddaa3d579bc40f0b6f04f6b7@haskell.org> References: <046.f8f24aa2ddaa3d579bc40f0b6f04f6b7@haskell.org> Message-ID: <061.f9d2c5c1ba5674327dbdde8f4bc8415c@haskell.org> #9173: Better type error messages -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by chreekat): {{{ Foo.hs:4:7: Couldn't match expected type ?Int? with actual type ?[Char]? In the expression: "Howdy!" In an equation for ?foo?: foo = "Howdy!" }}} This example reminded me that sometimes the phrase "In the expression" is confusing to me. It seems that the phrase *should* be "Of the expression". Using 'in' makes me expect that the error message is referring to some particular component of the expression, rather than the whole thing. It's a small incongruence, but it's big enough to force me to stop thinking about code and start thinking about the possible meanings of the error message. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 28 22:04:58 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Sep 2015 22:04:58 -0000 Subject: [GHC] #9173: Better type error messages In-Reply-To: <046.f8f24aa2ddaa3d579bc40f0b6f04f6b7@haskell.org> References: <046.f8f24aa2ddaa3d579bc40f0b6f04f6b7@haskell.org> Message-ID: <061.4c7672406b8b138e91aefff44544b03d@haskell.org> #9173: Better type error messages -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by chreekat): Replying to [comment:12 simonpj]: > > Switching the order as Reid suggests in comment:11 would be easy, and I can see that it might help. Do others like that? > > I'd also be ok with saying "type expected by the context" instead of just "expected". That longer phrase would also suggest putting it second. +1. E.g.: {{{ foo.hs:1:11: Couldn't match actual type ?Char? with type expected by context, ?Bool? In the first argument of ?not?, namely ?'c'? In the expression: not 'c' In an equation for ?foo?: foo = not 'c' }}} (I recall now that "In the expression" is used because the message often *does* refer to a component of the whole expression. Still, I think it would be nice if it switched to "In the expression" when referring to the whole thing.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 29 01:26:39 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Sep 2015 01:26:39 -0000 Subject: [GHC] #10029: ARM: internal error: evacuate(static): strange closure type 62744 In-Reply-To: <050.3e189618a175273ea644d5072d51372c@haskell.org> References: <050.3e189618a175273ea644d5072d51372c@haskell.org> Message-ID: <065.47f7d61ad8716bc385af48bf10c3a3ff@haskell.org> #10029: ARM: internal error: evacuate(static): strange closure type 62744 ---------------------------------------+----------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Compile-time crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): ---------------------------------------+----------------------------- Changes (by erikd): * cc: erikd (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 29 01:50:48 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Sep 2015 01:50:48 -0000 Subject: [GHC] #10029: ARM: internal error: evacuate(static): strange closure type 62744 In-Reply-To: <050.3e189618a175273ea644d5072d51372c@haskell.org> References: <050.3e189618a175273ea644d5072d51372c@haskell.org> Message-ID: <065.56fede452b3dfc047bbd471f37d621bf@haskell.org> #10029: ARM: internal error: evacuate(static): strange closure type 62744 ---------------------------------------+----------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Compile-time crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): ---------------------------------------+----------------------------- Comment (by juhpetersen): highlighting-kate and leksah-server tests also fail. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 29 09:59:12 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Sep 2015 09:59:12 -0000 Subject: [GHC] #10875: Unexpected defaulting of partial type signatures and inconsistent behaviour when -fdefer-typed-holes is set. In-Reply-To: <047.47e931d5fc4e6515630dc5cf2498378f@haskell.org> References: <047.47e931d5fc4e6515630dc5cf2498378f@haskell.org> Message-ID: <062.f0a0c2aa37118511f678d6ebe5666862@haskell.org> #10875: Unexpected defaulting of partial type signatures and inconsistent behaviour when -fdefer-typed-holes is set. -------------------------------------+------------------------------------- Reporter: holzensp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | PartialTypeSignatures TypedHoles Operating System: MacOS X | Architecture: x86_64 Type of failure: Incorrect | (amd64) warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by holzensp): I found another interesting bit of behaviour, which I would argue is an error. Consider this program: {{{#!hs {-# LANGUAGE NoMonomorphismRestriction #-} {-# LANGUAGE PartialTypeSignatures #-} {-# LANGUAGE NamedWildCards #-} {-# LANGUAGE ImplicitParams #-} module Foo where foo :: _ => _outer foo = (+) ?a ?b ?c ?d }}} This produces the following output in GHCi: {{{ [1 of 1] Compiling Foo ( Foo.hs, interpreted ) Foo.hs:7:8: Warning: Found hole ?_? with inferred constraints: (Num (t -> t -> w_outer), ?a::t -> t -> w_outer, ?b::t -> t -> w_outer, ?c::t, ?d::t) In the type signature for ?foo?: _ => _outer Foo.hs:7:13: Warning: Found hole ?_outer? with type: w_outer Where: ?w_outer? is a rigid type variable bound by the inferred type of foo :: (Num (t -> t1 -> w_outer), ?a::t -> t1 -> w_outer, ?b::t -> t1 -> w_outer, ?c::t, ?d::t1) => w_outer at Foo.hs:8:1 In the type signature for ?foo?: _ => _outer Ok, modules loaded: Foo. }}} I would say the second warning is accurate, but in the first warning, the `t1` type variables are printed as `t`, which is too restrictive. Considering the validity of the second warning, I would say this is probably a ppr-bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 29 13:50:00 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Sep 2015 13:50:00 -0000 Subject: [GHC] #10919: ghc: panic! (the 'impossible' happened) ... Dynamic linker not initialised Message-ID: <054.0b98f2d3ec398afce2ee51103df99d47@haskell.org> #10919: ghc: panic! (the 'impossible' happened) ... Dynamic linker not initialised -------------------------------------+------------------------------------- Reporter: recursion- | Owner: ninja | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: panic | Operating System: Linux impossible linker initialized | Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- When trying to build the CUDA accelerate backend I get the following "complier panic": {{{ me at box:~/accelerate-cuda-0.15.0.0$ cabal build Building accelerate-cuda-0.15.0.0... Preprocessing library accelerate-cuda-0.15.0.0... Data/Array/Accelerate/CUDA/CodeGen/Base.hs:5:14: Warning: -XOverlappingInstances is deprecated: instead use per-instance pragmas OVERLAPPING/OVERLAPPABLE/OVERLAPS [ 7 of 33] Compiling Data.Array.Accelerate.CUDA.CodeGen.Type ( Data/Array/Accelerate/CUDA/CodeGen/Type.hs, dist/build/Data/Array/Accelerate/CUDA/CodeGen/Type.o ) : ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-linux): Dynamic linker not initialised Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug [ 9 of 33] Compiling Data.Array.Accelerate.CUDA.Debug ( Data/Array/Accelerate/CUDA/Debug.hs, dist/build/Data/Array/Accelerate/CUDA/Debug.o ) : ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-linux): Dynamic linker not initialised Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug [10 of 33] Compiling Data.Array.Accelerate.CUDA.Analysis.Launch ( Data/Array/Accelerate/CUDA/Analysis/Launch.hs, dist/build/Data/Array/Accelerate/CUDA/Analysis/Launch.o ) : : can't load .so/.DLL for: /home/me/.cabal/lib/x86_64 -linux-ghc-7.10.2/cuda-0.6.7.0-EMlxEWvymgZGXnLSaVKypt/libHScuda-0.6.7.0 -EMlxEWvymgZGXnLSaVKypt-ghc7.10.2.so (libcudart.so.7.5: cannot open shared object file: No such file or directory) }}} This is the accelerate cuda package version 0.15.0.0: https://hackage.haskell.org/package/accelerate-cuda I changed the constraints from base==4.7.* to base==4.8.* to allow for compilation with GHC 7.10.2. After installing the dependencies through cabal and attempting to manually build the package manuall with cabal build I get the above mentioned compiler panics. GHC instructed me to report the issue as a bug (defect) so I did. I'd like to get this library to build with the newest version of GHC so please let me know how to proceed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 29 14:00:45 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Sep 2015 14:00:45 -0000 Subject: [GHC] #10891: `reify` doesn't find associated type families In-Reply-To: <046.9e704f075dee9514291b5d5766834bf9@haskell.org> References: <046.9e704f075dee9514291b5d5766834bf9@haskell.org> Message-ID: <061.26c80aae59a43341142d30cf9144cdc2@haskell.org> #10891: `reify` doesn't find associated type families -------------------------------------+------------------------------------- Reporter: antalsz | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: type | families; newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1254 -------------------------------------+------------------------------------- Comment (by goldfire): I argue against merging, as it changes an external interface. My TH code dislikes new, unexpected things being reported. :) If you (whoever reads this next) agree, close the ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 29 14:07:44 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Sep 2015 14:07:44 -0000 Subject: [GHC] #10568: Regression from 7.8.4, loading GLUT into GHCI fails on the Mac In-Reply-To: <045.16a6419c70e069ea547a1b942e636370@haskell.org> References: <045.16a6419c70e069ea547a1b942e636370@haskell.org> Message-ID: <060.c4025cf2298eb07d4616d7bb16f4a37d@haskell.org> #10568: Regression from 7.8.4, loading GLUT into GHCI fails on the Mac -------------------------------------+------------------------------------- Reporter: George | Owner: darchon Type: bug | Status: merge Priority: normal | Milestone: 7.10.3 Component: Runtime System | Version: 7.10.2-rc1 (Linker) | Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 | (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1115 -------------------------------------+------------------------------------- Changes (by simonmar): * component: Compiler => Runtime System (Linker) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 29 14:24:29 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Sep 2015 14:24:29 -0000 Subject: [GHC] #10891: `reify` doesn't find associated type families In-Reply-To: <046.9e704f075dee9514291b5d5766834bf9@haskell.org> References: <046.9e704f075dee9514291b5d5766834bf9@haskell.org> Message-ID: <061.8ef371319f422f4940c5c48d0e073021@haskell.org> #10891: `reify` doesn't find associated type families -------------------------------------+------------------------------------- Reporter: antalsz | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.2 Resolution: fixed | Keywords: type | families; newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1254 -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 29 14:44:07 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Sep 2015 14:44:07 -0000 Subject: [GHC] #10919: ghc: panic! (the 'impossible' happened) ... Dynamic linker not initialised In-Reply-To: <054.0b98f2d3ec398afce2ee51103df99d47@haskell.org> References: <054.0b98f2d3ec398afce2ee51103df99d47@haskell.org> Message-ID: <069.a5a8916dd969ade5b363b4c663032af4@haskell.org> #10919: ghc: panic! (the 'impossible' happened) ... Dynamic linker not initialised -------------------------------------+------------------------------------- Reporter: recursion-ninja | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: panic | impossible linker initialized Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by recursion-ninja): * architecture: Unknown/Multiple => x86_64 (amd64) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 29 14:45:00 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Sep 2015 14:45:00 -0000 Subject: [GHC] #10455: No detail for profiling costs atributed to SYSTEM / PINNED / ARR_WORDS In-Reply-To: <045.a9028fd77ac5d315b33e56f253825d09@haskell.org> References: <045.a9028fd77ac5d315b33e56f253825d09@haskell.org> Message-ID: <060.133925e56086d140e170809a7c7fa8c7@haskell.org> #10455: No detail for profiling costs atributed to SYSTEM / PINNED / ARR_WORDS -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Profiling | Version: 7.10.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #7275 | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => duplicate * related: => #7275 Comment: This is a duplicate of #7275. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 29 14:54:12 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Sep 2015 14:54:12 -0000 Subject: [GHC] #10600: -fwarn-incomplete-patterns doesn't work with -fno-code In-Reply-To: <043.972d3170891da80a4e96bca7b675a836@haskell.org> References: <043.972d3170891da80a4e96bca7b675a836@haskell.org> Message-ID: <058.37adfcbca52ab573e9bf0564c2df7ad9@haskell.org> #10600: -fwarn-incomplete-patterns doesn't work with -fno-code -------------------------------------+------------------------------------- Reporter: akio | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: driver/T8101b Blocked By: | Blocking: Related Tickets: #8101 | Differential Rev(s): Phab:D1278 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * differential: => Phab:D1278 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 29 14:55:05 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Sep 2015 14:55:05 -0000 Subject: [GHC] #10600: -fwarn-incomplete-patterns doesn't work with -fno-code In-Reply-To: <043.972d3170891da80a4e96bca7b675a836@haskell.org> References: <043.972d3170891da80a4e96bca7b675a836@haskell.org> Message-ID: <058.601ed8d686f19c4a6b1acba06d319c4e@haskell.org> #10600: -fwarn-incomplete-patterns doesn't work with -fno-code -------------------------------------+------------------------------------- Reporter: akio | Owner: ezyang Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: driver/T8101b Blocked By: | Blocking: Related Tickets: #8101 | Differential Rev(s): Phab:D1278 -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch Old description: > `-fwarn-incomplete-patterns` doensn't seem to generate any warnings when > `-fno-code` is specified. > > To reproduce, save this module as `foo.hs`. > > {{{#!hs > module Foo where > foo True = 4 > }}} > > and compile with `-fwarn-incomplete-patterns`, with and without `-fno- > code`. > > {{{ > % ghc -fwarn-incomplete-patterns -fforce-recomp foo.hs > [1 of 1] Compiling Foo ( foo.hs, foo.o ) > > foo.hs:2:1: Warning: > Pattern match(es) are non-exhaustive > In an equation for ?foo?: Patterns not matched: False > % ghc -fwarn-incomplete-patterns -fforce-recomp -fno-code foo.hs > [1 of 1] Compiling Foo ( foo.hs, nothing ) > % > }}} New description: `-fwarn-incomplete-patterns` doesn't seem to generate any warnings when `-fno-code` is specified. To reproduce, save this module as `foo.hs`. {{{#!hs module Foo where foo True = 4 }}} and compile with `-fwarn-incomplete-patterns`, with and without `-fno- code`. {{{ % ghc -fwarn-incomplete-patterns -fforce-recomp foo.hs [1 of 1] Compiling Foo ( foo.hs, foo.o ) foo.hs:2:1: Warning: Pattern match(es) are non-exhaustive In an equation for ?foo?: Patterns not matched: False % ghc -fwarn-incomplete-patterns -fforce-recomp -fno-code foo.hs [1 of 1] Compiling Foo ( foo.hs, nothing ) % }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 29 15:37:28 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Sep 2015 15:37:28 -0000 Subject: [GHC] #10918: Float once-used let binding into a recursive function In-Reply-To: <046.57a8bfaf928dc1d6c0d53688bcdd3dbd@haskell.org> References: <046.57a8bfaf928dc1d6c0d53688bcdd3dbd@haskell.org> Message-ID: <061.de899971c63049f92a301ce82502796e@haskell.org> #10918: Float once-used let binding into a recursive function -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by simonpj): I think float-in is the right place. The simplifier does only strictly- local floating; and only float out. Really the only floating transformation the simplifier does is {{{ let x = let y = e in (e1:e2) in ... ===> let y = e in let x = e1:e2 in ... }}} So yes: float-in! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 29 15:48:41 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Sep 2015 15:48:41 -0000 Subject: [GHC] #7275: Give more detailed information about PINNED data in a heap profile In-Reply-To: <044.d45534e5aeae0f0c324c2676fe16cc7e@haskell.org> References: <044.d45534e5aeae0f0c324c2676fe16cc7e@haskell.org> Message-ID: <059.23f400003bf5c5ea6e9dee9061f8d02e@haskell.org> #7275: Give more detailed information about PINNED data in a heap profile -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Profiling | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by thomie): * component: Compiler => Profiling Comment: Also reported as #10455. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 29 15:51:41 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Sep 2015 15:51:41 -0000 Subject: [GHC] #10600: -fwarn-incomplete-patterns doesn't work with -fno-code In-Reply-To: <043.972d3170891da80a4e96bca7b675a836@haskell.org> References: <043.972d3170891da80a4e96bca7b675a836@haskell.org> Message-ID: <058.c3c94d3f765f7847a8649ea5fd3b44fd@haskell.org> #10600: -fwarn-incomplete-patterns doesn't work with -fno-code -------------------------------------+------------------------------------- Reporter: akio | Owner: ezyang Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: driver/T8101b Blocked By: | Blocking: Related Tickets: #8101 | Differential Rev(s): Phab:D1278 -------------------------------------+------------------------------------- Comment (by bgamari): We discussed this during the weekly meeting; no one was terribly excited about any of the alternatives, * Fix `GHC.Prim` to pass Core Lint (perhaps not even possible) * Add a special case to skip desugaring for `GHC.Prim` * Add a special case to skip Core Linting `GHC.Prim` * Disable Core Linting when not generating code * Add a command line option to specifically disable desugaring (which could be used by Haddock) The point also came up that we should really try to avoid desugaring when invoked by Haddock as this is otherwise wasted effort. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 29 15:54:08 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Sep 2015 15:54:08 -0000 Subject: [GHC] #7275: Give more detailed information about PINNED data in a heap profile In-Reply-To: <044.d45534e5aeae0f0c324c2676fe16cc7e@haskell.org> References: <044.d45534e5aeae0f0c324c2676fe16cc7e@haskell.org> Message-ID: <059.94b661f941be501d493d66631b2ee479@haskell.org> #7275: Give more detailed information about PINNED data in a heap profile -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by bgamari): * component: Profiling => Compiler Comment: We discussed this during this week's GHC meeting. Simon Marlow confirmed that Ian's suggestion would likely be feasible given a few days of effort. There is, however, the possibility that we would need to be more careful about zeroing out slots that we might accidentally dereference. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 29 15:54:24 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Sep 2015 15:54:24 -0000 Subject: [GHC] #7275: Give more detailed information about PINNED data in a heap profile In-Reply-To: <044.d45534e5aeae0f0c324c2676fe16cc7e@haskell.org> References: <044.d45534e5aeae0f0c324c2676fe16cc7e@haskell.org> Message-ID: <059.a38ebadac6226626fc263c49a2b76a3a@haskell.org> #7275: Give more detailed information about PINNED data in a heap profile -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Profiling | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by bgamari): * component: Compiler => Profiling -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 29 16:34:13 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Sep 2015 16:34:13 -0000 Subject: [GHC] #10568: Regression from 7.8.4, loading GLUT into GHCI fails on the Mac In-Reply-To: <045.16a6419c70e069ea547a1b942e636370@haskell.org> References: <045.16a6419c70e069ea547a1b942e636370@haskell.org> Message-ID: <060.303cb94b791b5c20dcebeea80b30bf25@haskell.org> #10568: Regression from 7.8.4, loading GLUT into GHCI fails on the Mac -------------------------------------+------------------------------------- Reporter: George | Owner: darchon Type: bug | Status: closed Priority: normal | Milestone: 7.10.3 Component: Runtime System | Version: 7.10.2-rc1 (Linker) | Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 | (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1115 -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed Comment: dd7e1880 was merged to `ghc-7.10` as 5a55ed7. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 29 17:13:17 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Sep 2015 17:13:17 -0000 Subject: [GHC] #10920: ghci can't load local Prelude module Message-ID: <044.430737785a4f09b7817aca3e41ea1e80@haskell.org> #10920: ghci can't load local Prelude module -------------------------------------+------------------------------------- Reporter: Yuras | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- I have a `Prelude.hs` file which contains {{{#!hs module Prelude where }}} If I invoke `ghci` from the same directory, I get {{{ Top level: attempting to use module ?Prelude? (./Prelude.hs) which is not loaded }}} Note: `ghc --make` correctly compiles modules that use the local `Prelude.hs`, so I expect `ghci` to handle that case too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 29 17:57:19 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Sep 2015 17:57:19 -0000 Subject: [GHC] #10878: Near doubling of generated code size for compiler/cmm/PprC.hs with commit 5d57087e31 In-Reply-To: <044.9d94a947d4932234addf1109fa44fa7c@haskell.org> References: <044.9d94a947d4932234addf1109fa44fa7c@haskell.org> Message-ID: <059.a3681464a491eaf9c27f23c143724a3e@haskell.org> #10878: Near doubling of generated code size for compiler/cmm/PprC.hs with commit 5d57087e31 -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by thomie): I built various trees on Windows 64-bit using BuildFlavour=perf: * current HEAD (78053f449d47a90c977ec3a893524f2cdb5d33f9) with the change to compiler/utils/Pretty.hs reverted (5d57087e314bd484dbe14958f9b422be3ac6641a) * current HEAD + NOINLINE pragmas on above_ and beside_ * current HEAD || measurement || HEAD+revert || HEAD+INLINE || HEAD || || du -bhs compiler/stage2/build/PprCmm.o || 106K || 132K || 203K || || du -bhs compilre/stage2/build/CLabel.o || 838K || 336K || 371K || || du -bhs compiler/stage2/build || 503M || 517M || 533M || So I confirm your findings: PprCmm.o has doubled in size, and adding NOLINE pragmas brings it back to 20-30%. I compared some other .o files, and found to my surprise that CLabel.o has however more than halved in size! But since the total size of the stage2/build directory has increased, we should probably do something. I don't understand yet why adding NOINLINE on above_ and beside_ doesn't bring the sizes back to the baseline. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 29 19:07:14 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Sep 2015 19:07:14 -0000 Subject: [GHC] #10448: Implement rest of "Add bifunctor related classes to base"-Proposal In-Reply-To: <042.2a13dedaa488c75793ff62c67a501b4f@haskell.org> References: <042.2a13dedaa488c75793ff62c67a501b4f@haskell.org> Message-ID: <057.9e3cd4300524d1bf68dde8d6dcd2f3da@haskell.org> #10448: Implement rest of "Add bifunctor related classes to base"-Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: libraries/base | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9682 | Differential Rev(s): Phab:D336 -------------------------------------+------------------------------------- Comment (by RyanGlScott): Ed pointed out to me that one possible stumbling block in migrating `Bitraversable` to `base` is [http://hackage.haskell.org/package/bifunctors-5/docs/Data- Bitraversable.html its current definition]: {{{#!hs class (Bifunctor t, Bifoldable t) => Bitraversable t where bitraverse :: Applicative f => (a -> f c) -> (b -> f d) -> t a b -> f (t c d) bisequenceA :: Applicative f => t (f a) (f b) -> f (t a b) bimapM :: Monad m => (a -> m c) -> (b -> m d) -> t a b -> m (t c d) bisequence :: Monad m => t (m a) (m b) -> m (t a b) }}} Like `Traversable`, `Bitraversable` currently has two duplicate method signatures with stronger constraints (`Monad` instead of `Applicative`). We should probably aim to make `bimapM` and `bisequence` top-level definitions instead of class methods during the migration, but there has been a lingering question of whether this would affect runtime performance. AFAICT, the consensus is that any remaining obstacles to redefining `mapM = traverse` [https://mail.haskell.org/pipermail/libraries/2015-May/025723.html have been overcome] since #8189 was fixed, so is there any reason that we couldn't also redefine `bimapM = bitraverse` and `bisequence = bisequenceA`? Other than that, I don't see any reason why we couldn't migrate `Data.Bifoldable` and `Data.Bitraversable` as they're implemented right now. One thing that was a concern for `Foldable` (#9621) was turning functions like `toList` into class methods for efficiency purposes, but I can't think of a `Bifoldable` instance that would benefit significantly from this, so we can probably leave that aside. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 29 19:21:07 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Sep 2015 19:21:07 -0000 Subject: [GHC] #10448: Implement rest of "Add bifunctor related classes to base"-Proposal In-Reply-To: <042.2a13dedaa488c75793ff62c67a501b4f@haskell.org> References: <042.2a13dedaa488c75793ff62c67a501b4f@haskell.org> Message-ID: <057.d5ca0e44324bdad34bfa680b0d091e87@haskell.org> #10448: Implement rest of "Add bifunctor related classes to base"-Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: libraries/base | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9682 | Differential Rev(s): Phab:D336 -------------------------------------+------------------------------------- Comment (by ekmett): I support moving a minimal flavor of `Bifoldable`/`Bitraversable` in. They don't have any legacy users to consider in terms of any bad interactions with different `Monad`'s lack of implementation of `(*>)` vs. `(>>)`. In fact I'd go so far as to remove `bisequenceA`, `bimapM` and `bisequence` from the class entirely in anticipation of doing the same to `Traversable`, and as a much smaller, low-impact laboratory for exploring that change. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 29 20:25:36 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Sep 2015 20:25:36 -0000 Subject: [GHC] #10448: Implement rest of "Add bifunctor related classes to base"-Proposal In-Reply-To: <042.2a13dedaa488c75793ff62c67a501b4f@haskell.org> References: <042.2a13dedaa488c75793ff62c67a501b4f@haskell.org> Message-ID: <057.0d2fd706e4ed0a09b4bb82f3b24230ce@haskell.org> #10448: Implement rest of "Add bifunctor related classes to base"-Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: libraries/base | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9682 | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by hvr): * differential: Phab:D336 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 29 20:26:49 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Sep 2015 20:26:49 -0000 Subject: [GHC] #10913: deprecate and then remove -fwarn-hi-shadowing In-Reply-To: <043.5271c7f4effd317ccfe2016268f0bde8@haskell.org> References: <043.5271c7f4effd317ccfe2016268f0bde8@haskell.org> Message-ID: <058.4894926d342f8b8ae1f56bd26e0f1b1a@haskell.org> #10913: deprecate and then remove -fwarn-hi-shadowing -------------------------------------+------------------------------------- Reporter: osa1 | Owner: ChrisU Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by slyfox): * cc: slyfox (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 29 20:53:13 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Sep 2015 20:53:13 -0000 Subject: [GHC] #10918: Float once-used let binding into a recursive function In-Reply-To: <046.57a8bfaf928dc1d6c0d53688bcdd3dbd@haskell.org> References: <046.57a8bfaf928dc1d6c0d53688bcdd3dbd@haskell.org> Message-ID: <061.3149d94794612f993ea330b54b331bd8@haskell.org> #10918: Float once-used let binding into a recursive function -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by nomeata): Thanks for the input! Next thing to consider problem: Can we float it past the case analysis (or past multiple recursive bindings): In {{{ let x = f x0 in let go 30 = x go 20 = x go 10 = something else go i = go (i+1) in go y }}} we know that `x` is evaluated at most once, so we want to float it in. Also, `x` might actually not be needed, so we would gain something by not allocating it before hand. But we also definitely not want it to float past the let and the lambda, just to get {{{ let go i = let x = f x0 in case i of 30 -> x 20 -> x 10 -> something else i -> go (i+1) in go y }}} as now we would allocate it on _every_ call. So either, floats that are allowed to go into a recursive group _must_ also go past a case, possibly duplicating it: {{{ let go 30 = let x = f x0 in x go 20 = let x = f x0 in x go 10 = something else go i = go (i+1) in go y }}} But this would blow up the code size... . A more cautious route would be to only float something inside a recursive group if it is used at most once _and_ there is only one syntactical call to it, because then we can be reasonably sure that it will also float into the branches. Is there an easy way to detect that something has only one syntactic occurence? Is it not possible to tell the inliner to do this work and decision making? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 29 21:34:26 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Sep 2015 21:34:26 -0000 Subject: [GHC] #10448: Implement rest of "Add bifunctor related classes to base"-Proposal In-Reply-To: <042.2a13dedaa488c75793ff62c67a501b4f@haskell.org> References: <042.2a13dedaa488c75793ff62c67a501b4f@haskell.org> Message-ID: <057.bc24ea1ab39ac1a3b5065a9838c86104@haskell.org> #10448: Implement rest of "Add bifunctor related classes to base"-Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: libraries/base | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9682 | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by RyanGlScott): Oh, I didn't realize that you wanted to remove `bisequenceA` from the `Bitraversable` class as well. What is your reasoning for that one? Is it because it's just `bitraverse id id`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 29 21:37:44 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Sep 2015 21:37:44 -0000 Subject: [GHC] #10448: Implement rest of "Add bifunctor related classes to base"-Proposal In-Reply-To: <042.2a13dedaa488c75793ff62c67a501b4f@haskell.org> References: <042.2a13dedaa488c75793ff62c67a501b4f@haskell.org> Message-ID: <057.a412bcd49c4f8dbd275d1f5d78d21711@haskell.org> #10448: Implement rest of "Add bifunctor related classes to base"-Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: libraries/base | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9682 | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by ekmett): It is in the list of simplifications to consider for `Traversable`. If we can show it doesn't help measurably, it'd be a win for simplicity, and the `(bi)sequenceA` name that nobody likes can then eventually die in favor of `(bi)sequence`, whereas the other way there is no actual viable upgrade path that supports its removal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 30 03:08:13 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Sep 2015 03:08:13 -0000 Subject: [GHC] #10831: Document conditions on deriving Functor In-Reply-To: <048.8298ed09a98386a50539acd12ba36fa5@haskell.org> References: <048.8298ed09a98386a50539acd12ba36fa5@haskell.org> Message-ID: <063.ac3850caca31bb3a55c03695b49f6672@haskell.org> #10831: Document conditions on deriving Functor -------------------------------------+------------------------------------- Reporter: htebalaka | Owner: RyanGlScott Type: bug | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1293 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * owner: => RyanGlScott * differential: => Phab:D1293 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 30 11:23:16 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Sep 2015 11:23:16 -0000 Subject: [GHC] #9557: Deriving instances is slow In-Reply-To: <048.4125fec548f18fcd48da9989fc1ebc4e@haskell.org> References: <048.4125fec548f18fcd48da9989fc1ebc4e@haskell.org> Message-ID: <063.c4e461773e195a1d8d264ca412b6301c@haskell.org> #9557: Deriving instances is slow -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8731 #10858 | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by hvr): * cc: hvr (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 30 12:19:37 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Sep 2015 12:19:37 -0000 Subject: [GHC] #10747: Infix pattern synonyms fail to parse (regression) In-Reply-To: <048.dc77b17374ac8b11e33228cc9dd19430@haskell.org> References: <048.dc77b17374ac8b11e33228cc9dd19430@haskell.org> Message-ID: <063.547e36ff7a90cfde1d6a32870b6f35fb@haskell.org> #10747: Infix pattern synonyms fail to parse (regression) -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by heisenbug): Maybe I have to enable `TypeOperators` too? '''' No, same error message. {{{ error: parse error on input ?`? Failed, modules loaded: none. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 30 12:34:38 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Sep 2015 12:34:38 -0000 Subject: [GHC] #10747: Infix pattern synonyms fail to parse (regression) In-Reply-To: <048.dc77b17374ac8b11e33228cc9dd19430@haskell.org> References: <048.dc77b17374ac8b11e33228cc9dd19430@haskell.org> Message-ID: <063.c522c98f85811ede18680fdf62be76c6@haskell.org> #10747: Infix pattern synonyms fail to parse (regression) -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by mpickering): I'm yet to look at this in detail but I suspect that this was never meant to work. I assumed that infix pattern synonyms definitions were meant to be like infix data constructor definitions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 30 12:46:02 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Sep 2015 12:46:02 -0000 Subject: [GHC] #10747: Infix pattern synonyms fail to parse (regression) In-Reply-To: <048.dc77b17374ac8b11e33228cc9dd19430@haskell.org> References: <048.dc77b17374ac8b11e33228cc9dd19430@haskell.org> Message-ID: <063.a00bc732e8cdcdd4c793902c09c017b1@haskell.org> #10747: Infix pattern synonyms fail to parse (regression) -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by heisenbug): Replying to [comment:6 mpickering]: > I'm yet to look at this in detail but I suspect that this was never meant to work. I assumed that infix pattern synonyms definitions were meant to be like infix data constructor definitions. Then it should work: {{{ $ ghci GHCi, version 7.11.20150928: http://www.haskell.org/ghc/ :? for help Prelude> data List a = Nil | a `Cons` List a deriving Show Prelude> 4 `Cons` Nil 4 `Cons` Nil }}} This has been working for ages! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 30 13:09:17 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Sep 2015 13:09:17 -0000 Subject: [GHC] #10920: ghci can't load local Prelude module In-Reply-To: <044.430737785a4f09b7817aca3e41ea1e80@haskell.org> References: <044.430737785a4f09b7817aca3e41ea1e80@haskell.org> Message-ID: <059.53f3fb69c828a82682320627c0ace17f@haskell.org> #10920: ghci can't load local Prelude module -------------------------------------+------------------------------------- Reporter: Yuras | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by osa1): * cc: osa1 (added) Comment: I once reported this in IRC channel but IIRC someone had convinced me that this is not a bug. Maybe that person can write the explanation here. (I don't remember who) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 30 13:14:15 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Sep 2015 13:14:15 -0000 Subject: [GHC] #1407: Add the ability to :set -l{foo} in .ghci files In-Reply-To: <044.ced6846230ff2e238418885a3d68ddd9@haskell.org> References: <044.ced6846230ff2e238418885a3d68ddd9@haskell.org> Message-ID: <059.6de06193aae728d1e1eddb49da5f043c@haskell.org> #1407: Add the ability to :set -l{foo} in .ghci files -------------------------------------+------------------------------------- Reporter: guest | Owner: archblob Type: feature request | Status: new Priority: normal | Milestone: 7.10.3 Component: GHCi | Version: 6.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D194 -------------------------------------+------------------------------------- Comment (by archblob): I talked with @thomie on #ghc right after the ticked was opened again and the second problem was just a mistake and there is no problem with the patch, but there is indeed a problem with the test. I have looked into it then but I did not find a solution that was guaranteed not to break in the future(I looked for a library that was guaranteed to be present on both systems). What we could do instead is build one as part of the test and try to load that. If you think that is ok I'll go ahead and make a patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 30 13:26:55 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Sep 2015 13:26:55 -0000 Subject: [GHC] #10755: Add `MonadPlus IO` and `Alternative IO` instances In-Reply-To: <042.9475d11a3f91fa4e741f69ce0a266155@haskell.org> References: <042.9475d11a3f91fa4e741f69ce0a266155@haskell.org> Message-ID: <057.9258f07fae7de76e0d6a77a7b1971cda@haskell.org> #10755: Add `MonadPlus IO` and `Alternative IO` instances -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: patch Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: Resolution: | Keywords: report-impact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1148 -------------------------------------+------------------------------------- Comment (by RyanGlScott): The orphan `MonadPlus IO` and `Alternative IO` instances are back in the upstream version of `transformers` (guarded by `#ifdef`s so that they won't be defined in GHC 7.11 and later), so that should no longer be an issue as far as this ticket is concerned. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 30 13:27:17 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Sep 2015 13:27:17 -0000 Subject: [GHC] #10747: Infix pattern synonyms fail to parse (regression) In-Reply-To: <048.dc77b17374ac8b11e33228cc9dd19430@haskell.org> References: <048.dc77b17374ac8b11e33228cc9dd19430@haskell.org> Message-ID: <063.647e314c39842ed7ec07c4f345cccf56@haskell.org> #10747: Infix pattern synonyms fail to parse (regression) -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: mpickering Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by mpickering): * owner: => mpickering Comment: Ok! I will add it to my queue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 30 13:42:55 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Sep 2015 13:42:55 -0000 Subject: [GHC] #10921: weird "optimisation levels" in man page Message-ID: <043.8680f4d8778862d9aa62137f8695f078@haskell.org> #10921: weird "optimisation levels" in man page -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Documentation | Version: 7.10.2 Keywords: manpage, | Operating System: Unknown/Multiple newcomer | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- Man page shows this: {{{ Optimisation levels -O0 -O -O or -O1 -O0 -O2 -O0 -Odph }}} This looks very weird: - Why -O and -O0 listed twice? - That `or` looks weird, how do I read that? Apparently the man page is auto-generated from the user manual(thanks @int-e), and while doing that "reverse" column is also included. We should probably either ignore "reverse" column while parsing the user manual parts or somehow re-format generated man page lines. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 30 13:45:42 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Sep 2015 13:45:42 -0000 Subject: [GHC] #10857: "ghci -XMonomorphismRestriction" doesn't turn on the monomorphism restriction In-Reply-To: <047.0bca38b39289a4db2d373be62522bc3d@haskell.org> References: <047.0bca38b39289a4db2d373be62522bc3d@haskell.org> Message-ID: <062.f27a2665199ad433c425190c048fb0b4@haskell.org> #10857: "ghci -XMonomorphismRestriction" doesn't turn on the monomorphism restriction -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #3202, #3217 | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by cocreature): * owner: cocreature => Comment: I can't come up with a nice solution to this, I'll leave it to someone else. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 30 16:04:35 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Sep 2015 16:04:35 -0000 Subject: [GHC] #1407: Add the ability to :set -l{foo} in .ghci files In-Reply-To: <044.ced6846230ff2e238418885a3d68ddd9@haskell.org> References: <044.ced6846230ff2e238418885a3d68ddd9@haskell.org> Message-ID: <059.1ddd6326eed150271062c67dba7d1d6a@haskell.org> #1407: Add the ability to :set -l{foo} in .ghci files -------------------------------------+------------------------------------- Reporter: guest | Owner: archblob Type: feature request | Status: new Priority: normal | Milestone: 7.10.3 Component: GHCi | Version: 6.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D194 -------------------------------------+------------------------------------- Comment (by thomie): Sounds good to me. See also the other tests in `testsuite/tests/ghci/linking/Makefile`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 30 16:40:32 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Sep 2015 16:40:32 -0000 Subject: [GHC] #10918: Float once-used let binding into a recursive function In-Reply-To: <046.57a8bfaf928dc1d6c0d53688bcdd3dbd@haskell.org> References: <046.57a8bfaf928dc1d6c0d53688bcdd3dbd@haskell.org> Message-ID: <061.2e4fb001fd9cc59025dc69a2f9f23f4b@haskell.org> #10918: Float once-used let binding into a recursive function -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by simonpj): Oh, you are right! The inliner is a much better place to do this, specifically, the code in `preInlineUnconditionally`. It deals with the case where we have {{{ let x = in ....x..... }}} where there is a single syntactic occurrence of x, not inside a lambda (unless it's a one-shot lambda). The occurrence analyser marks `x` with an `OccInfo` of `OneOcc`. So you want to teach the occurrence analyser how to make `x` as "occurs once" even though it occurs inside a lambda which is called more than once (the one for `go`). Or perhaps, when the occurrence analyser is about to mark it it as `OneOcc True ...`, where the `True` is the `InsideLam` info, we can switch the `InsideLam` info to `False` if `x` is marked "demanded once" In haste Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 30 20:23:31 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Sep 2015 20:23:31 -0000 Subject: [GHC] #10922: String inlining is inconsistent Message-ID: <045.1248535f4fce805677912aba5d04066f@haskell.org> #10922: String inlining is inconsistent -------------------------------------+------------------------------------- Reporter: xnyhps | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- I have the following code: A.hs: {{{#!hs module A where foo :: String {-# INLINE foo #-} foo = "foo" }}} B.hs: {{{#!hs import A main = if foo == "foo" then return () else putStrLn "Wrong" }}} Compiling this with `-O2` shows the if-statement has not been eliminated (`"Wrong"` is still part of the output with `-ddump-simpl`). However, if I rewrite the code to: A.hs: {{{#!hs module A where foo :: () -> String {-# INLINE foo #-} foo () = "foo" }}} B.hs: {{{#!hs import A main = if foo () == "foo" then return () else putStrLn "Wrong" }}} Then the if-statement disappears and the generated Core has no string literals left. Even when the literal can not be eliminated from B it seems GHC is fine with duplicating it accross two modules if it occurs somewhere inside a function. But once I make it a top-level expression of type `String`, inlining it does not happen. I can not think of how this could be working as intended. (The case where `A.foo` is `""` seems to work differently, but also does not get optimized away.) (This happened to me when rewriting some code that previously used `CPP` for conditional compilation to using `if System.Info.os == "darwin" then ... else ...` and expecting the other OS cases to get optimized away.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 30 22:06:42 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Sep 2015 22:06:42 -0000 Subject: [GHC] #10921: weird "optimisation levels" in man page In-Reply-To: <043.8680f4d8778862d9aa62137f8695f078@haskell.org> References: <043.8680f4d8778862d9aa62137f8695f078@haskell.org> Message-ID: <058.f5f9f390c4aaf3903c0f7faf93738194@haskell.org> #10921: weird "optimisation levels" in man page -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Documentation | Version: 7.10.2 Resolution: | Keywords: manpage, | newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by rwbarton): * cc: bgamari (added) Comment: Ccing bgamari since he's working in this area currently. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 30 23:40:35 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Sep 2015 23:40:35 -0000 Subject: [GHC] #10747: Infix pattern synonyms fail to parse (regression) In-Reply-To: <048.dc77b17374ac8b11e33228cc9dd19430@haskell.org> References: <048.dc77b17374ac8b11e33228cc9dd19430@haskell.org> Message-ID: <063.3c59f896de5a57b69f643bf1b06a0e25@haskell.org> #10747: Infix pattern synonyms fail to parse (regression) -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: mpickering Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1295 -------------------------------------+------------------------------------- Changes (by mpickering): * differential: => Phab:D1295 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 17 09:26:41 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Sep 2015 09:26:41 -0000 Subject: [GHC] #10728: Add e.g. "-N<=4" in addition to the fixed "-N4" and variable "-N" RTS options In-Reply-To: <047.8ab1f4617aa75c3c439f322b5bb4c6f5@haskell.org> References: <047.8ab1f4617aa75c3c439f322b5bb4c6f5@haskell.org> Message-ID: <062.bf2c0c7f902aff00819960cea0c87280@haskell.org> #10728: Add e.g. "-N<=4" in addition to the fixed "-N4" and variable "-N" RTS options -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9221, #8224 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * cc: simonmar (added) * owner: simonmar => -- Ticket URL: GHC The Glasgow Haskell Compiler