From ghc-devs at haskell.org Sun Nov 1 00:40:18 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 00:40:18 -0000 Subject: [GHC] #11041: EventLog write fails if entire buffer is not written Message-ID: <049.1dbeaea4e627c4c0bcd66b984b44ecbf@haskell.org> #11041: EventLog write fails if entire buffer is not written -------------------------------------+------------------------------------- Reporter: sseverance | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.10.2 System | Keywords: eventlog | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Recently I was trying to use ThreadScope to run down a performance issue. I ran into what I believe is a corner case with flushing the eventlog data to disk. The program was generating hundreds of millions of events every few minutes. The function printAndClearEventBuf uses fwrite to flush the buffer to disk. What I observed is that with larger buffers it would only succeed in writing the first 4096 bytes. After it would print out its debugBelch message a number of times the program would crash. It does not crash if not run with the eventlog -l flag. My understanding is that fwrite might need to be called in a loop to ensure that all data is written. fwrite is not guaranteed to always write the entire requested buffer. I don't have a good test case for this, but if there is agreement about potential issues with flushing the buffer I am more than happy to provide a patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 1 03:50:57 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 03:50:57 -0000 Subject: [GHC] #10789: Notify user when a kind mismatch holds up a type family reduction In-Reply-To: <047.282dd8bb976bc76373d556a5e980ac6e@haskell.org> References: <047.282dd8bb976bc76373d556a5e980ac6e@haskell.org> Message-ID: <062.cad29256bd5bb7d9d4d49f87a40a5e29@haskell.org> #10789: Notify user when a kind mismatch holds up a type family reduction -------------------------------------+------------------------------------- Reporter: goldfire | Owner: ssequeira Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * milestone: ? => 8.0.1 Comment: Thanks, ssequeira! I assume the change in milestone was accidental, and so I'm reverting it. Setting a milestone to bottom effectively means that we've given up on the ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 1 03:53:53 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 03:53:53 -0000 Subject: [GHC] #10972: Add a :binfo (beginner info) GHCi command In-Reply-To: <045.69c25027f6e9192e0896957840c11b0e@haskell.org> References: <045.69c25027f6e9192e0896957840c11b0e@haskell.org> Message-ID: <060.de119cc274b231b4a600175eeed4acab@haskell.org> #10972: Add a :binfo (beginner info) GHCi command -------------------------------------+------------------------------------- Reporter: kanetw | Owner: kanetw 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: #10963 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): A few thoughts: we should only print out specialisations of class- constrained parameters (never parametric ones), and we have to worry about a combinatorial number of these if there are multiple constraints. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 1 04:02:25 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 04:02:25 -0000 Subject: [GHC] #11035: Add implicit call-stacks to partial functions in base In-Reply-To: <049.cfaa63a68670a816facc2036509f578c@haskell.org> References: <049.cfaa63a68670a816facc2036509f578c@haskell.org> Message-ID: <064.1754ac09fa39c140ec479e61ee330f6c@haskell.org> #11035: Add implicit call-stacks to partial functions in base -------------------------------------+------------------------------------- Reporter: gridaphobe | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:5 nomeata]: > How about we stay on top of the slipperly slope for a while, and let people experiment with their call-stack enabled custom Preludes first for a while? Perhaps that's true. But this change would be quite under-the-hood, so I'm less worried about changing libraries in this way. > > In fact, what I do not like about > {{{ > ghci> minimumBy compare [] > *** Exception: Prelude.foldr1: empty list > CallStack: > error, called at libraries/base/GHC/List.hs:999:3 in base-4.8.2.0:GHC.List > }}} > is that it leaks implementation details. This is great in your own code, but a polished library should _not_ leak a call stack about its details; it should either print plain exception or the call stack that finishes at the library?s API. At least for ?expected exceptions? like `"empty list"`. I disagree with this push toward perfection. I understand what you're getting at here, and I agree in principle. But I think this issue (which does seem to be independent from the original ticket) is not terribly important to solve. In other languages, I've seen standard libraries spill their implementation details all over the place in stack traces. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 1 04:04:07 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 04:04:07 -0000 Subject: [GHC] #11035: Add implicit call-stacks to partial functions in base In-Reply-To: <049.cfaa63a68670a816facc2036509f578c@haskell.org> References: <049.cfaa63a68670a816facc2036509f578c@haskell.org> Message-ID: <064.883bebfc4b2c794e887640e043c1b462@haskell.org> #11035: Add implicit call-stacks to partial functions in base -------------------------------------+------------------------------------- Reporter: gridaphobe | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:2 gridaphobe]: > Regarding problem (1): I get the feeling this will require code duplication at the source level, which would be a Bad Thing. Yes, that's true. I realized that as I wrote my post, but didn't really dwell on it. It is a Bad Thing. > A more heavyweight solution could be to have GHC generate a callstack- free version of each function that takes a CallStack, along with a RULE like you described. Then the source-level duplication is gone, but the desugarer or simplifier becomes more complex. Yes, this is indeed more heavyweight. Worth it? Probably not. I'd love input from someone who knows about the DWARF stuff! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 1 08:41:36 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 08:41:36 -0000 Subject: [GHC] #11042: Template Haskell / GHCi does not respect extra-lib-dirs Message-ID: <044.eb43e7f9b5666e68e3df817728c4c87b@haskell.org> #11042: Template Haskell / GHCi does not respect extra-lib-dirs -------------------------------------+------------------------------------- Reporter: mboes | 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: #10458 #5289 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In particular when compiling on NixOS, but also in many other situations, it is often needed to pass --extra-lib-dirs / --extra-include-dirs to cabal/stack, to help GHC find required system libraries. This works fine for GHC, but not GHCi, and therefore also not Template Haskell code. Minimal example attached. Try it in an environment where libz is not in a standard location, e.g. inside a nix-shell. Note that if you remove the template Haskell splice in Main.hs, the code compiles just fine. This affects GHC 7.10.2, but also HEAD from 2015-08-28, even one including Tamar Christina's 5d841108acef950fed6a5e608ac9b18e7431aa87 commit cherry- picked. I haven't been able to test more recent HEAD, because of unrelated compilation issues. I surmise that a fix to #10458, which currently blocks using HaskellR in GHCi, would also fix this, but I'm not sure. The error message I get is different: {{{ $ stack build --skip-ghc-check --extra-lib- dirs=/nix/store/31w31mc8immhpnmxvcl4l0fvc3i5iwh0-zlib-1.2.8/lib --extra- include- dirs=/nix/store/31w31mc8immhpnmxvcl4l0fvc3i5iwh0-zlib-1.2.8/include b-0.1.0.0: build Preprocessing executable 'b' for b-0.1.0.0... [2 of 2] Compiling Main ( src/Main.hs, .stack- work/dist/x86_64-linux/Cabal-1.23.0.0/build/b/b-tmp/Main.o ) : can't load .so/.DLL for: libz.so (libz.so: cannot open shared object file: No such file or directory) -- While building package b-0.1.0.0 using: /home/mboes/.stack/setup-exe-cache/setup-Simple- Cabal-1.23.0.0-x86_64-linux-ghc-7.11.20150828 --builddir=.stack- work/dist/x86_64-linux/Cabal-1.23.0.0/ build exe:b --ghc-options " -ddump- hi -ddump-to-file" Process exited with code: ExitFailure 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 1 08:43:19 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 08:43:19 -0000 Subject: [GHC] #11042: Template Haskell / GHCi does not respect extra-lib-dirs In-Reply-To: <044.eb43e7f9b5666e68e3df817728c4c87b@haskell.org> References: <044.eb43e7f9b5666e68e3df817728c4c87b@haskell.org> Message-ID: <059.4f97bc46bec7f59d0a297cb426fe73b7@haskell.org> #11042: Template Haskell / GHCi does not respect extra-lib-dirs -------------------------------------+------------------------------------- Reporter: mboes | 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: #10458 #5289 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mboes): * Attachment "b.tar.gz" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 1 08:44:47 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 08:44:47 -0000 Subject: [GHC] #11042: Template Haskell / GHCi does not respect extra-lib-dirs In-Reply-To: <044.eb43e7f9b5666e68e3df817728c4c87b@haskell.org> References: <044.eb43e7f9b5666e68e3df817728c4c87b@haskell.org> Message-ID: <059.3944f5fccf8e42a7c803af1cbd683687@haskell.org> #11042: Template Haskell / GHCi does not respect extra-lib-dirs -------------------------------------+------------------------------------- Reporter: mboes | 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: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #10458 #5289 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mboes): * failure: None/Unknown => GHCi crash -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 1 08:45:14 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 08:45:14 -0000 Subject: [GHC] #11042: Template Haskell / GHCi does not respect extra-lib-dirs In-Reply-To: <044.eb43e7f9b5666e68e3df817728c4c87b@haskell.org> References: <044.eb43e7f9b5666e68e3df817728c4c87b@haskell.org> Message-ID: <059.5c6e4405e5f22920496ed2863eb0c38c@haskell.org> #11042: Template Haskell / GHCi does not respect extra-lib-dirs -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: bug | 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 crash | Test Case: Blocked By: | Blocking: Related Tickets: #10458 #5289 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mboes): * failure: GHCi crash => Compile-time crash -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 1 08:47:20 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 08:47:20 -0000 Subject: [GHC] #11021: Document best practices for bringing up Sphinx on Windows In-Reply-To: <046.0c4621633ac4967e9cb5eee4e02186fd@haskell.org> References: <046.0c4621633ac4967e9cb5eee4e02186fd@haskell.org> Message-ID: <061.0ab02ebdf6728aa87aab12744363405f@haskell.org> #11021: Document best practices for bringing up Sphinx on Windows ----------------------------------+---------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Documentation | Version: 7.11 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1408 Wiki Page: | ----------------------------------+---------------------------------------- Changes (by Phyx-): * owner: Phyx- => * status: closed => new * resolution: fixed => Comment: Just ran into the codepage issue @awson mentioned. Worked the first validate but subsequent ones failed.. don't know why. In any case, the issue seems to be fixed in `python3` https://docs.python.org/dev/whatsnew/3.3.html#codecs and https://bugs.python.org/issue13216 Sphinx also has support for `python 3.3+` so I will make a patch to use the `python3` version of Sphinx and revalidate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 1 09:09:22 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 09:09:22 -0000 Subject: [GHC] #11042: Template Haskell / GHCi does not respect extra-lib-dirs In-Reply-To: <044.eb43e7f9b5666e68e3df817728c4c87b@haskell.org> References: <044.eb43e7f9b5666e68e3df817728c4c87b@haskell.org> Message-ID: <059.1de2222c602c9e73be808962f27909db@haskell.org> #11042: Template Haskell / GHCi does not respect extra-lib-dirs -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: bug | 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 crash | Test Case: Blocked By: | Blocking: Related Tickets: #10458 #5289 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Hi @mboes, Thanks for the report. Are you trying to link against a static of dynamic library? The patch in 5d841108acef950fed6a5e608ac9b18e7431aa87 is only for dynamic libraries. I have one locally that I haven't put for review yet for static libraries. I know the error message mentions `libz.so` but that's probably because it gave up and assumed it's an so, which is why I'm wondering if you're trying to link a static lib. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 1 09:29:01 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 09:29:01 -0000 Subject: [GHC] #11041: EventLog write fails if entire buffer is not written In-Reply-To: <049.1dbeaea4e627c4c0bcd66b984b44ecbf@haskell.org> References: <049.1dbeaea4e627c4c0bcd66b984b44ecbf@haskell.org> Message-ID: <064.86273bb54e4895e5b07d7122778a7af6@haskell.org> #11041: EventLog write fails if entire buffer is not written -------------------------------------+------------------------------------- Reporter: sseverance | Owner: Type: bug | Status: infoneeded Priority: high | Milestone: 8.0.1 Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: eventlog Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => infoneeded * failure: None/Unknown => Incorrect result at runtime * priority: normal => high * milestone: => 8.0.1 Old description: > Recently I was trying to use ThreadScope to run down a performance issue. > I ran into what I believe is a corner case with flushing the eventlog > data to disk. The program was generating hundreds of millions of events > every few minutes. > > The function printAndClearEventBuf uses fwrite to flush the buffer to > disk. What I observed is that with larger buffers it would only succeed > in writing the first 4096 bytes. After it would print out its debugBelch > message a number of times the program would crash. It does not crash if > not run with the eventlog -l flag. > > My understanding is that fwrite might need to be called in a loop to > ensure that all data is written. fwrite is not guaranteed to always write > the entire requested buffer. > > I don't have a good test case for this, but if there is agreement about > potential issues with flushing the buffer I am more than happy to provide > a patch. New description: Recently I was trying to use ThreadScope to run down a performance issue. I ran into what I believe is a corner case with flushing the eventlog data to disk. The program was generating hundreds of millions of events every few minutes. The function `printAndClearEventBuf` uses `fwrite` to flush the buffer to disk. What I observed is that with larger buffers it would only succeed in writing the first 4096 bytes. After it would print out its `debugBelch` message a number of times the program would crash. It does not crash if not run with the eventlog `-l` flag. My understanding is that `fwrite` might need to be called in a loop to ensure that all data is written. `fwrite` is not guaranteed to always write the entire requested buffer. I don't have a good test case for this, but if there is agreement about potential issues with flushing the buffer I am more than happy to provide a patch. -- Comment: For the sake of completeness of the ticket, what operating system did you observe this on? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 1 09:35:02 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 09:35:02 -0000 Subject: [GHC] #11041: EventLog write fails if entire buffer is not written In-Reply-To: <049.1dbeaea4e627c4c0bcd66b984b44ecbf@haskell.org> References: <049.1dbeaea4e627c4c0bcd66b984b44ecbf@haskell.org> Message-ID: <064.4964c7615f6433674cf5e0816ea9ed56@haskell.org> #11041: EventLog write fails if entire buffer is not written -------------------------------------+------------------------------------- Reporter: sseverance | Owner: Type: bug | Status: infoneeded Priority: high | Milestone: 8.0.1 Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: eventlog Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): For the record, on my Debian 8 machine this succeeds in writing the entire buffer, {{{ #include #include void main() { FILE* f = fopen("test", "w+"); int n = 1024*1025; char* xs = malloc(n); size_t written = fwrite(xs, 1, n, f); printf("written = %d\n", written); } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 1 09:38:15 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 09:38:15 -0000 Subject: [GHC] #11041: EventLog write fails if entire buffer is not written In-Reply-To: <049.1dbeaea4e627c4c0bcd66b984b44ecbf@haskell.org> References: <049.1dbeaea4e627c4c0bcd66b984b44ecbf@haskell.org> Message-ID: <064.881a63f6fb974969c61b46ebfd382731@haskell.org> #11041: EventLog write fails if entire buffer is not written -------------------------------------+------------------------------------- Reporter: sseverance | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: eventlog Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D11041 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: infoneeded => patch * differential: => Phab:D11041 Comment: Opened Phab:D11041 which ought to fix the eventlog flush logic. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 1 09:38:37 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 09:38:37 -0000 Subject: [GHC] #11041: EventLog write fails if entire buffer is not written In-Reply-To: <049.1dbeaea4e627c4c0bcd66b984b44ecbf@haskell.org> References: <049.1dbeaea4e627c4c0bcd66b984b44ecbf@haskell.org> Message-ID: <064.ea21d792649a81c983b9da7d29199d5a@haskell.org> #11041: EventLog write fails if entire buffer is not written -------------------------------------+------------------------------------- Reporter: sseverance | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: eventlog Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1415 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * differential: Phab:D11041 => Phab:D1415 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 1 09:46:46 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 09:46:46 -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.2f4fd913d3f947e1714b5b5c18b93a38@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 Rev(s): Phab:D1242 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"3021cc06f84109c6e7a529318d690c520748f936/ghc" 3021cc06/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3021cc06f84109c6e7a529318d690c520748f936" Add rts/Linker support for more than 64k sections Since some ELF fields ran out of range to represent that many sections, they've been extended with magic numbers that indicate that the full value is stored in another field. This will be necessary for GHCi with -split-sections on ELF platforms that don't use GNU ld. Reviewers: austin, bgamari, simonmar, erikd Reviewed By: bgamari, simonmar, erikd Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1357 GHC Trac Issues: #8405 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 1 09:46:46 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 09:46:46 -0000 Subject: [GHC] #10917: Provide a utility to check API Annotations In-Reply-To: <044.180158552b685611f17d6b8a8773714f@haskell.org> References: <044.180158552b685611f17d6b8a8773714f@haskell.org> Message-ID: <059.6841b9c7b86b7fbb617b64981740666e@haskell.org> #10917: Provide a utility to check API Annotations -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1368 Wiki Page: | Phab:D1397 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"c3b02150b516963422ed4b9b200a38814a35b535/ghc" c3b02150/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c3b02150b516963422ed4b9b200a38814a35b535" Provide a utility to check API Annotations docs A utility to check API Annotations was provided in https://git.haskell.org/ghc.git/commitdiff/43751b2436f370d956d8021b3cdd3 eb77801470b This commit had poor documentation. This patch improves the output generated by the utility as well as supplying better documentation Test Plan: ./validate Reviewers: simonpj, austin, bgamari Reviewed By: austin, bgamari Subscribers: thomie, mpickering Differential Revision: https://phabricator.haskell.org/D1397 GHC Trac Issues: #10917 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 1 09:46:46 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 09:46:46 -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.a08c5a3ebc5a243814df47faff283f6a@haskell.org> #10877: x86_64: dll-split: out of memory (requested 1099512676352 bytes) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: patch 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 Rev(s): Phab:D1405 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"4ad2a8f9a503a5ee060eb8e0d5ae71b98d605cfa/ghc" 4ad2a8f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4ad2a8f9a503a5ee060eb8e0d5ae71b98d605cfa" rts/posix: Reduce heap allocation amount on mmap failure Since the two-step allocator the RTS asks the kernel for a large upfront mmap'd region of memory (on the order of terabytes). While we have no expectation that this entire region will be backed by physical memory, this scheme nevertheless fails on some systems with resource limits. Here we use a back-off scheme to reduce our allocation request until we find a size agreeable to the kernel. Fixes #10877. This also fixes a latent bug wherein the heap reservation retry logic would fail to free the previously reserved address space, which would likely result in a heap allocation failure. Test Plan: set address space limit with `ulimit -v 67108864` and try running a compiled program Reviewers: simonmar, austin Reviewed By: simonmar Subscribers: thomie, RyanGlScott Differential Revision: https://phabricator.haskell.org/D1405 GHC Trac Issues: #10877 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 1 10:09:29 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 10:09:29 -0000 Subject: [GHC] #10917: Provide a utility to check API Annotations In-Reply-To: <044.180158552b685611f17d6b8a8773714f@haskell.org> References: <044.180158552b685611f17d6b8a8773714f@haskell.org> Message-ID: <059.82e354cca75b795f79e4c38268df1bc8@haskell.org> #10917: Provide a utility to check API Annotations -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1368 Wiki Page: | Phab:D1397 -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 1 10:11:00 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 10:11:00 -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.8f51fa832e2df980887d4bdd4851252f@haskell.org> #10877: x86_64: dll-split: out of memory (requested 1099512676352 bytes) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: #10682 | Differential Rev(s): Phab:D1405 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 1 10:28:34 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 10:28:34 -0000 Subject: [GHC] #11042: Template Haskell / GHCi does not respect extra-lib-dirs In-Reply-To: <044.eb43e7f9b5666e68e3df817728c4c87b@haskell.org> References: <044.eb43e7f9b5666e68e3df817728c4c87b@haskell.org> Message-ID: <059.c2a9be86a8b4b758aaae49e04aa046a0@haskell.org> #11042: Template Haskell / GHCi does not respect extra-lib-dirs -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: bug | 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 crash | Test Case: Blocked By: | Blocking: Related Tickets: #10458 #5289 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mboes): @Phyx- I'm not sure actually. How do I tell reliably? FWIW, the following command using the above provided example fails too: {{{ $ cabal sandbox init $ cabal install --enable-shared Resolving dependencies... Notice: installing into a sandbox located at /tmp/b/.cabal-sandbox Downloading zlib-0.6.1.1... Configuring zlib-0.6.1.1... Building zlib-0.6.1.1... Installed zlib-0.6.1.1 Configuring b-0.1.0.0... Building b-0.1.0.0... Failed to install b-0.1.0.0 Build log ( /tmp/b/.cabal-sandbox/logs/b-0.1.0.0.log ): Configuring b-0.1.0.0... Building b-0.1.0.0... Preprocessing executable 'b' for b-0.1.0.0... [1 of 2] Compiling Id ( src/Id.hs, dist/dist-sandbox- d8895b0c/build/b/b-tmp/Id.o ) [2 of 2] Compiling Main ( src/Main.hs, dist/dist-sandbox- d8895b0c/build/b/b-tmp/Main.o ) : can't load .so/.DLL for: libz.so (libz.so: cannot open shared object file: No such file or directory) cabal: Error: some packages failed to install: b-0.1.0.0 failed during the building phase. The exception was: ExitFailure 1 }}} Is there a way to control whether Template Haskell looks for static or for dynamic foreign libraries? Does the --enable-shared flag have any effect on that? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 1 11:00:30 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 11:00:30 -0000 Subject: [GHC] #11026: Bump `base` version to 4.9.0.0 In-Reply-To: <042.f747c2b78427a306bca14268108fcb46@haskell.org> References: <042.f747c2b78427a306bca14268108fcb46@haskell.org> Message-ID: <057.3b3d18ae489f4338c62c33da30957f3d@haskell.org> #11026: Bump `base` version to 4.9.0.0 -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: highest | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"62e1b3594c233d333e87e72d57c1e182d0aa0802/ghc" 62e1b35/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="62e1b3594c233d333e87e72d57c1e182d0aa0802" Update array/stm/hpc/haddock submodules This is needed to prepare for #11026 as these updates relax the upper bounds on `base` to allow for `base-4.9.0.0` }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 1 11:00:30 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 11:00:30 -0000 Subject: [GHC] #11026: Bump `base` version to 4.9.0.0 In-Reply-To: <042.f747c2b78427a306bca14268108fcb46@haskell.org> References: <042.f747c2b78427a306bca14268108fcb46@haskell.org> Message-ID: <057.9d3dbf86afef52e3a2d7f58a22cd7689@haskell.org> #11026: Bump `base` version to 4.9.0.0 -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: highest | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"d2a7fb9715799b6f420241a4647bdb113a0a928e/ghc" d2a7fb9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d2a7fb9715799b6f420241a4647bdb113a0a928e" Update directory submodule This is needed to prepare for #11026 as this update relaxes the upper bounds on `base` to allow for `base-4.9.0.0` }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 1 11:00:30 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 11:00:30 -0000 Subject: [GHC] #11026: Bump `base` version to 4.9.0.0 In-Reply-To: <042.f747c2b78427a306bca14268108fcb46@haskell.org> References: <042.f747c2b78427a306bca14268108fcb46@haskell.org> Message-ID: <057.51a48c43c7ccf82cbb6ce8b84dc1b892@haskell.org> #11026: Bump `base` version to 4.9.0.0 -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: highest | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"12abc77386751f7aa9fa6e8731fd1eabc52397f2/ghc" 12abc773/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="12abc77386751f7aa9fa6e8731fd1eabc52397f2" Update filepath submodule This is needed to prepare for #11026 as this update relaxes the upper bounds on `base` to allow for `base-4.9.0.0` }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 1 11:00:30 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 11:00:30 -0000 Subject: [GHC] #11026: Bump `base` version to 4.9.0.0 In-Reply-To: <042.f747c2b78427a306bca14268108fcb46@haskell.org> References: <042.f747c2b78427a306bca14268108fcb46@haskell.org> Message-ID: <057.a5da2ef5299e64c4fa51178b45046f4c@haskell.org> #11026: Bump `base` version to 4.9.0.0 -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: highest | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"3238ef7f834ede18f076d4e8c72b9a119e4499b6/ghc" 3238ef7f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3238ef7f834ede18f076d4e8c72b9a119e4499b6" Update unix submodule This is needed to prepare for #11026 as this update relaxes the upper bounds on `base` to allow for `base-4.9.0.0` }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 1 11:00:30 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 11:00:30 -0000 Subject: [GHC] #11026: Bump `base` version to 4.9.0.0 In-Reply-To: <042.f747c2b78427a306bca14268108fcb46@haskell.org> References: <042.f747c2b78427a306bca14268108fcb46@haskell.org> Message-ID: <057.a1243b7a4f4c155d9235c44d766bd465@haskell.org> #11026: Bump `base` version to 4.9.0.0 -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: highest | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"32f92a33b786cd70222393726aeb08ba2b9d63db/ghc" 32f92a3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="32f92a33b786cd70222393726aeb08ba2b9d63db" Update hoopl submodule This is needed to prepare for #11026 as this update relaxes the upper bounds on `base` to allow for `base-4.9.0.0` }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 1 11:00:30 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 11:00:30 -0000 Subject: [GHC] #11026: Bump `base` version to 4.9.0.0 In-Reply-To: <042.f747c2b78427a306bca14268108fcb46@haskell.org> References: <042.f747c2b78427a306bca14268108fcb46@haskell.org> Message-ID: <057.1d66fed36515eafe3172681a30410370@haskell.org> #11026: Bump `base` version to 4.9.0.0 -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: highest | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"de8443c1a26276dc33a97ecdb9ec5c67f61ff969/ghc" de8443c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="de8443c1a26276dc33a97ecdb9ec5c67f61ff969" Update process submodule This is needed to prepare for #11026 as this update relaxes the upper bounds on `base` to allow for `base-4.9.0.0` This also needs to relax a few upper bounds on process in some cabal files (there will be another process submodule update soon, as a major version bump of process' version is still pending) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 1 11:00:30 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 11:00:30 -0000 Subject: [GHC] #11026: Bump `base` version to 4.9.0.0 In-Reply-To: <042.f747c2b78427a306bca14268108fcb46@haskell.org> References: <042.f747c2b78427a306bca14268108fcb46@haskell.org> Message-ID: <057.c33f096c4bfa026ae8e1f68ca3fd3dae@haskell.org> #11026: Bump `base` version to 4.9.0.0 -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: highest | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"f8ba4b55cc3a061458f5cfabf17de96128defbbb/ghc" f8ba4b55/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f8ba4b55cc3a061458f5cfabf17de96128defbbb" Bump `base` version to 4.9.0.0 (closes #11026) This also relaxes a few upper bounds on base in the ghc.git repo; This required a mass-rewrite in testsuite/ sed -i s,base-4.8.2.0,base-4.9.0.0,g $(git grep -Fl 'base-4.8.2.0') because it turns out the testsuite is still sensitive to package version changes. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 1 11:17:55 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 11:17:55 -0000 Subject: [GHC] #11042: Template Haskell / GHCi does not respect extra-lib-dirs In-Reply-To: <044.eb43e7f9b5666e68e3df817728c4c87b@haskell.org> References: <044.eb43e7f9b5666e68e3df817728c4c87b@haskell.org> Message-ID: <059.172d1f8ce030920c9d5c2a7ce1712d79@haskell.org> #11042: Template Haskell / GHCi does not respect extra-lib-dirs -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: bug | 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 crash | Test Case: Blocked By: | Blocking: Related Tickets: #10458 #5289 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): @mboes, in general by default GHC prefers static libraries, where GHCi prefers dynamic ones. It seems like libz is only available as `libz.a`. So the patch you cherry picked would have no effect. Could you try this branch? https://github.com/Mistuke/ghc/tree/fix-ghci- archive-loading -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 1 11:33:12 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 11:33:12 -0000 Subject: [GHC] #11026: Bump `base` version to 4.9.0.0 In-Reply-To: <042.f747c2b78427a306bca14268108fcb46@haskell.org> References: <042.f747c2b78427a306bca14268108fcb46@haskell.org> Message-ID: <057.7a0529076b09c51fe024a1292efdf6e2@haskell.org> #11026: Bump `base` version to 4.9.0.0 -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: closed Priority: highest | Milestone: 8.0.1 Component: libraries/base | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 1 11:33:49 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 11:33:49 -0000 Subject: [GHC] #11043: Bump `ghc-prim` to 0.5.0.0 Message-ID: <042.36a8915d738563544a9be06daf524030@haskell.org> #11043: Bump `ghc-prim` to 0.5.0.0 -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: high | Milestone: 8.0.1 Component: | Version: 7.11 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 1 11:36:27 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 11:36:27 -0000 Subject: [GHC] #11043: Bump `ghc-prim` to 0.5.0.0 In-Reply-To: <042.36a8915d738563544a9be06daf524030@haskell.org> References: <042.36a8915d738563544a9be06daf524030@haskell.org> Message-ID: <057.58267fd4a9f4de39f997ceac66f4b182@haskell.org> #11043: Bump `ghc-prim` to 0.5.0.0 -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: high | Milestone: 8.0.1 Component: libraries/base | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"4b8b9347f19c6a260c9f93032447bc82f6457912/ghc" 4b8b9347/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4b8b9347f19c6a260c9f93032447bc82f6457912" ghc-prim: add API delta as changelog (re #11043) [skip ci] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 1 12:17:23 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 12:17:23 -0000 Subject: [GHC] #11043: Bump `ghc-prim` to 0.5.0.0 In-Reply-To: <042.36a8915d738563544a9be06daf524030@haskell.org> References: <042.36a8915d738563544a9be06daf524030@haskell.org> Message-ID: <057.17ca0a528eecd93b2fbe681dd4290972@haskell.org> #11043: Bump `ghc-prim` to 0.5.0.0 -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: high | Milestone: 8.0.1 Component: libraries/base | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"84bf1ebae75bff6c1e37382bc348850d17f3f2c0/ghc" 84bf1eb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="84bf1ebae75bff6c1e37382bc348850d17f3f2c0" Bump ghc-prim version to 0.5.0.0 (closes #11043) This also needs to update the primitive/vector submodules in order to relax upper bounds on ghc-prim. Like in f8ba4b55cc3a061458f5cfabf17de96128defbbb, a mass-rewrite in testsuite/ via sed -i s,ghc-prim-0.4.0.0,ghc-prim-0.5.0.0,g $(git grep -Fl 'ghc- prim-0.4.0.0') was performed. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 1 12:18:27 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 12:18:27 -0000 Subject: [GHC] #11043: Bump `ghc-prim` to 0.5.0.0 In-Reply-To: <042.36a8915d738563544a9be06daf524030@haskell.org> References: <042.36a8915d738563544a9be06daf524030@haskell.org> Message-ID: <057.58e9531cfe317a553b5b3171c6a2920e@haskell.org> #11043: Bump `ghc-prim` to 0.5.0.0 -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: closed Priority: high | Milestone: 8.0.1 Component: libraries/base | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 1 12:40:01 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 12:40:01 -0000 Subject: [GHC] #11044: Parse error on empty multi-line deprecation warnings Message-ID: <044.eca441d1c47bb055a7995ead40767af4@haskell.org> #11044: Parse error on empty multi-line deprecation warnings -------------------------------------+------------------------------------- Reporter: inaki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | 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): | Wiki Page: -------------------------------------+------------------------------------- Bug #3303 introduced support for multi-line deprecation messages, with syntax {{{ {-# DEPRECATED someFunction ["One line", "another line"] #-} }}} The following gives a parse error, though: {{{ {-# DEPRECATED someFunction [] #-} }}} I think that it would be reasonable to treat this case as {{{ {-# DEPRECATED somefunction "" #-} }}} For motivation: we ran into this problem when writing bindings to external libraries. The API description for the original library includes deprecation info, with the deprecation messages sometimes spanning multiple lines, so it was convenient to use the list syntax above when generating the Haskell wrappers. But the parse error forced us to special case the case of no deprecation message. We can easily do this, of course, but perhaps the restriction to non-empty lists was not intentional? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 1 12:42:56 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 12:42:56 -0000 Subject: [GHC] #11017: ApiAnnotations: BooleanFormula is not properly Located In-Reply-To: <044.8a6c3bf330a4eb35f37df8711068c35c@haskell.org> References: <044.8a6c3bf330a4eb35f37df8711068c35c@haskell.org> Message-ID: <059.4be197e808b5b36a603e4b86b248ef59@haskell.org> #11017: ApiAnnotations: BooleanFormula is not properly Located -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1384 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"f16827f84855bef94b1b69f49bd1734627946f02/ghc" f16827f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f16827f84855bef94b1b69f49bd1734627946f02" ApiAnnotations: BooleanFormula is not properly Located At the moment BooleanFormula is defined as data BooleanFormula a = Var a | And [BooleanFormula a] | Or [BooleanFormula a] deriving (Eq, Data, Typeable, Functor, Foldable, Traversable) An API Annotation can only be attached to an item of the form Located a. Replace this with a properly Located version, and attach the appropriate API Annotations to it Updates haddock submodule. Test Plan: ./validate Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie, mpickering Differential Revision: https://phabricator.haskell.org/D1384 GHC Trac Issues: #11017 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 1 12:59:37 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 12:59:37 -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.39ad803e6c7cbb90e93298e7b120e715@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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > im seeing slowdowns in parallel builds of a (simple!!) 6 module project > when I build it on a 40 core server i'm using for work. for any given > ghc invocation with -jn, once n>10, i start to see a super linear slow > down as a function of n > > heres some basic numbers > > at -j1 0m2.693s > > at -j4 0m2.507s > > at -j10 0m2.763s > > at -j25 0m12.634s > > at -j30 : 0m39.154s > > at -j40 : 0m57.511s > > at -j60 : 2m21.821s > > these timings are another 2-4x worse if ghc is invoked indirectly via > cabal-install / setup.hs > > according to the linux utility latencytop, 100% of ghc's cpu time was > spent on user-space lock contention when I did the -j40 invocation. > > the timing in the -j40 case stayed the same even when ghc was also passed > -O0 (and -fforce-recomp to ensure it did the same ) > > a bit of experimentation makes me believe that in *ANY* cabalized project > on a 40 core machine will exhibit this perf issue. > > cabal clean ; cabal configure --ghc-options="-j" ; cabal build -j1 > > should be enough to trigger the lock contention. > > That said, I'll try to cook up a minimal repro that i can share the > source for post haste. New description: I'm seeing slowdowns in parallel builds of a (simple!!) 6 module project when I build it on a 40 core server that I'm using for work. For any given ghc invocation with `-jn`, once n>10, I start to see a super-linear slow down as a function of n, here are some basic numbers, ||= =||= compile time =|| || -j1 || 0m2.693s || || -j4 || 0m2.507s || || -j10 || 0m2.763s || || -j25 || 0m12.634s || || -j30 || 0m39.154s || || -j40 || 0m57.511s || || -j60 || 2m21.821s || These timings are another 2-4x worse if ghc is invoked indirectly via cabal-install / `Setup.hs` According to the linux utility latencytop, 100% of ghc's cpu time was spent on user-space lock contention when I did the `-j40` invocation. The timing in the `-j40` case stayed the same even when ghc was also passed `-O0` (and `-fforce-recomp` to ensure it did the same ) A bit of experimentation makes me believe that *any* cabalized project on a 40 core machine will exhibit this performance issue. {{{ cabal clean cabal configure --ghc-options="-j" cabal build -j1 }}} should be enough to trigger the lock contention. That said, I'll try to cook up a minimal repro that i can share the source for post haste. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 1 13:06:58 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 13:06:58 -0000 Subject: [GHC] #11042: Template Haskell / GHCi does not respect extra-lib-dirs In-Reply-To: <044.eb43e7f9b5666e68e3df817728c4c87b@haskell.org> References: <044.eb43e7f9b5666e68e3df817728c4c87b@haskell.org> Message-ID: <059.7e532ebbcc3dec7a9081a9e53cc772be@haskell.org> #11042: Template Haskell / GHCi does not respect extra-lib-dirs -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: bug | 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 crash | Test Case: Blocked By: | Blocking: Related Tickets: #10458 #5289 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by trommler): #10458 has nothing to do with this issue. In #10458 we would like to access a function in a C library specified on the command line. In this ticket GHCi's linker fails to find a shared library that is required by another Haskell package, because the library is installed in a path that is not searched by the operating system's runtime linker. As a workaround you could add the path of `libz.so` to `LD_LIBRARY_PATH`. Suppose, you only want to use Haskell zlib in you Main module, I think GHCi's linker should not try to load `libz.so` at all and merely load the Haskell package's shared library (`libHSzlib<...>.so`). The Haskell shared library contains the appropriate DT_RUNPATH tag pointing to the location of the C library and so it is found and loaded. On ELF systems I would say the fix is to teach `Linker.hs` to not load dependent libraries but rely on the system linker to do the Right Thing. On OS X there are issues with symbols from dependent libraries not being reexported by default. I could look into this once I am done with #10458, but I would rather like to see a document specifying the expected behavior of the GHCi linker and then reimplement it. We also need regression tests for all those special cases! I agree with Austin. The amount of patches starts to smell. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 1 13:36:27 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 13:36:27 -0000 Subject: [GHC] #11017: ApiAnnotations: BooleanFormula is not properly Located In-Reply-To: <044.8a6c3bf330a4eb35f37df8711068c35c@haskell.org> References: <044.8a6c3bf330a4eb35f37df8711068c35c@haskell.org> Message-ID: <059.172fa5c1e2bb9b40a805a48e8d3eca46@haskell.org> #11017: ApiAnnotations: BooleanFormula is not properly Located -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1384 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 1 14:35:24 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 14:35:24 -0000 Subject: [GHC] #11035: Add implicit call-stacks to partial functions in base In-Reply-To: <049.cfaa63a68670a816facc2036509f578c@haskell.org> References: <049.cfaa63a68670a816facc2036509f578c@haskell.org> Message-ID: <064.d6c104d230239d3923ef13b4aa2000c9@haskell.org> #11035: Add implicit call-stacks to partial functions in base -------------------------------------+------------------------------------- Reporter: gridaphobe | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): *Please* do not do this in base, instead provide a separate package that people can use if they want this functionality. I'm concerned about all the points you raise in the description. I don't think I need to expand on them, you've done a great job of explaining the problems this leads to. So this gets a strong -1 from me, at least in base. We should be deeply suspicious about hard-wiring a particular debugging method into the types of core library functions. It just seems entirely wrong. Useful perhaps, but wrong. Let's not forget we have no less than 3 ways to get call stacks, each with advantages and disadvantages: * Profiling * Execution stacks (DWARF) * Implicit call stacks None of these is perfect, where perfect is something like: full call stacks available all the time with no changes to the source code, no performance overhead, and no need to recompile. Each method compromises on one or more of these things. Implicit call stacks are great for finding out where you called 'error' from, but they don't scale up to solve the general problem. We start to need multiple versions of functions, and RULES and magic in Haddock to hide this mess from users. In contrast, you can just compile everything with profiling and get full call stacks, or you can use execution stacks which probably provide enough information in most cases. Neither of these things requires any source-level changes. That's why I think we should stop where we are with implicit call stacks. I should also mention that I'm working on extending profiling to work with GHCi, so people using GHCi will get the benefit of full and detailed call stacks without any changes at the source level. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 1 16:08:22 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 16:08:22 -0000 Subject: [GHC] #11030: D757 (emit Typeable at type definition site) regresses T3294 max_bytes_used by factor of two In-Reply-To: <046.dcbfe5b30aed7ce500ba8edfc26b6702@haskell.org> References: <046.dcbfe5b30aed7ce500ba8edfc26b6702@haskell.org> Message-ID: <061.f4048171d37e3a0760192f1c990806a2@haskell.org> #11030: D757 (emit Typeable at type definition site) regresses T3294 max_bytes_used by factor of two -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: T3294 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: The above commit was incorrect and was ultimately reverted. The idea was merged again in 91c6b1f54aea658b0056caec45655475897f1972, which does not exhibit this regression. I'm not entirely sure why this is the case, although I suspect the phenomenon was due to sloppy test conditions on my part as I have been unable to reproduce the issue. Closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 1 16:36:03 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 16:36:03 -0000 Subject: [GHC] #11045: Loading temp shared object failed - undefined symbol Message-ID: <046.9d39dd7431e7e6dfe6663e1ceca6d812@haskell.org> #11045: Loading temp shared object failed - undefined symbol -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While re-compiling [https://github.com/commercialhaskell/stack stack]: {{{ $ stack install --ghc-options -O2 stack-0.1.7.0: configure Configuring stack-0.1.7.0... stack-0.1.7.0: build Preprocessing library stack-0.1.7.0... [30 of 74] Compiling Stack.Types.Docker ( src/Stack/Types/Docker.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Stack/Types/Docker.o ) [31 of 74] Compiling Options.Applicative.Complicated ( src/Options/Applicative/Complicated.hs, .stack- work/dist/x86_64-linux/Cabal-1.22.4.0/build/Options/Applicative/Complicated.o ) [32 of 74] Compiling Stack.Types.Config ( src/Stack/Types/Config.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Stack/Types/Config.o ) [33 of 74] Compiling Stack.Constants ( src/Stack/Constants.hs, .stack- work/dist/x86_64-linux/Cabal-1.22.4.0/build/Stack/Constants.o ) [Stack.Types.Config changed] [34 of 74] Compiling Stack.Types.Internal ( src/Stack/Types/Internal.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Stack/Types/Internal.o ) [Stack.Types.Config changed] [35 of 74] Compiling Stack.Types.StackT ( src/Stack/Types/StackT.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Stack/Types/StackT.o ) [36 of 74] Compiling Stack.Docker.GlobalDB ( src/Stack/Docker/GlobalDB.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Stack/Docker/GlobalDB.o ) [Stack.Types.Config changed] [37 of 74] Compiling Stack.Types.Package ( src/Stack/Types/Package.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Stack/Types/Package.o ) [Stack.Types.Config changed] [38 of 74] Compiling Stack.Types.Build ( src/Stack/Types/Build.hs, .stack- work/dist/x86_64-linux/Cabal-1.22.4.0/build/Stack/Types/Build.o ) [39 of 74] Compiling Stack.Types ( src/Stack/Types.hs, .stack- work/dist/x86_64-linux/Cabal-1.22.4.0/build/Stack/Types.o ) [Stack.Types.Build changed] [40 of 74] Compiling Stack.GhcPkg ( src/Stack/GhcPkg.hs, .stack- work/dist/x86_64-linux/Cabal-1.22.4.0/build/Stack/GhcPkg.o ) [Stack.Constants changed] [41 of 74] Compiling Stack.PackageIndex ( src/Stack/PackageIndex.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Stack/PackageIndex.o ) [Data.Binary.VersionTagged changed] ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-linux): Loading temp shared object failed: /tmp/ghc22553_0/libghc_96.so: undefined symbol: stackzuFHzzONQT9HI3ATX2xQH198L_StackziTypesziCompiler_zdfBinaryCompilerVersionzuzdszdfGSumM2_closure Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- While building package stack-0.1.7.0 using: /home/simon/.stack/setup-exe-cache/setup-Simple- Cabal-1.22.4.0-x86_64-linux-ghc-7.10.2 --builddir=.stack- work/dist/x86_64-linux/Cabal-1.22.4.0/ build lib:stack exe:stack --ghc- options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 1 $ git show commit 2fb2d11fffddde3c44920f7ea93e34b9d3195dad Author: Emanuel Borsboom Date: Sun Nov 1 05:21:16 2015 -0800 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 1 16:57:26 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 16:57:26 -0000 Subject: [GHC] #11021: Document best practices for bringing up Sphinx on Windows In-Reply-To: <046.0c4621633ac4967e9cb5eee4e02186fd@haskell.org> References: <046.0c4621633ac4967e9cb5eee4e02186fd@haskell.org> Message-ID: <061.a71b538eac0e4ad78fe2a6adce719102@haskell.org> #11021: Document best practices for bringing up Sphinx on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: patch Priority: normal | Milestone: 8.0.1 Component: Documentation | Version: 7.11 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1408 Wiki Page: | Phab:D1417 -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => patch * differential: Phab:D1408 => Phab:D1408 Phab:D1417 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 1 16:57:43 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 16:57:43 -0000 Subject: [GHC] #11021: Document best practices for bringing up Sphinx on Windows In-Reply-To: <046.0c4621633ac4967e9cb5eee4e02186fd@haskell.org> References: <046.0c4621633ac4967e9cb5eee4e02186fd@haskell.org> Message-ID: <061.d3cfa5cf4b12558982d59ced923220ce@haskell.org> #11021: Document best practices for bringing up Sphinx on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Phyx- Type: task | Status: patch Priority: normal | Milestone: 8.0.1 Component: Documentation | Version: 7.11 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1408 Wiki Page: | Phab:D1417 -------------------------------------+------------------------------------- Changes (by Phyx-): * owner: => Phyx- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 1 18:13:01 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 18:13: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.5e9cc70b3d89f3d67224ccbda4a67836@haskell.org> #10365: Implement Semigroup as a superclass of Monoid Proposal (Phase 1) -------------------------------------+------------------------------------- Reporter: gidyn | Owner: quchen 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 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): @rwbarton: The short version of it is this: We have `mconcat` for `Monoid` today. It actually sees a fair bit of use and I've seen folks implement it in the wild to do things like Kahan summation or better short circuiting than the base monoid can (it gets to assume an associativity.) `fold` gets to know the container, `mconcat` gets to know the Monoid. The moral equivalent in `Semigroup` requires some form of canonical non- empty type to fold over. The net effect of removing it is that the `semigroups` package would continue to exist just to supply this type, the class would lose its canonical structure to fold over, and `sconcat` becomes unimplementable. Why should moving `Semigroup` into `base` cost users functionality? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 1 18:23:52 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 18:23:52 -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.5b025a76f744cbedcc780b5b2a381efe@haskell.org> #10365: Implement Semigroup as a superclass of Monoid Proposal (Phase 1) -------------------------------------+------------------------------------- Reporter: gidyn | Owner: quchen 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 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Lemming): Replying to [comment:31 ekmett]: > The moral equivalent in `Semigroup` requires some form of canonical non- empty type to fold over. The net effect of removing it is that the `semigroups` package would continue to exist just to supply this type, the class would lose its canonical structure to fold over, and `sconcat` becomes unimplementable. `sconcat` in base could have type `s -> [s] -> s`. Then there is no need for `NonEmpty` to be in `base` and people can define top-level functions that use `sconcat` to implement a counterpart for their favourite `NonEmpty` type (e.g. `Data.List.NonEmpty` or `Data.NonEmpty`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 1 18:27:13 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 18:27:13 -0000 Subject: [GHC] #11021: Document best practices for bringing up Sphinx on Windows In-Reply-To: <046.0c4621633ac4967e9cb5eee4e02186fd@haskell.org> References: <046.0c4621633ac4967e9cb5eee4e02186fd@haskell.org> Message-ID: <061.2f27aa20f71dda8675687dad20ba5432@haskell.org> #11021: Document best practices for bringing up Sphinx on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Phyx- Type: task | Status: patch Priority: normal | Milestone: 8.0.1 Component: Documentation | Version: 7.11 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1408 Wiki Page: | Phab:D1417 -------------------------------------+------------------------------------- Comment (by Tamar Christina ): In [changeset:"65f3c4c0a1304b8d00b46dc0e77ad93fc566ffb1/ghc" 65f3c4c0/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="65f3c4c0a1304b8d00b46dc0e77ad93fc566ffb1" Change sphinx for documentation building on windows to the python3 version Summary: Python 3 seems to have fixed the long standing codepage issue with python on Windows. To be able to reliably build the documentation we should use the Python 3 version of Sphinx. See `https://docs.python.org/dev/whatsnew/3.3.html#codecs` and `https://bugs.python.org/issue13216`. Sphinx also supports Python 3. Oddly enough `python3-sphinx` is registered as `sphinx-build.exe` instead of `sphinx-build3.exe`, so the changes in `configure.ac` can be reverted. install with `pacman -S mingw-w64-$(uname -m)-python3-sphinx` Test Plan: ./validate Reviewers: austin, thomie, bgamari Reviewed By: bgamari Subscribers: erikd Differential Revision: https://phabricator.haskell.org/D1417 GHC Trac Issues: #11021 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 1 18:28:18 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 18:28:18 -0000 Subject: [GHC] #11021: Document best practices for bringing up Sphinx on Windows In-Reply-To: <046.0c4621633ac4967e9cb5eee4e02186fd@haskell.org> References: <046.0c4621633ac4967e9cb5eee4e02186fd@haskell.org> Message-ID: <061.23070f3f4bac01141035fd03cc96210c@haskell.org> #11021: Document best practices for bringing up Sphinx on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Phyx- Type: task | Status: closed Priority: normal | Milestone: 8.0.1 Component: Documentation | Version: 7.11 Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1408 Wiki Page: | Phab:D1417 -------------------------------------+------------------------------------- Changes (by Phyx-): * status: patch => closed * resolution: => fixed Comment: Should now be really fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 1 18:34:57 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 18:34:57 -0000 Subject: [GHC] #11041: EventLog write fails if entire buffer is not written In-Reply-To: <049.1dbeaea4e627c4c0bcd66b984b44ecbf@haskell.org> References: <049.1dbeaea4e627c4c0bcd66b984b44ecbf@haskell.org> Message-ID: <064.de8ecb40943bb0200d24e29b89f546f5@haskell.org> #11041: EventLog write fails if entire buffer is not written -------------------------------------+------------------------------------- Reporter: sseverance | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: eventlog Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1415 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"f46f32b922d7ecbee2829937295521f5db1d7997/ghc" f46f32b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f46f32b922d7ecbee2829937295521f5db1d7997" EventLog: Loop fwrite if necessary during flush Previously the eventlog flush code would fail if `fwrite` wrote less than the requested amount. Like all Unix stream I/O operations, however, `fwrite` isn't guaranteed to write the entire buffer. Here we loop as long as `fwrite` succeeds in writing anything. Fixes #11041. Test Plan: Validate with eventlog Reviewers: austin, simonmar Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1415 GHC Trac Issues: #11041 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 1 18:58:57 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 18:58:57 -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.fc1fab6f7d4d69fca49cc675b3c9f21d@haskell.org> #10365: Implement Semigroup as a superclass of Monoid Proposal (Phase 1) -------------------------------------+------------------------------------- Reporter: gidyn | Owner: quchen 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 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): Lemming: It is clear that any choice that includes it won't make you happy. However, randomly carving it up into two pieces and changing the API ensures that nobody who has existing code that supplies an `sconcat` in their instances winds up with code that will work across the transition. `semigroups` is the most downloaded package in all of Hackage, I don't like the idea of randomly bikeshedding the API here to get an end state that is less useful and which ensures work on the behalf of every package maintainer who currently implements `sconcat`. The transition story is better if we include it than if we don't, and the result is more usable out of the box. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 1 19:13:14 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 19:13:14 -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.ae0ab98636aa119a7adb359232a39ce0@haskell.org> #10365: Implement Semigroup as a superclass of Monoid Proposal (Phase 1) -------------------------------------+------------------------------------- Reporter: gidyn | Owner: quchen 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 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Yes, just give `sconcat` type `s -> [s] -> s`. A module being included in a package that is a dependency of a popular package is not a compelling reason to move that module into `base`! I mean I don't even know what to say to that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 1 19:59:11 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 19:59:11 -0000 Subject: [GHC] #11035: Add implicit call-stacks to partial functions in base In-Reply-To: <049.cfaa63a68670a816facc2036509f578c@haskell.org> References: <049.cfaa63a68670a816facc2036509f578c@haskell.org> Message-ID: <064.42052aa53758981d8ba859509cc76302@haskell.org> #11035: Add implicit call-stacks to partial functions in base -------------------------------------+------------------------------------- Reporter: gridaphobe | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gridaphobe): Replying to [comment:12 simonmar]: > *Please* do not do this in base, instead provide a separate package that people can use if they want this functionality. > > I'm concerned about all the points you raise in the description. I don't think I need to expand on them, you've done a great job of explaining the problems this leads to. So this gets a strong -1 from me, at least in base. Noted. I actually do have a separate package that exports location-aware variants of common partial functions (https://hackage.haskell.org/package /located-base), and I don't mind keeping the broader use of CallStacks out of base. I opened this ticket primarily because I'm not very satisfied with the error produced in the description: {{{ ghci> minimumBy compare [] *** Exception: Prelude.foldr1: empty list CallStack: error, called at libraries/base/GHC/List.hs:999:3 in base-4.8.2.0:GHC.List }}} This CallStack adds no value to the error (since `foldr1` is already identified as the culprit), but does add a fair bit of noise. Adding more CallStacks would make this error much more useful, but it doesn't sound like that will happen at this point. The other thing we could do is suppress CallStacks inside base. We'd still export a CallStack-enhanced `error` and `undefined`, we just wouldn't use them internally. Do you think the error message would be better without the partial CallStack, or does it seem more like a non-issue? ------------ > I should also mention that I'm working on extending profiling to work with GHCi, so people using GHCi will get the benefit of full and detailed call stacks without any changes at the source level. Is there a ticket for this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 1 20:03:55 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 20:03:55 -0000 Subject: [GHC] #11035: Add implicit call-stacks to partial functions in base In-Reply-To: <049.cfaa63a68670a816facc2036509f578c@haskell.org> References: <049.cfaa63a68670a816facc2036509f578c@haskell.org> Message-ID: <064.3dfc0615a61f8291aa1f0bb4c2548686@haskell.org> #11035: Add implicit call-stacks to partial functions in base -------------------------------------+------------------------------------- Reporter: gridaphobe | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gridaphobe): Replying to [comment:10 goldfire]: > Replying to [comment:5 nomeata]: > > In fact, what I do not like about > > {{{ > > ghci> minimumBy compare [] > > *** Exception: Prelude.foldr1: empty list > > CallStack: > > error, called at libraries/base/GHC/List.hs:999:3 in base-4.8.2.0:GHC.List > > }}} > > is that it leaks implementation details. This is great in your own code, but a polished library should _not_ leak a call stack about its details; it should either print plain exception or the call stack that finishes at the library?s API. At least for ?expected exceptions? like `"empty list"`. > > I disagree with this push toward perfection. I understand what you're getting at here, and I agree in principle. But I think this issue (which does seem to be independent from the original ticket) is not terribly important to solve. In other languages, I've seen standard libraries spill their implementation details all over the place in stack traces. I'm generally inclined to agree that there's no harm in spilling implementation details in the stack trace, I can't think of a single language that lets you do what Joachim is suggesting. That being said, it sounds like it could be a very lightweight extension of the existing machinery, so it might be interesting to experiment with. But it probably should be a separate ticket :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 1 20:11:34 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 20:11:34 -0000 Subject: [GHC] #11046: lookupTypeName does not support type operators Message-ID: <045.eabc8eeec9cc920f3e0838e9774eff4d@haskell.org> #11046: lookupTypeName does not support type operators -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.10.2 Haskell | 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): | Wiki Page: -------------------------------------+------------------------------------- The following non-working code (minus a missing import) was [http://stackoverflow.com/questions/33465109/template-haskell-how-to- lookup-type-operator-name posted on stackoverflow]: `IssueTH.hs`: {{{#!hs {-# LANGUAGE TemplateHaskell #-} module IssueTH where import Language.Haskell.TH f :: Q [Dec] f = do Just n <- lookupTypeName "GHC.TypeLits.*" return [] }}} `Issue.hs`: {{{#!hs {-# LANGUAGE TemplateHaskell #-} module Issue where import IssueTH import GHC.TypeLits $f }}} `ghc Issue.hs` fails with message: `Pattern match failure in do expression at IssueTH.hs:7:5-10` This gives no error if `*` is replaced by an alphanumeric type like `Nat`. Similar tests seem to fail whenever attempting to look up a type operator with `lookupTypeName`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 1 20:27:40 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 20:27:40 -0000 Subject: [GHC] #11046: lookupTypeName does not support type operators In-Reply-To: <045.eabc8eeec9cc920f3e0838e9774eff4d@haskell.org> References: <045.eabc8eeec9cc920f3e0838e9774eff4d@haskell.org> Message-ID: <060.b59b2d9081717028e2ac69c736da58d2@haskell.org> #11046: lookupTypeName does not support type operators -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.2 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by oerjan): On a hunch I did a further test: `lookupTypeName` ''does'' work with a type operator if it starts with `:`. A bit more flexible test file: {{{#!hs {-# LANGUAGE TemplateHaskell #-} module IssueTH where import Language.Haskell.TH f :: String -> Q [Dec] f n = do Just n <- lookupTypeName n return [] }}} And then in GHCi: {{{ *IssueTH> :set -XTypeOperators *IssueTH> :set -XTemplateHaskell *IssueTH> data a :& b = A *IssueTH> data a & b = B *IssueTH> data Dummy; $(f ":&") *IssueTH> data Dummy; $(f "&") :7:15: Pattern match failure in do expression at IssueTH.hs:9:5-10 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 1 20:31:52 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 20:31:52 -0000 Subject: [GHC] #11046: lookupTypeName does not support type operators not starting with : (was: lookupTypeName does not support type operators) In-Reply-To: <045.eabc8eeec9cc920f3e0838e9774eff4d@haskell.org> References: <045.eabc8eeec9cc920f3e0838e9774eff4d@haskell.org> Message-ID: <060.3732f7b69617f59945a30bc71cf12465@haskell.org> #11046: lookupTypeName does not support type operators not starting with : -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.2 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): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 1 21:10:23 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 21:10:23 -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.cca931581cc1927fc083dbd79271792e@haskell.org> #10365: Implement Semigroup as a superclass of Monoid Proposal (Phase 1) -------------------------------------+------------------------------------- Reporter: gidyn | Owner: quchen 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 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): Both are reasonable colors for this bikeshed, but one doesn't break users. I'll refer this to the rest of the CLC to get a judgment. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 1 21:30:54 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 21:30:54 -0000 Subject: [GHC] #11047: Provide call stacks in GHCi Message-ID: <047.3eb9c7a7d6579e45d15f3dffd3ade555@haskell.org> #11047: Provide call stacks in GHCi -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #545, #4837 Differential Rev(s): Phab:D1407 | Wiki Page: -------------------------------------+------------------------------------- I want call stacks to be available in GHCi with no effort on the part of the user, or changes to the source code. The call stack will be available both programatically and via GHCi commands: * `GHC.Stack.currentCallStack` returns the current call stack as `[String]`. This can be used from `error` and copied into the exception string. * `Debug.Trace.traceStack` prints out the stack anywhere. * GHCi will have a new command `:where` to print out the stack when stopped at a breakpoint The stack trace will be the accurate (i.e. not exposing details of lazy evaluation or tail calls) and detailed (including locations of calls, not just the enclosing function definition). = Implmeentation = Here's how it's going to work: * We make GHCi work with profiling (done: Phab:D1407) * We make breakpoint ticks behave like SCC annotations, and update the interpreter to implement the cost-centre-stack semantics. = Exmaple = Here's an example from my prototype: {{{ g :: Int -> [Int] g n = traceStack "g" [n] h :: Int -> Bool h n = case g n of [] -> True (x:xs) -> False map :: (a -> b) -> [a] -> [b] map f [] = [] map f (x:xs) = f x : map f xs k n = map h [n] }}} {{{ [1 of 1] Compiling Main ( /home/smarlow/scratch/dbg1.hs, interpreted ) Ok, modules loaded: Main. *Main> k 1 [g Stack trace: Main.g (/home/smarlow/scratch/dbg1.hs:13:7-24) Main.g (/home/smarlow/scratch/dbg1.hs:13:1-24) Main.h (/home/smarlow/scratch/dbg1.hs:16:12-14) Main.h (/home/smarlow/scratch/dbg1.hs:(16,7)-(18,24)) Main.h (/home/smarlow/scratch/dbg1.hs:(16,1)-(18,24)) Main.map (/home/smarlow/scratch/dbg1.hs:22:16-18) Main.map (/home/smarlow/scratch/dbg1.hs:22:16-29) Main.map (/home/smarlow/scratch/dbg1.hs:(21,1)-(22,29)) Main.k (/home/smarlow/scratch/dbg1.hs:24:7-15) Main.k (/home/smarlow/scratch/dbg1.hs:24:1-15) False] *Main> }}} We could trim some of the extra detail from the stack trace so that each function appears once; there are several choices here, currently I'm collecting and displaying the most detail. = Deployment = One disadvantage of this is that it requires GHCi to be built with profiling, and all the libraries have to be built with profiling too. There are two options for deployment: 1. We deploy two versions of GHCi (profiled and non-profiled), or 2. We expand on what GHCJS did, and make the interpreted code run in a separate process, thus separating the GHCi binary itself from the code being interpreted. This would allow the interpreted code to be run with the profiled RTS while GHCi itself is unprofiled. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 1 21:37:31 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 21:37:31 -0000 Subject: [GHC] #11041: EventLog write fails if entire buffer is not written In-Reply-To: <049.1dbeaea4e627c4c0bcd66b984b44ecbf@haskell.org> References: <049.1dbeaea4e627c4c0bcd66b984b44ecbf@haskell.org> Message-ID: <064.cb99b9d3533c2da3d921d259306536dc@haskell.org> #11041: EventLog write fails if entire buffer is not written -------------------------------------+------------------------------------- Reporter: sseverance | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: eventlog Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1415 Wiki Page: | -------------------------------------+------------------------------------- Comment (by sseverance): I observed this on CentOS 7. Thanks for the prompt response. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 1 21:38:35 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 21:38:35 -0000 Subject: [GHC] #11035: Add implicit call-stacks to partial functions in base In-Reply-To: <049.cfaa63a68670a816facc2036509f578c@haskell.org> References: <049.cfaa63a68670a816facc2036509f578c@haskell.org> Message-ID: <064.29b664d1fd335abf5c1d061364773b63@haskell.org> #11035: Add implicit call-stacks to partial functions in base -------------------------------------+------------------------------------- Reporter: gridaphobe | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): > Do you think the error message would be better without the partial CallStack, or does it seem more like a non-issue? We could have a non-callstack version of error, and use that from `minimumBy` and other functions in base that call `error`? > > I should also mention that I'm working on extending profiling to work with GHCi, so people using GHCi will get the benefit of full and detailed call stacks without any changes at the source level. > Is there a ticket for this? I just made one: #11047 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 1 21:40:12 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 21:40:12 -0000 Subject: [GHC] #11047: Provide call stacks in GHCi In-Reply-To: <047.3eb9c7a7d6579e45d15f3dffd3ade555@haskell.org> References: <047.3eb9c7a7d6579e45d15f3dffd3ade555@haskell.org> Message-ID: <062.a2aaaa6718139a435c99408f24cf34e0@haskell.org> #11047: Provide call stacks in GHCi -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #545, #4837 | Differential Rev(s): Phab:D1407 Wiki Page: | -------------------------------------+------------------------------------- Changes (by gridaphobe): * cc: gridaphobe (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 1 21:43:25 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 21:43:25 -0000 Subject: [GHC] #11047: Provide call stacks in GHCi In-Reply-To: <047.3eb9c7a7d6579e45d15f3dffd3ade555@haskell.org> References: <047.3eb9c7a7d6579e45d15f3dffd3ade555@haskell.org> Message-ID: <062.06498f4c7e86ad4f6a67fcfa503e8b50@haskell.org> #11047: Provide call stacks in GHCi -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #545, #4837 | Differential Rev(s): Phab:D1407 Wiki Page: | -------------------------------------+------------------------------------- Description changed by simonmar: Old description: > I want call stacks to be available in GHCi with no effort on the part of > the user, or changes to the source code. The call stack will be > available both programatically and via GHCi commands: > > * `GHC.Stack.currentCallStack` returns the current call stack as > `[String]`. This can be used from `error` and copied into the exception > string. > * `Debug.Trace.traceStack` prints out the stack anywhere. > * GHCi will have a new command `:where` to print out the stack when > stopped at a breakpoint > > The stack trace will be the accurate (i.e. not exposing details of lazy > evaluation or tail calls) and detailed (including locations of calls, not > just the enclosing function definition). > > = Implmeentation = > > Here's how it's going to work: > > * We make GHCi work with profiling (done: Phab:D1407) > * We make breakpoint ticks behave like SCC annotations, and update the > interpreter to implement the cost-centre-stack semantics. > > = Exmaple = > > Here's an example from my prototype: > > {{{ > g :: Int -> [Int] > g n = traceStack "g" [n] > > h :: Int -> Bool > h n = case g n of > [] -> True > (x:xs) -> False > > map :: (a -> b) -> [a] -> [b] > map f [] = [] > map f (x:xs) = f x : map f xs > > k n = map h [n] > }}} > > {{{ > [1 of 1] Compiling Main ( /home/smarlow/scratch/dbg1.hs, > interpreted ) > Ok, modules loaded: Main. > *Main> k 1 > [g > Stack trace: > Main.g (/home/smarlow/scratch/dbg1.hs:13:7-24) > Main.g (/home/smarlow/scratch/dbg1.hs:13:1-24) > Main.h (/home/smarlow/scratch/dbg1.hs:16:12-14) > Main.h (/home/smarlow/scratch/dbg1.hs:(16,7)-(18,24)) > Main.h (/home/smarlow/scratch/dbg1.hs:(16,1)-(18,24)) > Main.map (/home/smarlow/scratch/dbg1.hs:22:16-18) > Main.map (/home/smarlow/scratch/dbg1.hs:22:16-29) > Main.map (/home/smarlow/scratch/dbg1.hs:(21,1)-(22,29)) > Main.k (/home/smarlow/scratch/dbg1.hs:24:7-15) > Main.k (/home/smarlow/scratch/dbg1.hs:24:1-15) > False] > *Main> > }}} > > We could trim some of the extra detail from the stack trace so that each > function appears once; there are several choices here, currently I'm > collecting and displaying the most detail. > > = Deployment = > > One disadvantage of this is that it requires GHCi to be built with > profiling, and all the libraries have to be built with profiling too. > There are two options for deployment: > > 1. We deploy two versions of GHCi (profiled and non-profiled), or > 2. We expand on what GHCJS did, and make the interpreted code run in a > separate process, thus separating the GHCi binary itself from the code > being interpreted. This would allow the interpreted code to be run with > the profiled RTS while GHCi itself is unprofiled. New description: I want call stacks to be available in GHCi with no effort on the part of the user, or changes to the source code. The call stack will be available both programatically and via GHCi commands: * `GHC.Stack.currentCallStack` returns the current call stack as `[String]`. This can be used from `error` and copied into the exception string. * `Debug.Trace.traceStack` prints out the stack anywhere. * GHCi will have a new command `:where` to print out the stack when stopped at a breakpoint The stack trace will be the accurate (i.e. not exposing details of lazy evaluation or tail calls) and detailed (including locations of calls, not just the enclosing function definition). = Implementation = Here's how it's going to work: * We make GHCi work with profiling (done: Phab:D1407) * We make breakpoint ticks behave like SCC annotations, and update the interpreter to implement the cost-centre-stack semantics. = Example = Here's an example from my prototype: {{{ g :: Int -> [Int] g n = traceStack "g" [n] h :: Int -> Bool h n = case g n of [] -> True (x:xs) -> False map :: (a -> b) -> [a] -> [b] map f [] = [] map f (x:xs) = f x : map f xs k n = map h [n] }}} {{{ [1 of 1] Compiling Main ( /home/smarlow/scratch/dbg1.hs, interpreted ) Ok, modules loaded: Main. *Main> k 1 [g Stack trace: Main.g (/home/smarlow/scratch/dbg1.hs:13:7-24) Main.g (/home/smarlow/scratch/dbg1.hs:13:1-24) Main.h (/home/smarlow/scratch/dbg1.hs:16:12-14) Main.h (/home/smarlow/scratch/dbg1.hs:(16,7)-(18,24)) Main.h (/home/smarlow/scratch/dbg1.hs:(16,1)-(18,24)) Main.map (/home/smarlow/scratch/dbg1.hs:22:16-18) Main.map (/home/smarlow/scratch/dbg1.hs:22:16-29) Main.map (/home/smarlow/scratch/dbg1.hs:(21,1)-(22,29)) Main.k (/home/smarlow/scratch/dbg1.hs:24:7-15) Main.k (/home/smarlow/scratch/dbg1.hs:24:1-15) False] *Main> }}} We could trim some of the extra detail from the stack trace so that each function appears once; there are several choices here, currently I'm collecting and displaying the most detail. = Deployment = One disadvantage of this is that it requires GHCi to be built with profiling, and all the libraries have to be built with profiling too. There are two options for deployment: 1. We deploy two versions of GHCi (profiled and non-profiled), or 2. We expand on what GHCJS did, and make the interpreted code run in a separate process, thus separating the GHCi binary itself from the code being interpreted. This would allow the interpreted code to be run with the profiled RTS while GHCi itself is unprofiled. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 1 21:47:53 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 21:47:53 -0000 Subject: [GHC] #11035: Add implicit call-stacks to partial functions in base In-Reply-To: <049.cfaa63a68670a816facc2036509f578c@haskell.org> References: <049.cfaa63a68670a816facc2036509f578c@haskell.org> Message-ID: <064.e870833aba7ddc37f705843aaccb599a@haskell.org> #11035: Add implicit call-stacks to partial functions in base -------------------------------------+------------------------------------- Reporter: gridaphobe | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gridaphobe): Replying to [comment:15 simonmar]: > We could have a non-callstack version of error, and use that from `minimumBy` and other functions in base that call `error`? Yes, that's the idea. We could even add a one-off version of Richard's RULE to optimize away the callstacks for `error` in distributed code, which I think would make Joachim happier. I'm just wondering if the cosmetic issue is enough to warrant the extra (probably small) maintenance burden. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 1 22:41:45 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 22:41:45 -0000 Subject: [GHC] #11048: Kind Incompatibility in GHC 7.6.3 Message-ID: <048.64915df854801a709c1b855460eb8fbc@haskell.org> #11048: Kind Incompatibility in GHC 7.6.3 ----------------------------------------+--------------------------------- Reporter: skatenerd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- In [https://github.com/skatenerd/vectorracing/commit/ddb950a3c89f7ba5aae84050d278a643769d3a5e this commit] I have added a line with an intentionally missing dollar- sign. This should result in a mundane build failure, but instead, GHC produces this message: {{{ src/Main.hs:50:3: Couldn't match kind `* -> *' with `*' Expected type: Window -> Maybe Integer -> t0 Curses (Maybe Event) Actual type: Window -> Maybe Integer -> t0 Curses (Maybe Event) Kind incompatibility when matching types: Window :: * -> * Window :: * The function `lift'ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-unknown-linux): kindFunResult ghc-prim:GHC.Prim.*{(w) tc 34d} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 1 22:59:03 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 22:59:03 -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.61bffc1c7876e355d3c27d177dbefe46@haskell.org> #10365: Implement Semigroup as a superclass of Monoid Proposal (Phase 1) -------------------------------------+------------------------------------- Reporter: gidyn | Owner: quchen 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 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): I follow ekmett?s argument that Monoid to [] is like semigroups to ?, and to me it makes sense of have a type for non-empty sets in base. (If having a slim base were a goal, then maybe not, but I don?t see that being a goal for the community in general). But it is true that things are harder to fix once they are in base, so we should aim to pick the ?right? implementation. According to https://wiki.haskell.org/Non-empty_list#Packages there are 6(!) implementations of non-empty lists on hackage. I did not look at them right now, so I?ll lazily pose the question: Is there any good reason to prefer any of these over the implementation from `semigroups`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 1 23:03:08 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 23:03:08 -0000 Subject: [GHC] #11049: Allow CallStacks to be hidden or cut Message-ID: <046.99c74047c61a8c0886c2d3ab954b8b7d@haskell.org> #11049: Allow CallStacks to be hidden or cut -------------------------------------+------------------------------------- Reporter: nomeata | 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: #11035 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is a spin off of #11035. I?d like to see a way for a function `foo` * use another function `bar` with a `(?_::CallStack)` constraint so that `bar` will _not_ print a call stack, and * use another function `bar` with a `(?_::CallStack)` constraint so that if `bar` prints a call stack, it will stop at the call to `foo`. This might be possible to implement with a special `rootCallStack :: CallStack` which is a value such that {{{ x `pushCallStack` rootCallStack = rootCallStack }}} but {{{ rootCallStack `pushCallStack` x = rootCallStack ?:? x }}} as before and a call stack that consists of only a rootCallStack causes no stack trace to be printed. The use case is to provide the user of a library less cluttered call stacks that do not expose unhelpful details and allow her to quickly spot the relevant information. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 1 23:05:36 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 23:05:36 -0000 Subject: [GHC] #11035: Add implicit call-stacks to partial functions in base In-Reply-To: <049.cfaa63a68670a816facc2036509f578c@haskell.org> References: <049.cfaa63a68670a816facc2036509f578c@haskell.org> Message-ID: <064.cd8b5aaa4414df3583c54f2245b942b2@haskell.org> #11035: Add implicit call-stacks to partial functions in base -------------------------------------+------------------------------------- Reporter: gridaphobe | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): > I'm generally inclined to agree that there's no harm in spilling implementation details in the stack trace, I can't think of a single language that lets you do what Joachim is suggesting. Since when has that become an argument _against_ a change? Especially if no one else is doing it, then we should be doing it ;-) > That being said, it sounds like it could be a very lightweight extension of the existing machinery, so it might be interesting to experiment with. But it probably should be a separate ticket :) Agreed; #11049. If that is implemented you might use that machinery to fix this bug without having to maintain two variants of error, as you can suppress the CallStack at the point where error (or `foldl1`) is called. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 1 23:17:01 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 23:17:01 -0000 Subject: [GHC] #11049: Allow CallStacks to be hidden or cut In-Reply-To: <046.99c74047c61a8c0886c2d3ab954b8b7d@haskell.org> References: <046.99c74047c61a8c0886c2d3ab954b8b7d@haskell.org> Message-ID: <061.cbd7392204418e88d826935cbecfc974@haskell.org> #11049: Allow CallStacks to be hidden or cut -------------------------------------+------------------------------------- Reporter: nomeata | Owner: gridaphobe 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: #11035 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by gridaphobe): * owner: => gridaphobe -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 1 23:18:11 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Nov 2015 23:18:11 -0000 Subject: [GHC] #5642: Deriving Generic of a big type takes a long time and lots of space In-Reply-To: <049.904645e363a227f735eb4cfb7fbae513@haskell.org> References: <049.904645e363a227f735eb4cfb7fbae513@haskell.org> Message-ID: <064.a2b2970342ee1c586e079230a101c044@haskell.org> #5642: Deriving Generic of a big type takes a long time and lots of space -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: T5642 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ghorn): * cc: gregmainland@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 2 02:19:25 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Nov 2015 02:19:25 -0000 Subject: [GHC] #11048: Kind Incompatibility in GHC 7.6.3 In-Reply-To: <048.64915df854801a709c1b855460eb8fbc@haskell.org> References: <048.64915df854801a709c1b855460eb8fbc@haskell.org> Message-ID: <063.66eb292ac09d86f34d0430a7d056839b@haskell.org> #11048: Kind Incompatibility in GHC 7.6.3 ---------------------------------+---------------------------------------- Reporter: skatenerd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by skatenerd): Minimal example: https://gist.github.com/skatenerd/4fcc99434c901e8ef373 You have to have the ncurses library installed... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 2 02:48:31 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Nov 2015 02:48:31 -0000 Subject: [GHC] #11050: [bug] ModOrigin: hidden module redefined Message-ID: <049.f4e3e81343960e7ba9d67c8e78ae8ab2@haskell.org> #11050: [bug] ModOrigin: hidden module redefined -------------------------------------+------------------------------------- Reporter: codeonwort | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs 1 import Haste 2 import Haste.DOM 3 import Haste.Graphics.Canvas 4 import Control.Monad 5 6 mkCanvas width height = do 7 canvas <- newElem "canvas" 8 setProp canvas "width" $ show width 9 setProp canvas "height" $ show height 10 let conf = [("display", "block"), ("border", "1px solid black"), ("margin", "0px auto 0 aut o"), ("backgroundColor", "black")] 11 mapM_ (\(style, value) -> setStyle canvas style value) conf 12 return canvas 13 14 picture = fill $ rect (0, 0) (600, 600) 15 16 main = do 17 canv <- mkCanvas 600 600 18 addChild canv documentBody 19 Just canv <- getCanvas canv 20 render canv picture }}} ------------------------------------------------------------------------ hello.hs:18:3: Warning:hastec: hastec: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-linux): ModOrigin: hidden module redefined Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug ------------------------------------------------------------------------ I was following the tutorial on http://ifeanyi.co/posts/client-side- haskell/ and got this bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 2 04:05:59 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Nov 2015 04:05:59 -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.7ece63e259f5da7de572b2f4f22c45ad@haskell.org> #10365: Implement Semigroup as a superclass of Monoid Proposal (Phase 1) -------------------------------------+------------------------------------- Reporter: gidyn | Owner: quchen 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 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): @nomeata: FWIW- the implementation in `semigroups` was crafted by mixing and matching parts between the 2-3 implementations of non-empty lists at the time. The skeleton of it was build mostly by raiding the `NonEmptyList` package for parts with permission of the owners. AFAIK, Tony has deprecated his `NonEmptyList` package in favor of the one in `semigroups` (hence the lack of updates in the last 5 years -- this changeover predated having any deprecation mechanism on hackage.) Robin Kay's `NonEmpty` package is just a data type with no instances and no methods, also 6 years old. Cardinality also hasn't seen a patch in 6 years. Remarkably it still builds, because it too simply provides no instances. `MinLen` requires a ton of type system extensions. Out of the things that are suitable to consider as a `base`-ready encoding of a non-empty list, only Henning's `Data.NonEmpty` is actively maintained, and it tackles a more general problem, and brings with it a dozen different ad hoc classes for inserts and the like. So if you're hunting for materials to use to rebuild the bikeshed completely, I'd say out of the packages on hackage today, that is the only real source of lumber. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 2 07:30:39 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Nov 2015 07:30:39 -0000 Subject: [GHC] #11046: lookupTypeName does not support type operators not starting with : In-Reply-To: <045.eabc8eeec9cc920f3e0838e9774eff4d@haskell.org> References: <045.eabc8eeec9cc920f3e0838e9774eff4d@haskell.org> Message-ID: <060.3fd2fe6183c38c78eabe6f8068f761d2@haskell.org> #11046: lookupTypeName does not support type operators not starting with : -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.2 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by vagarenko): * cc: vagarenko (added) * priority: normal => high * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 2 08:35:48 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Nov 2015 08:35:48 -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.dea02e9ff0363c0a10c69e9d9dc8263d@haskell.org> #10365: Implement Semigroup as a superclass of Monoid Proposal (Phase 1) -------------------------------------+------------------------------------- Reporter: gidyn | Owner: quchen 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 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Right. `Data.NonEmpty` looks interesting, but a tad too interesting for a plain non-empty-list-type suitable for base. With all the others, the data type definition is equivalent, and rest of the API seems to be straight forward to me. So I have no qualms about this particular color of the shed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 2 08:56:03 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Nov 2015 08:56:03 -0000 Subject: [GHC] #11051: GHCi with +t option set shows type representations Message-ID: <046.80bf6e2eddeb6b8db1c64cf901c24623@haskell.org> #11051: GHCi with +t option set shows type representations -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- hvr reported this morning that defining a data type in GHCi with the show types (`:set +t`) option set results in additional unexpected output. For instance, {{{ $ inplace/bin/ghc-stage2 --interactive GHCi, version 7.11.20151101: http://www.haskell.org/ghc/ :? for help Prelude> :set +t Prelude> data Hi $tcHi :: TyCon $trModule :: Module data Hi Prelude> }}} The `$tcHi` and `$trModule` bindings are details of the Typeable implementation introduced in Phab:D1404 and should likely be hidden from the user. This would be trivial to fix except for the fact that we currently have no way to identify this sort of `Name`. In fact any knowledge that the name was generated appears to have been thrown away as early as `OccName.mkTyConRepSysOcc`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 2 09:02:20 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Nov 2015 09:02:20 -0000 Subject: [GHC] #11051: GHCi with +t option set shows type representations In-Reply-To: <046.80bf6e2eddeb6b8db1c64cf901c24623@haskell.org> References: <046.80bf6e2eddeb6b8db1c64cf901c24623@haskell.org> Message-ID: <061.6ff52abef9f0d2ef4193616ef1439b0b@haskell.org> #11051: GHCi with +t option set shows type representations -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > hvr reported this morning that defining a data type in GHCi with the show > types (`:set +t`) option set results in additional unexpected output. For > instance, > > {{{ > $ inplace/bin/ghc-stage2 --interactive > GHCi, version 7.11.20151101: http://www.haskell.org/ghc/ :? for help > Prelude> :set +t > Prelude> data Hi > $tcHi :: TyCon > $trModule :: Module > data Hi > Prelude> > }}} > > The `$tcHi` and `$trModule` bindings are details of the Typeable > implementation introduced in Phab:D1404 and should likely be hidden from > the user. > > This would be trivial to fix except for the fact that we currently have > no way to identify this sort of `Name`. In fact any knowledge that the > name was generated appears to have been thrown away as early as > `OccName.mkTyConRepSysOcc`. New description: hvr reported this morning that defining a data type in GHCi with the show types (`:set +t`) option set results in additional unexpected output. For instance, {{{ $ inplace/bin/ghc-stage2 --interactive GHCi, version 7.11.20151101: http://www.haskell.org/ghc/ :? for help Prelude> :set +t Prelude> data Hi $tcHi :: TyCon $trModule :: Module data Hi Prelude> }}} The `$tcHi` and `$trModule` bindings are details of the Typeable implementation introduced in Phab:D1404 and should likely be hidden from the user. This would be trivial to fix in `InteractiveUI.printTypeOfNames` except for the fact that we currently have no way to identify this sort of `Name`. In fact any knowledge that the name was generated appears to have been thrown away as early as `OccName.mkTyConRepSysOcc`. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 2 10:49:31 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Nov 2015 10:49:31 -0000 Subject: [GHC] #11047: Provide call stacks in GHCi In-Reply-To: <047.3eb9c7a7d6579e45d15f3dffd3ade555@haskell.org> References: <047.3eb9c7a7d6579e45d15f3dffd3ade555@haskell.org> Message-ID: <062.36a6721585cadfefa6b6417ec2aaffca@haskell.org> #11047: Provide call stacks in GHCi -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #545, #4837 | Differential Rev(s): Phab:D1407 Wiki Page: | -------------------------------------+------------------------------------- Changes (by kgardas): * cc: kgardas (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 2 11:46:49 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Nov 2015 11:46:49 -0000 Subject: [GHC] #11052: Standalone derived Typeable instance for promoted lists is not found Message-ID: <045.1e0a781324c7d2e967c0560b8a754ab7@haskell.org> #11052: Standalone derived Typeable instance for promoted lists is not found -------------------------------------+------------------------------------- Reporter: liamoc | 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 Rev(s): | Wiki Page: -------------------------------------+------------------------------------- On GHC 7.10.2, if I try and compile the following short program: {{{#!hs {-# LANGUAGE DataKinds, PolyKinds, DeriveDataTypeable, StandaloneDeriving #-} module Test where import Data.Typeable deriving instance Typeable '[] deriving instance Typeable '(:) nilTyCon = typeRepTyCon (typeRep (Proxy :: Proxy '[])) consTyCon = typeRepTyCon (typeRep (Proxy :: Proxy '(:) )) }}} Then GHC reports the following errors: {{{ Test.hs:9:27: No instance for (Typeable '[]) arising from a use of ?typeRep? In the first argument of ?typeRepTyCon?, namely ?(typeRep (Proxy :: Proxy '[]))? In the expression: typeRepTyCon (typeRep (Proxy :: Proxy '[])) In an equation for ?nilTyCon?: nilTyCon = typeRepTyCon (typeRep (Proxy :: Proxy '[])) Test.hs:10:27: No instance for (Typeable (':)) (maybe you haven't applied enough arguments to a function?) arising from a use of ?typeRep? In the first argument of ?typeRepTyCon?, namely ?(typeRep (Proxy :: Proxy (:)))? In the expression: typeRepTyCon (typeRep (Proxy :: Proxy (:))) In an equation for ?consTyCon?: consTyCon = typeRepTyCon (typeRep (Proxy :: Proxy (:))) }}} It seems a bug to me that the very instances I asked to be derived (and apparently were without complaint from GHC) are now not found by the typechecker in the very next line. I think that if the instance cannot be derived, GHC should say so, or if it can, then GHC should find it. I can't really see what's going on with the dump flags, because the typechecker fails before the desugarer runs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 2 11:47:26 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Nov 2015 11:47:26 -0000 Subject: [GHC] #11052: Standalone derived Typeable instance for promoted lists is not found In-Reply-To: <045.1e0a781324c7d2e967c0560b8a754ab7@haskell.org> References: <045.1e0a781324c7d2e967c0560b8a754ab7@haskell.org> Message-ID: <060.8d44e9fa562a1759b15b342571474d6a@haskell.org> #11052: Standalone derived Typeable instance for promoted lists is not found -------------------------------------+------------------------------------- Reporter: liamoc | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by liamoc): * component: Compiler => Compiler (Type checker) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 2 12:10:14 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Nov 2015 12:10:14 -0000 Subject: [GHC] #11053: Add a warning for pattern synonyms without signatures Message-ID: <049.14bd36767d1a42a7a773049896471d92@haskell.org> #11053: Add a warning for pattern synonyms without signatures -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: feature | Status: new request | 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 Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It is accepted as good style that top-level definitions should have type signatures. Pattern synonyms seem no different to me in this regard so I think it would be good if GHC warned if there was a pattern synonym definition which lacked a type signature. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 2 14:42:04 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Nov 2015 14:42:04 -0000 Subject: [GHC] #11026: Bump `base` version to 4.9.0.0 In-Reply-To: <042.f747c2b78427a306bca14268108fcb46@haskell.org> References: <042.f747c2b78427a306bca14268108fcb46@haskell.org> Message-ID: <057.390e4a22c3c886775091535c32af7b4d@haskell.org> #11026: Bump `base` version to 4.9.0.0 -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: closed Priority: highest | Milestone: 8.0.1 Component: libraries/base | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"5065cf490ccdf03dda1e148afb979b8838e6c32e/ghc" 5065cf49/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5065cf490ccdf03dda1e148afb979b8838e6c32e" base: Update `@since 4.8.2` annotations (re #11026) This missed to perform in f8ba4b55cc3a061458f5cfabf17de96128defbbb }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 2 14:50:12 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Nov 2015 14:50:12 -0000 Subject: [GHC] #11048: Kind Incompatibility in GHC 7.6.3 In-Reply-To: <048.64915df854801a709c1b855460eb8fbc@haskell.org> References: <048.64915df854801a709c1b855460eb8fbc@haskell.org> Message-ID: <063.7337158ad13ffad77d2fd538a14a9476@haskell.org> #11048: Kind Incompatibility in GHC 7.6.3 ---------------------------------+---------------------------------------- Reporter: skatenerd | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => duplicate Comment: Thanks for reporting! This issue has been fixed in later versions of GHC and has several other tickets describing it. For example, see #8055. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 2 15:01:18 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Nov 2015 15:01:18 -0000 Subject: [GHC] #11052: Standalone derived Typeable instance for promoted lists is not found In-Reply-To: <045.1e0a781324c7d2e967c0560b8a754ab7@haskell.org> References: <045.1e0a781324c7d2e967c0560b8a754ab7@haskell.org> Message-ID: <060.09cf74c2d040deb81ce5a5889a111502@haskell.org> #11052: Standalone derived Typeable instance for promoted lists is not found -------------------------------------+------------------------------------- Reporter: liamoc | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): The error is correct, though the error message is bad (especially the second one). With `-fprint-explicit-kinds` the error is better: {{{ Test2.hs:10:28: No instance for (Typeable [k1] ('[] k1)) arising from a use of ?typeRep? In the first argument of ?typeRepTyCon?, namely ?(typeRep (Proxy :: Proxy []))? In the expression: typeRepTyCon (typeRep (Proxy :: Proxy [])) In an equation for ?nilTyCon?: nilTyCon = typeRepTyCon (typeRep (Proxy :: Proxy [])) Test2.hs:11:28: No instance for (Typeable (k0 -> [k0] -> [k0]) ((':) k0)) (maybe you haven't applied enough arguments to a function?) arising from a use of ?typeRep? In the first argument of ?typeRepTyCon?, namely ?(typeRep (Proxy :: Proxy (:)))? In the expression: typeRepTyCon (typeRep (Proxy :: Proxy (:))) In an equation for ?consTyCon?: consTyCon = typeRepTyCon (typeRep (Proxy :: Proxy (:))) }}} The type `'[]` can have any kind `[k1]`, and these must have different Typeable instances. So, the (implicit, and not even mentioned in the original error message) kind variable is really ambiguous. You could choose a particular kind with a signature: {{{ nilStarTyCon = typeRepTyCon (typeRep (Proxy :: Proxy ('[] :: [*]))) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 2 15:01:55 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Nov 2015 15:01:55 -0000 Subject: [GHC] #11052: Standalone derived Typeable instance for promoted lists is not found In-Reply-To: <045.1e0a781324c7d2e967c0560b8a754ab7@haskell.org> References: <045.1e0a781324c7d2e967c0560b8a754ab7@haskell.org> Message-ID: <060.65edb33a19f65cea9e8fb9586c9d1c16@haskell.org> #11052: Standalone derived Typeable instance for promoted lists is not found -------------------------------------+------------------------------------- Reporter: liamoc | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * priority: normal => high * milestone: => 8.0.1 Comment: (Written concurrently with comment:2) This is actually expected behavior, but perhaps shouldn't be. The problem is that, at your call sites of `typeRep`, GHC doesn't know what ''kinds'' you want to specialize `'[]` and `'(:)` to. We can't have type representations of poly-kinded things (for various good reasons that would take a bit of academic research to sort out), so compilation fails. But we sure can improve the error message. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 2 16:11:40 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Nov 2015 16:11:40 -0000 Subject: [GHC] #11054: GHC on Windows could not use more than 64 logical processors Message-ID: <045.741627474d8a57d1af2339a943171c04@haskell.org> #11054: GHC on Windows could not use more than 64 logical processors -------------------------------------+------------------------------------- Reporter: varosi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.10.2 System | Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I found that GHC runtime does not take advantage of processor groups under Windows. So it cannot use more than 64 logical processors (2x 18 core physical + HT). This is Reddit thread about: https://www.reddit.com/r/haskell/comments/3q1r0o/ghc_on_numa_72_core_2_processor_machine_cannot/ MSDN link https://msdn.microsoft.com/en- us/library/windows/desktop/dd405503(v=vs.85).aspx -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 2 16:27:18 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Nov 2015 16:27:18 -0000 Subject: [GHC] #11014: re-order GHC type errors for clarity In-Reply-To: <047.63b2ee64fbc0e8cf4ea8e84a14f0ce30@haskell.org> References: <047.63b2ee64fbc0e8cf4ea8e84a14f0ce30@haskell.org> Message-ID: <062.83a1b30635faa9b4923c18fda8a789cf@haskell.org> #11014: re-order GHC type errors for clarity -------------------------------------+------------------------------------- Reporter: elaforge | Owner: elaforge Type: feature request | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by elaforge): Yeah, I'm working on a patch. I'll update the ticket once I get all the details figured out. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 2 16:48:28 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Nov 2015 16:48:28 -0000 Subject: [GHC] #11047: Provide call stacks in GHCi In-Reply-To: <047.3eb9c7a7d6579e45d15f3dffd3ade555@haskell.org> References: <047.3eb9c7a7d6579e45d15f3dffd3ade555@haskell.org> Message-ID: <062.beba38f526ce0bba431faf410bcf74c1@haskell.org> #11047: Provide call stacks in GHCi -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #545, #4837 | Differential Rev(s): Phab:D1407 Wiki Page: | -------------------------------------+------------------------------------- Comment (by gridaphobe): Just for clarity, could you elaborate on how this differs from the existing call stacks that you can print in ghci? Is the main difference that currently ghci's call stack only traces byte-compiled code? It's also not clear to me how we're going to avoid exposing the details of lazy evaluation. Both the breakpoint-based traces and the SCC-based traces currently expose lazy evaluation (which I agree is a bad thing, at least for error debugging!). I guess this means extending the byte-code interpreter to distinguish between a lexical call-site vs entering a closure based on demand? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 2 18:33:41 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Nov 2015 18:33:41 -0000 Subject: [GHC] #11047: Provide call stacks in GHCi In-Reply-To: <047.3eb9c7a7d6579e45d15f3dffd3ade555@haskell.org> References: <047.3eb9c7a7d6579e45d15f3dffd3ade555@haskell.org> Message-ID: <062.0ccbeb183b5068cdf589043a56650ccb@haskell.org> #11047: Provide call stacks in GHCi -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #545, #4837 | Differential Rev(s): Phab:D1407 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): `:hist` doesn't really print a call stack, it just prints a history of the recent locations that execution passed through. It was a hack because we didn't have real stack trace support. We might even drop `:trace` or replace it with something better when we have stack traces. SCC-based stack traces don't expose lazy evaluation (or at least, if they do, it's a bug we should fix, so please let me know). I'm using the same cost-centre-stack semantics in GHCi as we have in the profiling system. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 2 19:49:47 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Nov 2015 19:49:47 -0000 Subject: [GHC] #11025: Per-database shadowing In-Reply-To: <045.d3e5eba6f5850281f113a1da5a4f0541@haskell.org> References: <045.d3e5eba6f5850281f113a1da5a4f0541@haskell.org> Message-ID: <060.5c0cd2448d07986deecbc56004045e29@haskell.org> #11025: Per-database shadowing -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Package system | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: cabal/shadow Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1385 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * testcase: => cabal/shadow * status: new => closed * resolution: => fixed Comment: In commit 39b71e81ec1044518f065d0055676d713521e483: {{{ Author: Edward Z. Yang Date: Tue Oct 27 14:47:33 2015 -0700 Reimplement shadowing on a per database basis. Summary: This commit reimplements shadowing on package databases by doing the shadowing calculation on a per-database basis: specifically, if a later package database shadows a package from the earlier databases, we first remove that package (and its transitive dependencies) before merging the databases together. This should also fix bootstrapping GHC HEAD with HEAD. Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: ggreif, bgamari, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1385 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 2 21:50:28 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Nov 2015 21:50:28 -0000 Subject: [GHC] #10986: GHC should delete all temporary files it creates in /tmp In-Reply-To: <044.1681438585b48fcd6c17fa0b77a432bd@haskell.org> References: <044.1681438585b48fcd6c17fa0b77a432bd@haskell.org> Message-ID: <059.5ef94432c8fe8bdbc6eea5c5987d5931@haskell.org> #10986: GHC should delete all temporary files it creates in /tmp -------------------------------------+------------------------------------- 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: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by gridaphobe): * cc: gridaphobe (added) Comment: I've encountered this recently as well on our ubuntu server (14.04.1). We have gcc-4.8.4 and ghc-7.6.3 installed by default, though with `stack` there's no telling what version people are using (probably 7.10.2). The sheer number of temporary directories left behind by ghc (which is enough to occasionally bring our server to a crawl) suggests that the directories must be left behind even under normal circumstances. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 2 23:26:07 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Nov 2015 23:26:07 -0000 Subject: [GHC] #11047: Provide call stacks in GHCi In-Reply-To: <047.3eb9c7a7d6579e45d15f3dffd3ade555@haskell.org> References: <047.3eb9c7a7d6579e45d15f3dffd3ade555@haskell.org> Message-ID: <062.ceaddf1cedc50d649889a99094ab7953@haskell.org> #11047: Provide call stacks in GHCi -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #545, #4837 | Differential Rev(s): Phab:D1407 Wiki Page: | -------------------------------------+------------------------------------- Comment (by gridaphobe): Ah, I haven't actually used the SCC-based stack traces in a while, so I'm probably just misremembering how they work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 3 06:28:12 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Nov 2015 06:28:12 -0000 Subject: [GHC] #11055: GHC 7.8.4 crash on ARM while building Stack 0.1.7 Message-ID: <047.fb2a0236ca36949d692f2910f33633d4@haskell.org> #11055: GHC 7.8.4 crash on ARM while building Stack 0.1.7 --------------------------------+--------------------------------------- Reporter: Lokathor | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Linux Architecture: arm | Type of failure: Compile-time crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+--------------------------------------- I was attempting to get stack on a raspberry pi 2. I had made a sandbox and installed the dependencies just fine. I go to build stack itself and the following happens: {{{ daniel at pixie stack $ cabal build Package has never been configured. Configuring with default flags. If this fails, please run configure manually. Resolving dependencies... Configuring stack-0.1.7.0... Building stack-0.1.7.0... Preprocessing library stack-0.1.7.0... [ 1 of 74] Compiling Data.Set.Monad ( src/Data/Set/Monad.hs, dist/build/Data/Set/Monad.o ) ghc: internal error: scavenge: unimplemented/strange closure type 15028 @ 0x6dfe143c (GHC version 7.8.4 for arm_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted }}} The folder is still there so I could attach files or some such if needed. I know that GHC on ARM is full of weird instruction problems that have only recently been fixed, but I wasn't sure if this was related or not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 3 09:10:08 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Nov 2015 09:10:08 -0000 Subject: [GHC] #11055: GHC 7.8.4 crash on ARM while building Stack 0.1.7 In-Reply-To: <047.fb2a0236ca36949d692f2910f33633d4@haskell.org> References: <047.fb2a0236ca36949d692f2910f33633d4@haskell.org> Message-ID: <062.5bfd6502c1d8a76343d299914bb8e630@haskell.org> #11055: GHC 7.8.4 crash on ARM while building Stack 0.1.7 ---------------------------------------+---------------------------------- Reporter: Lokathor | Owner: Type: bug | Status: infoneeded 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): Wiki Page: | ---------------------------------------+---------------------------------- Changes (by bgamari): * status: new => infoneeded Comment: Indeed there are a number of bugs in ARM support in the 7.8. As of 7.10.3 these are largely fixed. Could you try the 7.10.3 release candidate? For the record, the testsuite summary should look something like this on 7.10.3, {{{ OVERALL SUMMARY for test run started at Tue Nov 3 02:48:37 2015 KST 0:46:50 spent to go through 4463 total tests, which gave rise to 18087 test cases, of which 14064 were skipped 52 had missing libraries 3906 expected passes 41 expected failures 6 caused framework failures 0 unexpected passes 11 unexpected failures 13 unexpected stat failures Unexpected failures: cabal/sigcabal01 sigcabal01 [bad stderr] (normal) codeGen/should_compile T7574 [stderr mismatch] (normal) driver T5313 [bad stderr] (normal) ghc-api T8628 [bad stderr] (normal) ghc-api T8639_api [bad stderr] (normal) ghc-api/T10052 T10052 [bad stderr] (normal) ghc-api/dynCompileExpr dynCompileExpr [bad stderr] (normal) rts T5435_v_asm [bad stderr] (normal) rts T5435_v_gcc [bad stderr] (normal) rts linker_unload [bad stderr] (normal) safeHaskell/flags Flags02 [exit code non-0] (normal) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 3 09:27:40 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Nov 2015 09:27:40 -0000 Subject: [GHC] #11055: GHC 7.8.4 crash on ARM while building Stack 0.1.7 In-Reply-To: <047.fb2a0236ca36949d692f2910f33633d4@haskell.org> References: <047.fb2a0236ca36949d692f2910f33633d4@haskell.org> Message-ID: <062.f5c51a1f6f7e8b306ae9819e1d9cf6d2@haskell.org> #11055: GHC 7.8.4 crash on ARM while building Stack 0.1.7 ---------------------------------------+---------------------------------- Reporter: Lokathor | Owner: Type: bug | Status: infoneeded 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): Wiki Page: | ---------------------------------------+---------------------------------- Comment (by Lokathor): Is https://downloads.haskell.org/~ghc/7.10.3-rc1/ where i should try? Reddit directs me there, but the folder is blank to me. Usually there are no ARM builds to begin with. Could a broken 7.8 like I have somehow compile 7.10.3? Or would I have to try some cross compiler thing from a different computer? I tried the official debian armhf version of 7.10.2 but it crashed on every build because of some assembally mismatch i ended up having. Raspbian itself doesnt have a version of the 7.10 line as far as I know. I'm afraid I'm very new to this all and have never compiled ghc before. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 3 13:00:06 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Nov 2015 13:00:06 -0000 Subject: [GHC] #11047: Provide call stacks in GHCi In-Reply-To: <047.3eb9c7a7d6579e45d15f3dffd3ade555@haskell.org> References: <047.3eb9c7a7d6579e45d15f3dffd3ade555@haskell.org> Message-ID: <062.adb27d2b4e7b644162842f9c9e31d2a7@haskell.org> #11047: Provide call stacks in GHCi -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #545, #4837 | Differential Rev(s): Phab:D1407 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I like the idea of running GHCi commands in a separate process. But the division of responsibility between the two is quite obscure to me. Presumably we have a non-profiled GHC compiling profiled code, in the host process, that then squirts bytecode (?) to the assistant process which runs it? We have various unsolved semantic bugs in cost-centre semantics, which makes me feel uneasy. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 3 13:30:30 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Nov 2015 13:30:30 -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.6e00cb4566984531bb438cbe7111ad72@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: #10846 | Differential Rev(s): Phab:D1422 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * differential: => Phab:D1422 Comment: On [Phab:D1422] you say: Sadly, it turns out we can't remove the no-given solver entirely. Consider {{{ main = do putStrLn $ showCallStack ?loc putStrLn $ showCallStack ?loc }}} GHC treats the constraints arising from the two occurrences of ?loc as interchangeable (after all, they have the same type), and solves one from the other, giving us the incorrect output {{{ % ./T10845 CallStack: ?loc, called at T10845.hs:33:36 in main:Main CallStack: ?loc, called at T10845.hs:33:36 in main:Main }}} (note that both CallStacks refer to the same location). Good point! But there is a better way to solve this particular issue: * In `Inst.instCallConstraints`, add a special case for `CallStack` constraints, where you push on the call site (i.e. do what the solver currently does, in `isCallStackIP` * Now any Wanted call-stack constraints encountered by the solver can be solved by equality from each other, or directly from a given. In fact this makes call-stack constraints behave even more like implicit-parameter constraints. * Defaulting solves a `CallStack` constraint with `EmptyStack` This is much simpler and more direct. There is a wrinkle: what if the function being called had a type like `f :: c => T c -> Int`, and `c` was subsequently inferred to be `IP "foo" CallStack`? So the fact that it's a call-stack constraint isn't immediately obvious. It's a pretty obscure problem but could be solved by NOT solving in `instCallConstraints`, but intead * Have two kind of call-stack constraints, with origin `OccurrenceOf`, and `IPOccOrigin` (this is actually true already; see `IPCallStackIP`. * The only way to solve an `OccurrenceOf` call-stack constraint is by pushing on the call item, and producing a new wanted `IPOccOrigin` call-stack constraint * Solve wanted `IPOccOrigin` call-stack constraints as above, from each other, from givens, or by defaulting. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 3 13:48:01 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Nov 2015 13:48:01 -0000 Subject: [GHC] #11047: Provide call stacks in GHCi In-Reply-To: <047.3eb9c7a7d6579e45d15f3dffd3ade555@haskell.org> References: <047.3eb9c7a7d6579e45d15f3dffd3ade555@haskell.org> Message-ID: <062.47079754765336aea165295ef2ca56bd@haskell.org> #11047: Provide call stacks in GHCi -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #545, #4837 | Differential Rev(s): Phab:D1407 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): Yes - we would need to clearly define the interface between GHC and the interpreter as a set of commands that have to be serializable across the process boundary. I imagine there would be a `mkByteCodeObject` command that took byte-code as an argument, and we would have to keep track of the byte-code with StablePtrs (or something like that). Luite has already done some of this work in order to get TH working with GHCJS - all the methods of the `Quasi` class are serialized using `Data.Binary` across the process boundary, including all of the TH syntax returned by a splice (see https://github.com/ghcjs/ghcjs/tree/master/lib /ghcjs-prim/GHCJS/Prim/TH). Regarding the semantic bugs, the main one is #5654. I'll try to fix that, but it doesn't seem to happen all that often, and for a debugging tool I think an occasional inaccuracy isn't too much of a concern. Some information is better than none, and we get *lots* of good information. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 3 13:57:46 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Nov 2015 13:57:46 -0000 Subject: [GHC] #11056: Need to generate Typable info for promoted data constructors Message-ID: <046.10d6ee6a6f34d362ec160d92f2757040@haskell.org> #11056: Need to generate Typable info for promoted data constructors -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: high | 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): | Wiki Page: -------------------------------------+------------------------------------- Trac #10052 isn't relevant for HEAD, because HEAD generates implicit `Typeable` bindings for everything. But in testing {{{ {-# LANGUAGE PolyKinds, DataKinds #-} module Foo where import Data.Typeable data T = A | B Int bar :: TypeRep bar = typeRep (Proxy :: Proxy '[True]) }}} I discovered that we aren't generating tycon-rep bindings for promoted data constructors. As a result we get {{{ GHC error in desugarer lookup in Foo: Can't find interface-file declaration for variable tc'[] Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error }}} In particular `TcTypeable.mkTypeableBinds` doesn't generate the bindings for the `tc'[]` and `tc':`. It's not hard to fix this, but it will add more top-level declarations for each data type decl. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 3 14:16:59 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Nov 2015 14:16:59 -0000 Subject: [GHC] #11020: Make worker-wrapper transformation optional. In-Reply-To: <046.af56752a88fefa3cca6c1cc155378f63@haskell.org> References: <046.af56752a88fefa3cca6c1cc155378f63@haskell.org> Message-ID: <061.0cab560efdbe679503b87ae61e084026@haskell.org> #11020: Make worker-wrapper transformation optional. -------------------------------------+------------------------------------- Reporter: darchon | Owner: darchon Type: feature request | 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: none Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1372 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * testcase: => none * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 3 14:22:11 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Nov 2015 14:22:11 -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.7e76830029d1b268e7e600c069ccbeac@haskell.org> #10848: GHC/GHCi should optionally print errors in reversed order -------------------------------------+------------------------------------- Reporter: osa1 | Owner: siddhanathan 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: none Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1367 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * testcase: => none * status: new => closed * resolution: => fixed * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 3 14:24:05 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Nov 2015 14:24:05 -0000 Subject: [GHC] #10736: threadWaitRead/registerFd unusable In-Reply-To: <044.a96ce04f26395251bc71867625bc2939@haskell.org> References: <044.a96ce04f26395251bc71867625bc2939@haskell.org> Message-ID: <059.c5c0878536f592e79638cf8ee4efea9b@haskell.org> #10736: threadWaitRead/registerFd unusable -------------------------------------+------------------------------------- Reporter: mboes | Owner: bgamari 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- 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 Nov 3 14:36:33 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Nov 2015 14:36:33 -0000 Subject: [GHC] #11057: toIfaceIdDetails trace statement catches PatSynBuilder Message-ID: <046.6feaafdc65794c033bfadc6a62db1081@haskell.org> #11057: toIfaceIdDetails trace statement catches PatSynBuilder -------------------------------------+------------------------------------- Reporter: bgamari | 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: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- hvr reported this `pprTrace` message showing up during a GHC build, {{{ [ 73 of 212] Compiling GHC.Exception ( GHC/Exception.hs, dist/build/GHC/Exception.o ) toIfaceIdDetails [PatSynBuilder] }}} I believe this is due to mpickering's Phab:D1152, which introduced the `PatSynBuilder` constructor without handling it in `toIfaceIdDetails`. Given that things appear to work, I would guess we want to handle it with, {{{ toIfaceIdDetails PatSynBuilder = IfVanillaId }}} but I'm not certain. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 3 14:54:25 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Nov 2015 14:54:25 -0000 Subject: [GHC] #11057: toIfaceIdDetails trace statement catches PatSynBuilder In-Reply-To: <046.6feaafdc65794c033bfadc6a62db1081@haskell.org> References: <046.6feaafdc65794c033bfadc6a62db1081@haskell.org> Message-ID: <061.2f94e9e57ba5b89290210bdb9c1185ae@haskell.org> #11057: toIfaceIdDetails trace statement catches PatSynBuilder -------------------------------------+------------------------------------- Reporter: bgamari | Owner: mpickering Type: bug | Status: new Priority: normal | Milestone: 8.0.1 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: => mpickering * cc: mpickering (added) Comment: Yes, that is wrong. `PatSynBuilder` is not making it through interface files. But it's a pain having to track the fact that an Id is in fact a `PatSynBuilderId`. And it's only done for one extremely narrow purpose: to service `idConLike` which in turn is only called in `dsExpr` for `RecordCon`. We should not use `IdDetails` for such a narrow reason. Let's remove it from `IdDetails` altogether, and get the info from the type checker to the desugarer some other way. What we want is for the post-typecheck `RecordCon` to carry `ConLike`, which `tcExpr (RecordCon ...)` has in its sticky paw. To do this we either need a `PostTc ConLike` field, or a new data constructor `RecordConOut`. (Compare `ConPatIn` and `ConPatOut` in `HsPat`; the latter has a `ConLike`.) Matthew would you like to look at this? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 3 15:14:27 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Nov 2015 15:14:27 -0000 Subject: [GHC] #11058: selected processor does not support ARM mode Message-ID: <046.179fa65419f6552c89ce7f996b230033@haskell.org> #11058: selected processor does not support ARM mode --------------------------------+---------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: arm | Type of failure: Building GHC failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+---------------------------------------- Building GHC-7.10.3-rc1 on Debian armel produces: {{{ "inplace/bin/ghc-stage1" -static -H32m -O -lffi -optl-pthread -optl-B/usr/bin/ld.gold -Iincludes -Iincludes/dist -Iincludes/dist- derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-package-key rts -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2 -c rts/StgStartup.cmm -o rts/dist/build/StgStartup.o /tmp/ghcd0b9_0/ghc_7.s: Assembler messages: /tmp/ghcd0b9_0/ghc_7.s:96:0: Error: selected processor does not support ARM mode `ldrd r0,r1,[r3,#64]' /tmp/ghcd0b9_0/ghc_7.s:99:0: Error: selected processor does not support ARM mode `strd r0,r1,[r3,#64]' /tmp/ghcd0b9_0/ghc_7.s:210:0: Error: selected processor does not support ARM mode `ldrd r0,r1,[r7,#64]' /tmp/ghcd0b9_0/ghc_7.s:214:0: Error: selected processor does not support ARM mode `strd r0,r1,[r7,#64]' rts/ghc.mk:236: recipe for target 'rts/dist/build/StgStartup.o' failed make[3]: *** [rts/dist/build/StgStartup.o] Error 1 Makefile:71: recipe for target 'all' failed make[2]: *** [all] Error 2 }}} According to Austin, this is fallout from changeset:933adc0f31164cb651d11ecfcfe612ac429f714f/ghc / #10375. But it is also a regression from GHC-7.10.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 3 15:35:07 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Nov 2015 15:35:07 -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.a5ed8f1c73b3df06e27ac5bd87343943@haskell.org> #10365: Implement Semigroup as a superclass of Monoid Proposal (Phase 1) -------------------------------------+------------------------------------- Reporter: gidyn | Owner: quchen 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 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): You can rename the method of `Semigroup` with type `a -> [a] -> a` and move `sconcat` to a top-level definition in `Data.List.NonEmpty`, and that should hardly break anyone compared to the rather substantial `Semigroup => Monoid` superclass addition that is the main part of this proposal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 3 15:39:46 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Nov 2015 15:39:46 -0000 Subject: [GHC] #11057: toIfaceIdDetails trace statement catches PatSynBuilder In-Reply-To: <046.6feaafdc65794c033bfadc6a62db1081@haskell.org> References: <046.6feaafdc65794c033bfadc6a62db1081@haskell.org> Message-ID: <061.8d10a8f0883ef4830f64c459d9b3e440@haskell.org> #11057: toIfaceIdDetails trace statement catches PatSynBuilder -------------------------------------+------------------------------------- Reporter: bgamari | Owner: mpickering Type: bug | Status: new Priority: normal | Milestone: 8.0.1 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Yes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 3 16:46:04 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Nov 2015 16:46:04 -0000 Subject: [GHC] #11014: re-order GHC type errors for clarity In-Reply-To: <047.63b2ee64fbc0e8cf4ea8e84a14f0ce30@haskell.org> References: <047.63b2ee64fbc0e8cf4ea8e84a14f0ce30@haskell.org> Message-ID: <062.c43bdf585d9073b297acbc3a7ee179d7@haskell.org> #11014: re-order GHC type errors for clarity -------------------------------------+------------------------------------- Reporter: elaforge | Owner: elaforge Type: feature request | 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 Rev(s): Phab:D1427 Wiki Page: | -------------------------------------+------------------------------------- Changes (by elaforge): * differential: => Phab:D1427 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 3 16:57:28 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Nov 2015 16:57:28 -0000 Subject: [GHC] #11058: selected processor does not support ARM mode In-Reply-To: <046.179fa65419f6552c89ce7f996b230033@haskell.org> References: <046.179fa65419f6552c89ce7f996b230033@haskell.org> Message-ID: <061.0c3f4d378f76971c061cf2cce2c3bf4f@haskell.org> #11058: selected processor does not support ARM mode ----------------------------------------+------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------ Comment (by bgamari): Here is a summary of the issue sent to ghc-devs, > Indeed this appears to be regression compared to 7.10.2 for some. > However for most users it will be a significant improvement in > stability. > > ARM processors can run code encoded in one of several instruction sets > of which ARM and Thumb are two. The issue here is that we have never > been able to handle Thumb instructions correctly; we fare even worse in > cases where we have Thumb and ARM instructions in the same executable > due to various linker issues: > > * the runtime's linker doesn't support loading heterogeneous code at > all > > * the system's dynamic linker will almost certainly screw up our info > tables due to the need for a trampoline (for this reason , I'm not > even sure whether it's possible to handle Thumb-ARM interworking in > Haskell code) > > There are several places where Thumb instructions could come from, > > 1. GHCi produced them in mkJumpToAddr > > 2. native code compiled with GCC, which defaults to Thumb on many > systems > > 3. system libraries, which are Thumb on many distributions > > The solution which Erik implemented was to switch entirely to ARM. (1) > was addressed by changing the GHC, (2) was fixed by explicitly passing > -marm to GCC. I'm actually not sure the state of (3). > > Regardless, the solution to (2) is clearly upsetting your system. This > is odd as I was under the impression that all non-microcontroller ARM > devices support the full ARM instruction set (the Cortex devices, on the > other hand, only support Thumb but are totally incapable of running GHC > at all). What hardware and distribution is this? > > Cheers, > > ~ Ben > -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 3 17:46:02 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Nov 2015 17:46:02 -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.77a49eff9b39ba3ef8cada28f75d0ebc@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: #10846 | Differential Rev(s): Phab:D1422 Wiki Page: | -------------------------------------+------------------------------------- Comment (by gridaphobe): If I understand your suggestion correctly, this won't fix my example. Why? Because `?loc` creates an `IPOccOrigin` constraint, which you suggest we should freely solve from other call-stack constraints (I take this to mean the usual form of solving an IP, ie we don't push on the stack). So the two `?loc` constraints would be consolidated to one, which we would default to the empty stack. But perhaps this isn't so bad after all. My example was a bit of a red herring, what we really care about is that in {{{ f :: (?stk :: CallStack) => .. main = print (f 0) >> print (f 1) }}} the two calls to `f` are not consolidated to a single constraint. `f x` gives rise to an `OccurrenceOf` constraint, which you suggest we would solve by pushing on the stack and emitting an `IPOccOrigin` constraint, so we '''would''' get the correct behavior here. So, I think under your suggestion, we'll never see a `?loc` in the call- stack, but I think that's fine. (It always stuck me as a bit odd to have the root of the call-stack be an occurrence of an IP, rather than a function call) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 3 18:58:07 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Nov 2015 18:58:07 -0000 Subject: [GHC] #10678: integer-gmp's runS seems unnecessarily expensive In-Reply-To: <047.1e3027d49179affc6473e88cc8dec51a@haskell.org> References: <047.1e3027d49179affc6473e88cc8dec51a@haskell.org> Message-ID: <062.7d4a368288ddd1c4940606b12a889e7f@haskell.org> #10678: integer-gmp's runS seems unnecessarily expensive -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1103 Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > integer-gmp uses an unsafePerformIO-like operation to work with mutable > BigNats (unsafePerformIO and even the IO type are not yet available, > since integer-gmp is a dependency of base): > {{{ > type S s a = State# s -> (# State# s, a #) > > -- NB: equivalent of GHC.IO.unsafeDupablePerformIO, see notes there > runS :: S RealWorld a -> a > runS m = lazy (case m realWorld# of (# _, r #) -> r) > {-# NOINLINE runS #-} > }}} > It's tempting to think of such an operation as "free" like an > unsafeCoerce, but it is actually somewhat expensive. > > Consider `plusBigNat` for instance. (Most BigNat operations have a > similar structure.) > {{{ > plusBigNat :: BigNat -> BigNat -> BigNat > plusBigNat x y > | isTrue# (eqBigNatWord# x 0##) = y > | isTrue# (eqBigNatWord# y 0##) = x > | isTrue# (nx# >=# ny#) = go x nx# y ny# > | True = go y ny# x nx# > where > go (BN# a#) na# (BN# b#) nb# = runS $ do > mbn@(MBN# mba#) <- newBigNat# na# > (W# c#) <- liftIO (c_mpn_add mba# a# na# b# nb#) > case c# of > 0## -> unsafeFreezeBigNat# mbn > _ -> unsafeSnocFreezeBigNat# mbn c# > > nx# = sizeofBigNat# x > ny# = sizeofBigNat# y > }}} > The assembly for `go` begins > {{{ > 00000000000001d0 : > 1d0: 49 83 c4 28 add $0x28,%r12 > 1d4: 4d 3b a5 58 03 00 00 cmp 0x358(%r13),%r12 > 1db: 77 26 ja 203 > > 1dd: 49 c7 44 24 e0 00 00 movq $0x0,-0x20(%r12) > 1e4: 00 00 > 1e2: R_X86_64_32S .text+0x38 > 1e6: 4d 89 74 24 e8 mov %r14,-0x18(%r12) > 1eb: 49 89 7c 24 f0 mov %rdi,-0x10(%r12) > 1f0: 49 89 74 24 f8 mov %rsi,-0x8(%r12) > 1f5: 4d 89 04 24 mov %r8,(%r12) > 1f9: 4d 8d 74 24 e1 lea -0x1f(%r12),%r14 > 1fe: e9 00 00 00 00 jmpq 203 > > 1ff: R_X86_64_PC32 > integerzmgmp_GHCziIntegerziType_runS_info-0x4 > 203: ... ; heap overflow > }}} > This allocates a 5-word closure (containing `a#`, `na#`, `b#`, `nb#`) > whose code is at `.text+0x38` and passes it to `runS`, which does some > `stg_ap`-y things to call back into the closure, which reads its free > variables back from the heap and finally does all the real work. > Altogether it's around two dozen instructions compared to if we could > call directly from `go` to the argument of `runS`. > > The old integer-gmp somehow avoided this particular overhead by instead > using the implicit "unsafePerformIO" of a foreign import prim which > performed both the allocation and the addition. Is this overhead a > necessary consequence of doing the work in multiple steps in Haskell? > > I understand that we cannot allow everything to be inlined and, for > example, the `newBigNat#` to be shared between a `plusBigNat` and > `minusBigNat` with the same arguments. But once `runS` has done its job > of keeping the `newBigNat#/c_mpn_add/unsafeFreeze*` together, it would be > nice to eliminate it completely in the backend when compiling `go`, or > any inlined version of `go`. > > I'm not sure whether this should be fixed in the code generator or in > integer-gmp itself. I'm also aware that this is a tricky subject but > haven't really done my homework on the related tickets, so I might be > missing something important! New description: integer-gmp uses an unsafePerformIO-like operation to work with mutable BigNats (unsafePerformIO and even the IO type are not yet available, since integer-gmp is a dependency of base): {{{#!hs type S s a = State# s -> (# State# s, a #) -- NB: equivalent of GHC.IO.unsafeDupablePerformIO, see notes there runS :: S RealWorld a -> a runS m = lazy (case m realWorld# of (# _, r #) -> r) {-# NOINLINE runS #-} }}} It's tempting to think of such an operation as "free" like an unsafeCoerce, but it is actually somewhat expensive. Consider `plusBigNat` for instance. (Most BigNat operations have a similar structure.) {{{#!hs plusBigNat :: BigNat -> BigNat -> BigNat plusBigNat x y | isTrue# (eqBigNatWord# x 0##) = y | isTrue# (eqBigNatWord# y 0##) = x | isTrue# (nx# >=# ny#) = go x nx# y ny# | True = go y ny# x nx# where go (BN# a#) na# (BN# b#) nb# = runS $ do mbn@(MBN# mba#) <- newBigNat# na# (W# c#) <- liftIO (c_mpn_add mba# a# na# b# nb#) case c# of 0## -> unsafeFreezeBigNat# mbn _ -> unsafeSnocFreezeBigNat# mbn c# nx# = sizeofBigNat# x ny# = sizeofBigNat# y }}} The assembly for `go` begins {{{ 00000000000001d0 : 1d0: 49 83 c4 28 add $0x28,%r12 1d4: 4d 3b a5 58 03 00 00 cmp 0x358(%r13),%r12 1db: 77 26 ja 203 1dd: 49 c7 44 24 e0 00 00 movq $0x0,-0x20(%r12) 1e4: 00 00 1e2: R_X86_64_32S .text+0x38 1e6: 4d 89 74 24 e8 mov %r14,-0x18(%r12) 1eb: 49 89 7c 24 f0 mov %rdi,-0x10(%r12) 1f0: 49 89 74 24 f8 mov %rsi,-0x8(%r12) 1f5: 4d 89 04 24 mov %r8,(%r12) 1f9: 4d 8d 74 24 e1 lea -0x1f(%r12),%r14 1fe: e9 00 00 00 00 jmpq 203 1ff: R_X86_64_PC32 integerzmgmp_GHCziIntegerziType_runS_info-0x4 203: ... ; heap overflow }}} This allocates a 5-word closure (containing `a#`, `na#`, `b#`, `nb#`) whose code is at `.text+0x38` and passes it to `runS`, which does some `stg_ap`-y things to call back into the closure, which reads its free variables back from the heap and finally does all the real work. Altogether it's around two dozen instructions compared to if we could call directly from `go` to the argument of `runS`. The old integer-gmp somehow avoided this particular overhead by instead using the implicit "unsafePerformIO" of a foreign import prim which performed both the allocation and the addition. Is this overhead a necessary consequence of doing the work in multiple steps in Haskell? I understand that we cannot allow everything to be inlined and, for example, the `newBigNat#` to be shared between a `plusBigNat` and `minusBigNat` with the same arguments. But once `runS` has done its job of keeping the `newBigNat#/c_mpn_add/unsafeFreeze*` together, it would be nice to eliminate it completely in the backend when compiling `go`, or any inlined version of `go`. I'm not sure whether this should be fixed in the code generator or in integer-gmp itself. I'm also aware that this is a tricky subject but haven't really done my homework on the related tickets, so I might be missing something important! -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 3 19:05:10 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Nov 2015 19:05:10 -0000 Subject: [GHC] #10678: integer-gmp's runS seems unnecessarily expensive In-Reply-To: <047.1e3027d49179affc6473e88cc8dec51a@haskell.org> References: <047.1e3027d49179affc6473e88cc8dec51a@haskell.org> Message-ID: <062.b7c66626dac26138e6c2f381898e297a@haskell.org> #10678: integer-gmp's runS seems unnecessarily expensive -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1103 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * cc: simonmar (added) Old description: > integer-gmp uses an unsafePerformIO-like operation to work with mutable > BigNats (unsafePerformIO and even the IO type are not yet available, > since integer-gmp is a dependency of base): > {{{#!hs > type S s a = State# s -> (# State# s, a #) > > -- NB: equivalent of GHC.IO.unsafeDupablePerformIO, see notes there > runS :: S RealWorld a -> a > runS m = lazy (case m realWorld# of (# _, r #) -> r) > {-# NOINLINE runS #-} > }}} > It's tempting to think of such an operation as "free" like an > unsafeCoerce, but it is actually somewhat expensive. > > Consider `plusBigNat` for instance. (Most BigNat operations have a > similar structure.) > {{{#!hs > plusBigNat :: BigNat -> BigNat -> BigNat > plusBigNat x y > | isTrue# (eqBigNatWord# x 0##) = y > | isTrue# (eqBigNatWord# y 0##) = x > | isTrue# (nx# >=# ny#) = go x nx# y ny# > | True = go y ny# x nx# > where > go (BN# a#) na# (BN# b#) nb# = runS $ do > mbn@(MBN# mba#) <- newBigNat# na# > (W# c#) <- liftIO (c_mpn_add mba# a# na# b# nb#) > case c# of > 0## -> unsafeFreezeBigNat# mbn > _ -> unsafeSnocFreezeBigNat# mbn c# > > nx# = sizeofBigNat# x > ny# = sizeofBigNat# y > }}} > The assembly for `go` begins > {{{ > 00000000000001d0 : > 1d0: 49 83 c4 28 add $0x28,%r12 > 1d4: 4d 3b a5 58 03 00 00 cmp 0x358(%r13),%r12 > 1db: 77 26 ja 203 > > 1dd: 49 c7 44 24 e0 00 00 movq $0x0,-0x20(%r12) > 1e4: 00 00 > 1e2: R_X86_64_32S .text+0x38 > 1e6: 4d 89 74 24 e8 mov %r14,-0x18(%r12) > 1eb: 49 89 7c 24 f0 mov %rdi,-0x10(%r12) > 1f0: 49 89 74 24 f8 mov %rsi,-0x8(%r12) > 1f5: 4d 89 04 24 mov %r8,(%r12) > 1f9: 4d 8d 74 24 e1 lea -0x1f(%r12),%r14 > 1fe: e9 00 00 00 00 jmpq 203 > > 1ff: R_X86_64_PC32 > integerzmgmp_GHCziIntegerziType_runS_info-0x4 > 203: ... ; heap overflow > }}} > This allocates a 5-word closure (containing `a#`, `na#`, `b#`, `nb#`) > whose code is at `.text+0x38` and passes it to `runS`, which does some > `stg_ap`-y things to call back into the closure, which reads its free > variables back from the heap and finally does all the real work. > Altogether it's around two dozen instructions compared to if we could > call directly from `go` to the argument of `runS`. > > The old integer-gmp somehow avoided this particular overhead by instead > using the implicit "unsafePerformIO" of a foreign import prim which > performed both the allocation and the addition. Is this overhead a > necessary consequence of doing the work in multiple steps in Haskell? > > I understand that we cannot allow everything to be inlined and, for > example, the `newBigNat#` to be shared between a `plusBigNat` and > `minusBigNat` with the same arguments. But once `runS` has done its job > of keeping the `newBigNat#/c_mpn_add/unsafeFreeze*` together, it would be > nice to eliminate it completely in the backend when compiling `go`, or > any inlined version of `go`. > > I'm not sure whether this should be fixed in the code generator or in > integer-gmp itself. I'm also aware that this is a tricky subject but > haven't really done my homework on the related tickets, so I might be > missing something important! New description: integer-gmp uses an unsafePerformIO-like operation to work with mutable BigNats (unsafePerformIO and even the IO type are not yet available, since integer-gmp is a dependency of base): {{{#!hs type S s a = State# s -> (# State# s, a #) -- NB: equivalent of GHC.IO.unsafeDupablePerformIO, see notes there runS :: S RealWorld a -> a runS m = lazy (case m realWorld# of (# _, r #) -> r) {-# NOINLINE runS #-} }}} It's tempting to think of such an operation as "free" like an unsafeCoerce, but it is actually somewhat expensive. Consider `plusBigNat` for instance. (Most BigNat operations have a similar structure.) {{{#!hs plusBigNat :: BigNat -> BigNat -> BigNat plusBigNat x y | isTrue# (eqBigNatWord# x 0##) = y | isTrue# (eqBigNatWord# y 0##) = x | isTrue# (nx# >=# ny#) = go x nx# y ny# | True = go y ny# x nx# where go (BN# a#) na# (BN# b#) nb# = runS $ do mbn@(MBN# mba#) <- newBigNat# na# (W# c#) <- liftIO (c_mpn_add mba# a# na# b# nb#) case c# of 0## -> unsafeFreezeBigNat# mbn _ -> unsafeSnocFreezeBigNat# mbn c# nx# = sizeofBigNat# x ny# = sizeofBigNat# y }}} The assembly for `go` begins {{{ 00000000000001d0 : 1d0: 49 83 c4 28 add $0x28,%r12 1d4: 4d 3b a5 58 03 00 00 cmp 0x358(%r13),%r12 1db: 77 26 ja 203 1dd: 49 c7 44 24 e0 00 00 movq $0x0,-0x20(%r12) 1e4: 00 00 1e2: R_X86_64_32S .text+0x38 1e6: 4d 89 74 24 e8 mov %r14,-0x18(%r12) 1eb: 49 89 7c 24 f0 mov %rdi,-0x10(%r12) 1f0: 49 89 74 24 f8 mov %rsi,-0x8(%r12) 1f5: 4d 89 04 24 mov %r8,(%r12) 1f9: 4d 8d 74 24 e1 lea -0x1f(%r12),%r14 1fe: e9 00 00 00 00 jmpq 203 1ff: R_X86_64_PC32 integerzmgmp_GHCziIntegerziType_runS_info-0x4 203: ... ; heap overflow }}} This allocates a 5-word closure (containing `a#`, `na#`, `b#`, `nb#`) whose code is at `.text+0x38` and passes it to `runS`, which does some `stg_ap`-y things to call back into the closure, which reads its free variables back from the heap and finally does all the real work. Altogether it's around two dozen instructions compared to if we could call directly from `go` to the argument of `runS`. The old integer-gmp somehow avoided this particular overhead by instead using the implicit "unsafePerformIO" of a foreign import prim which performed both the allocation and the addition. Is this overhead a necessary consequence of doing the work in multiple steps in Haskell? I understand that we cannot allow everything to be inlined and, for example, the `newBigNat#` to be shared between a `plusBigNat` and `minusBigNat` with the same arguments. But once `runS` has done its job of keeping the `newBigNat#/c_mpn_add/unsafeFreeze*` together, it would be nice to eliminate it completely in the backend when compiling `go`, or any inlined version of `go`. I'm not sure whether this should be fixed in the code generator or in integer-gmp itself. I'm also aware that this is a tricky subject but haven't really done my homework on the related tickets, so I might be missing something important! -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 3 19:08:27 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Nov 2015 19:08:27 -0000 Subject: [GHC] #10678: integer-gmp's runS seems unnecessarily expensive In-Reply-To: <047.1e3027d49179affc6473e88cc8dec51a@haskell.org> References: <047.1e3027d49179affc6473e88cc8dec51a@haskell.org> Message-ID: <062.9e16606749154edba1f164055d94d176@haskell.org> #10678: integer-gmp's runS seems unnecessarily expensive -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1103 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * cc: simonmar (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 3 21:23:26 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Nov 2015 21:23:26 -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.fbde8f0edae087db21644ef4c30cd330@haskell.org> #10365: Implement Semigroup as a superclass of Monoid Proposal (Phase 1) -------------------------------------+------------------------------------- Reporter: gidyn | Owner: quchen 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 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): @rwbarton: That is the most reasonable version of the "non-NonEmpty" version of the proposal I've heard. I'm not yet sold one way or the other, but I'll bring that up at the CLC meeting Thursday and see if that sways folks your way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 3 21:45:30 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Nov 2015 21:45:30 -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.82bc546b599676f2708da06726fcdfa0@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 Rev(s): Phab:D1248 -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"8c80dcc166e4a083086d8b240d84563d0c4c4c50/ghc" 8c80dcc/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8c80dcc166e4a083086d8b240d84563d0c4c4c50" base: Add new Control.Monad.Fail module (re #10751) This is based on David's initial patch augmented by more extensive Haddock comments. This has been broken out of D1248 to reduce its size by splitting the patch into smaller logical pieces. On its own, this new module does nothing interesting yet. Later patches will add support for a different desugaring of `do`-blocks, at which point the new `MonadFail` class will become more useful. Reviewed By: ekmett, austin Differential Revision: https://phabricator.haskell.org/D1424 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 3 22:15:53 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Nov 2015 22:15:53 -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.39c3b9740727377124e3af3c9c77a349@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 Austin Seipp ): In [changeset:"b62605e53c167719b3bf8842eba628061cf22dd1/ghc" b62605e5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b62605e53c167719b3bf8842eba628061cf22dd1" Add `MonadPlus IO` and `Alternative IO` instances This requires adding a new primitive `mplusIO` to `GHC.IO` Update transformers submodule to accomodate extant orphan instances. Reviewed By: austin, bgamari Differential Revision: https://phabricator.haskell.org/D1148 GHC Trac Issues: #10755 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 3 22:26:09 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Nov 2015 22:26:09 -0000 Subject: [GHC] #11058: selected processor does not support ARM mode In-Reply-To: <046.179fa65419f6552c89ce7f996b230033@haskell.org> References: <046.179fa65419f6552c89ce7f996b230033@haskell.org> Message-ID: <061.8257344c5b921a82da00712791e032a1@haskell.org> #11058: selected processor does not support ARM mode ----------------------------------------+------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------ Comment (by nomeata): Yes, let?s continue the discussion here. I don?t doubt that the patch is an important improvement! I am also slightly annoyed that Debian seems to be supporting a rather obsolete(?) ARM variant there... But it is one of the official Debian architectures, so this is a Debian-release-critical problem. > What hardware and distribution is this? This is Debian?s armel architecture on experimental, ?newer port using the "new" ABI (EABI), supported on ARM v4t and higher.?. More info on https://wiki.debian.org/ArmEabiPort -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 3 23:18:55 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Nov 2015 23:18:55 -0000 Subject: [GHC] #11058: selected processor does not support ARM mode In-Reply-To: <046.179fa65419f6552c89ce7f996b230033@haskell.org> References: <046.179fa65419f6552c89ce7f996b230033@haskell.org> Message-ID: <061.5ccc1a72dbeb6aa664810e62e2adc71f@haskell.org> #11058: selected processor does not support ARM mode ----------------------------------------+------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------ Comment (by erikd): I *think* this is fixable, but it requires a bit of fiddling about. As noted by @joeyhess in #10469 the Clang/LLVM target triple for `armel` is `armv4t-unknown-linux-gnueabi`. What we need to fix this is: * `configure.ac` needs to distinguish between Debian's `armhf` and `armel`. * `compiler/llvmGen/LlvmCodeGen/Ppr.hs` needs to set a different target triple depending on whether its build `armel` vs `armhf`. This also assumes that GCC build for `armel` understands the `-marm` flag that was a significant part of the fix for #10375. I'll see if I can get an `armel` chroot set up on one of my `armhf` boards to allow me to debug this. Assuming that works, I should have fix in a couple of days. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 3 23:25:22 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Nov 2015 23:25:22 -0000 Subject: [GHC] #11059: panic in type hole when using 'ScopedTypeVariables' Message-ID: <050.172dcf163f3236046d5eeddf3dba524c@haskell.org> #11059: panic in type hole when using 'ScopedTypeVariables' ----------------------------------------+--------------------------------- Reporter: dimitri-xyz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- I got the following error message: {{{ [1 of 1] Compiling Main ( ghc-bug.hs, ghc-bug.o ) ghc-bug.hs:27:5: Couldn't match type ?m? with ?IO? ?m? is untouchable inside the constraints (Ord seqNum, Num seqNum) bound by the type signature for mkConsecutive :: (Ord seqNum, Num seqNum) => (value -> seqNum) -> Int -> Pipe value value IO () at ghc-bug.hs:22:18-116ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-apple-darwin): No skolem info: m_a1qw[sk] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} when compiling the following file: {{{ {-# LANGUAGE OverloadedStrings #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} import Data.List import Data.IORef import Control.Monad import Data.PriorityQueue.FingerTree as PQ import Pipes import Pipes.Concurrent import qualified Pipes.Prelude as P main = runEffect $ P.stdinLn >-> mkConsecutive length 20 >-> P.stdoutLn -- Ensure messages are received in order. -- FIX ME!! buffer should allow at most 20 messages. mkConsecutive :: forall value seqNum. (Ord seqNum, Num seqNum) => (value -> seqNum) -> Int -> Pipe value value IO () mkConsecutive f maxSize = do msg1 <- await yield msg1 curRef <- liftIO $ newIORef (f msg1, PQ.empty) forever $ do msg <- await (cur, pq) <- liftIO $ readIORef curRef let pq' = PQ.add (f msg) msg pq next cur pq' curRef where -- next :: (Ord seqNum, Num seqNum) => seqNum -- -> PQ.PQueue seqNum value -- -> IORef (seqNum, PQ.PQueue seqNum avalue) -- -> Pipe value value IO () next :: _ next cur pq curRef = case PQ.minView pq of Nothing -> liftIO $ writeIORef curRef (cur, pq) Just (minVal, pq') -> if f minVal == cur + 1 then do yield minVal next (f minVal) pq' curRef else do liftIO $ writeIORef curRef (cur, pq) }}} I am using Pipes-4.1.6 and fingertree-0.1.1.0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 4 02:58:04 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Nov 2015 02:58:04 -0000 Subject: [GHC] #11058: selected processor does not support ARM mode In-Reply-To: <046.179fa65419f6552c89ce7f996b230033@haskell.org> References: <046.179fa65419f6552c89ce7f996b230033@haskell.org> Message-ID: <061.993cee90c841cb6f34235dcd4d51d27a@haskell.org> #11058: selected processor does not support ARM mode ----------------------------------------+------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------ Comment (by erikd): Ok, I have an `armel` chroot and I have reproduced this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 4 04:17:57 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Nov 2015 04:17:57 -0000 Subject: [GHC] #11060: Failing tests on 32 bit platforms Message-ID: <044.8903e45b189743246ba884746b94acaa@haskell.org> #11060: Failing tests on 32 bit platforms -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Test Suite | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- On 32 bit PowerPC and Arm I've been getting about 20 new test failures (starting about a week ago). For example: {{{ --- ./simplCore/should_compile/T8274.stdout.normalised +++ ./simplCore/should_compile/T8274.run.stdout.normalised @@ -1,10 +1,10 @@ T8274.$trModule2 = TrNameS "main"# T8274.$trModule1 = TrNameS "T8274"# T8274.$tcP1 = TrNameS "P"# - 11095028091707994303## - 9476557054198009608## + 11095028091707994303L## + 9476557054198009608L## T8274.$tcN1 = TrNameS "N"# - 7479687563082171902## - 17616649989360543185## + 7479687563082171902L## + 17616649989360543185L## p = T8274.Positives 42# 4.23# 4.23## '4'# 4## n = T8274.Negatives -4# -4.0# -4.0## \ No newline at end of file *** unexpected failure for T8274(normal) }}} This is simply a matter of a difference between the expected output `123##` vs `123L##`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 4 05:32:27 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Nov 2015 05:32:27 -0000 Subject: [GHC] #10435: catastrophic exception-handling disablement on Windows Server 2008 R2 In-Reply-To: <047.bc42599240078110c16528fec3996433@haskell.org> References: <047.bc42599240078110c16528fec3996433@haskell.org> Message-ID: <062.03896eba6a3a6302bc3dec9085415760@haskell.org> #10435: catastrophic exception-handling disablement on Windows Server 2008 R2 -------------------------------------+------------------------------------- Reporter: malcolmw | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 7.10.3 Component: Runtime System | Version: 7.10.1 Resolution: fixed | Keywords: windows, | exceptions Operating System: Windows | Architecture: x86 Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #9218 #10726 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * milestone: => 7.10.3 Comment: Fix to this has been merged back to `7.10.3` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 4 06:02:39 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Nov 2015 06:02:39 -0000 Subject: [GHC] #11009: Errors reading stdin on Windows In-Reply-To: <045.6536b0b9909b2bd209cff5be9e0bf17c@haskell.org> References: <045.6536b0b9909b2bd209cff5be9e0bf17c@haskell.org> Message-ID: <060.a6798169cea2df63326ac135df509501@haskell.org> #11009: Errors reading stdin on Windows -------------------------------------+------------------------------------- Reporter: ncreep | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): I am not sure, I don't see any debug statements around the allocation code, but take a look here https://ghc.haskell.org/trac/ghc/wiki/Debugging -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 4 06:27:24 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Nov 2015 06:27:24 -0000 Subject: [GHC] #11058: selected processor does not support ARM mode In-Reply-To: <046.179fa65419f6552c89ce7f996b230033@haskell.org> References: <046.179fa65419f6552c89ce7f996b230033@haskell.org> Message-ID: <061.5d1805a6ea0dcac919014a27c3217de7@haskell.org> #11058: selected processor does not support ARM mode ----------------------------------------+------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------ Comment (by erikd): Tried simple hack of: {{{ diff --git a/compiler/llvmGen/LlvmCodeGen/Ppr.hs b/compiler/llvmGen/LlvmCodeGen/Ppr.hs index d7ddf80..03c369c 100644 --- a/compiler/llvmGen/LlvmCodeGen/Ppr.hs +++ b/compiler/llvmGen/LlvmCodeGen/Ppr.hs @@ -50,7 +50,10 @@ moduleLayout = sdocWithPlatform $ \platform -> Platform { platformArch = ArchX86_64, platformOS = OSLinux } -> text "target datalayout = \"e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64\"" $+$ text "target triple = \"x86_64-linux-gnu\"" - Platform { platformArch = ArchARM {}, platformOS = OSLinux } -> + Platform { platformArch = ArchARM { armISA = ARMv5 }, platformOS = OSLinux } -> + text "target datalayout = \"e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:64:128-a0:0:64-n32\"" + $+$ text "target triple = \"armv4t-unknown-linux-gnueabihf\"" + Platform { platformArch = ArchARM {}, platformOS = OSLinux } -> text "target datalayout = \"e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:64:128-a0:0:64-n32\"" $+$ text "target triple = \"armv6-unknown-linux-gnueabihf\"" Platform { platformArch = ArchARM {}, platformOS = OSAndroid } -> }}} but then linking the RTS fails with: {{{ /usr/bin/ar: creating rts/dist/build/libHSrts_thr_debug.a /usr/bin/ld.gold: error: rts/dist/build/StgStartup.dyn_o uses VFP register arguments, output does not /usr/bin/ld.gold: error: rts/dist/build/Updates.dyn_o uses VFP register arguments, output does not /usr/bin/ld.gold: error: rts/dist/build/StgMiscClosures.dyn_o uses VFP register arguments, output does not /usr/bin/ld.gold: error: rts/dist/build/Apply.dyn_o uses VFP register arguments, output does not /usr/bin/ld.gold: error: rts/dist/build/HeapStackCheck.dyn_o uses VFP register arguments, output does not /usr/bin/ld.gold: error: rts/dist/build/Exception.dyn_o uses VFP register arguments, output does not /usr/bin/ld.gold: error: rts/dist/build/StgStdThunks.dyn_o uses VFP register arguments, output does not /usr/bin/ld.gold: error: rts/dist/build/PrimOps.dyn_o uses VFP register arguments, output does not /usr/bin/ld.gold: error: rts/dist/build/AutoApply.dyn_o uses VFP register arguments, output does not }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 4 07:16:03 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Nov 2015 07:16:03 -0000 Subject: [GHC] #11059: panic in type hole when using 'ScopedTypeVariables' In-Reply-To: <050.172dcf163f3236046d5eeddf3dba524c@haskell.org> References: <050.172dcf163f3236046d5eeddf3dba524c@haskell.org> Message-ID: <065.2632702bca6f860e78caecd942934829@haskell.org> #11059: panic in type hole when using 'ScopedTypeVariables' ---------------------------------+---------------------------------------- Reporter: dimitri-xyz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by simonpj): While I have not reproduced this, it looks like a dup of #10045. Can you try with HEAD? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 4 13:49:03 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Nov 2015 13:49:03 -0000 Subject: [GHC] #11039: Panic with incorrect pattern synonym signature In-Reply-To: <049.d27e3ae5d026b330a69421484a0cabf6@haskell.org> References: <049.d27e3ae5d026b330a69421484a0cabf6@haskell.org> Message-ID: <064.512f9bf27402548e1df794bbffa58cd8@haskell.org> #11039: Panic with incorrect pattern synonym signature -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | patsyn/should_fail/T11039 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * keywords: => PatternSynonyms * testcase: => patsyn/should_fail/T11039 * component: Compiler => Compiler (Type checker) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 4 13:53:59 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Nov 2015 13:53:59 -0000 Subject: [GHC] #11041: EventLog write fails if entire buffer is not written In-Reply-To: <049.1dbeaea4e627c4c0bcd66b984b44ecbf@haskell.org> References: <049.1dbeaea4e627c4c0bcd66b984b44ecbf@haskell.org> Message-ID: <064.fef09d5dc0050c4b4b7c8d394e710d3c@haskell.org> #11041: EventLog write fails if entire buffer is not written -------------------------------------+------------------------------------- Reporter: sseverance | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Runtime System | Version: 7.10.2 Resolution: fixed | Keywords: eventlog Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: none Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1415 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => closed * testcase: => none * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 4 14:32:46 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Nov 2015 14:32:46 -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.db8a5b03439c5747e0a210c38b9d0d11@haskell.org> #10872: More informative assertion for non-unique TH names -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: goldfire 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * owner: jstolarek => goldfire Comment: I have solved this in the course of my work on #7961. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 4 14:37:34 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Nov 2015 14:37:34 -0000 Subject: [GHC] #3303: Allow multi-line deprecation messages. In-Reply-To: <045.504e3e8992fc7aa97369c63a127f30a6@haskell.org> References: <045.504e3e8992fc7aa97369c63a127f30a6@haskell.org> Message-ID: <060.7644899cc7a1ec3513140b19f93a8ea2@haskell.org> #3303: Allow multi-line deprecation messages. -------------------------------------+------------------------------------- Reporter: duncan | Owner: igloo Type: merge | Status: closed Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | parser/should_compile/T3303 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * testcase: => parser/should_compile/T3303 Comment: In commit bf510aa86f3161c981b3432d43417874c38adf8f: {{{ Author: Ian Lynagh Date: Wed Aug 12 18:57:43 2009 +0000 Add a test for #3303: multiline deprecated warnings }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 4 14:39:35 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Nov 2015 14:39:35 -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.1297b29243a6ae55132c772012ac6aac@haskell.org> #10872: More informative assertion for non-unique TH names -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: goldfire 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jstolarek): Is the solution part od Phab:D808? I'd love to see how you solved that - I still don't understand where I went wrong with my implementation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 4 15:53:39 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Nov 2015 15:53:39 -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.a13632b98861de4b065583122cd6f6fc@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: #10846 | Differential Rev(s): Phab:D1422 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): (I think you are referring to my second version, post-wrinkle.) You are right. I was hi-jacking `IPOccOrigin` to do "combine and default to empty stack". But yes, I think we can allow it ''not'' to add a location on its own behalf. If you wanted the current effect of `?loc`, you can always get the same effect by using {{{ currentLoc :: ?loc :: Location => Location currentLoc = ?loc }}} We'd better document this carefully though. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 4 16:21:37 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Nov 2015 16:21:37 -0000 Subject: [GHC] #11050: [bug] ModOrigin: hidden module redefined In-Reply-To: <049.f4e3e81343960e7ba9d67c8e78ae8ab2@haskell.org> References: <049.f4e3e81343960e7ba9d67c8e78ae8ab2@haskell.org> Message-ID: <064.46f3de3e589fd657d3d600ec0f506a69@haskell.org> #11050: [bug] ModOrigin: hidden module redefined -------------------------------------+------------------------------------- Reporter: codeonwort | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * milestone: 7.10.3 => 8.0.1 Comment: To reproduce on Ubuntu with ghc-7.10.2: * Install the `haste-compiler` Debian package from http://haste- lang.org/downloads/ * Create `T11050.hs`: {{{ import Haste.DOM main = do addChild undefined undefined return () }}} * Run {{{ $ ghc -no-user-package-db -package-db=/usr/lib/haste-compiler/x86_64 -linux-haste-0.5.2-ghc-7.10.2/package.conf.d T11050.hs -fforce-recomp }}} Somehow, `haste` managed to create a package (`haste-lib`) that lists all hidden modules twice: {{{ $ ghc-pkg --package-db=/usr/lib/haste-compiler/x86_64-linux- haste-0.5.2-ghc-7.10.2/package.conf.d describe haste-lib ... hidden-modules: Haste.App.Client Haste.App.Monad Haste.App.Protocol Haste.Audio.Events Haste.Binary.Get Haste.Binary.Put Haste.Binary.Types Haste.Compiler.Flags Haste.Concurrent.Monad Haste.Concurrent.Ajax Haste.DOM.Core Haste.Events.BasicEvents Haste.Events.Core Haste.Events.KeyEvents Haste.Events.MouseEvents Haste.Events.TouchEvents Haste.Hash Haste.Random Haste.Timer Haste.App.Client Haste.App.Monad Haste.App.Protocol Haste.Audio.Events Haste.Binary.Get Haste.Binary.Put Haste.Binary.Types Haste.Compiler.Flags Haste.Concurrent.Monad Haste.Concurrent.Ajax Haste.DOM.Core Haste.Events.BasicEvents Haste.Events.Core Haste.Events.KeyEvents Haste.Events.MouseEvents Haste.Events.TouchEvents Haste.Hash Haste.Random Haste.Timer }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 4 16:34:29 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Nov 2015 16:34:29 -0000 Subject: [GHC] #11049: Allow CallStacks to be hidden or cut In-Reply-To: <046.99c74047c61a8c0886c2d3ab954b8b7d@haskell.org> References: <046.99c74047c61a8c0886c2d3ab954b8b7d@haskell.org> Message-ID: <061.a9789ce0e9db0cf32021b3eabd33ef40@haskell.org> #11049: Allow CallStacks to be hidden or cut -------------------------------------+------------------------------------- Reporter: nomeata | Owner: gridaphobe 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: #11035 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm sorry but I don't understand the Description at all. Could you elaborate it, at least with examples, both to explain and to motivate? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 4 17:05:18 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Nov 2015 17:05:18 -0000 Subject: [GHC] #11049: Allow CallStacks to be hidden or cut In-Reply-To: <046.99c74047c61a8c0886c2d3ab954b8b7d@haskell.org> References: <046.99c74047c61a8c0886c2d3ab954b8b7d@haskell.org> Message-ID: <061.043b54db4dbf11f8f9279f5ae5e3564f@haskell.org> #11049: Allow CallStacks to be hidden or cut -------------------------------------+------------------------------------- Reporter: nomeata | Owner: gridaphobe 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: #11035 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Sure. Assume we are given a function {{{#!hs readFile :: ?callstack :: CallStack => FilePath -> IO () }}} that prints a stack trace with every IO error that happens (`bar` in the description). Now assume we want to implement a function that uses the above, for example {{{#!hs readConfig :: IO Config readConfig = do s <- readFile "config.txt" -- line 42 return (parseConfig s) }}} and we deliberately do not want that function have a `?_::CallStack` constraint. What will happen when `config.txt` will be missing? `readFile` will raise an exception that includes a call stack that tells the user that this was raised due to `readFile` being called in line 42. But as the author of the `readConfig` function, I do not want this information (which is not very helpful to the user) to be omitted. This is the first use case. The second is related. I might now allow `readConfig` to have a `?_::CallStack` constraint, e.g. {{{#!hs readConfig :: ?callstack::CallStack => IO Config readConfig = do s <- readFile "config.txt" -- line 42 return (parseConfig s) }}} But I do want to provide a polished API, and not leak any information to the users of my API about my internals. So _do_ want the `?callstack` to be passed on to `readFile` and be included in the exception, but I _don?t_ want it to mention line 42; instead it should end with the (for the user relevant) information where `readConfig` was called. This is the second use case. So now to the suggested implementation: In both cases, I want to insert a marker into the callstack that makes the call stack printer ignore anything ?below? or ?after? it. This is the suggested `rootCallStack` value, and it allows me to write {{{#!hs readConfig :: IO Config readConfig = do s <- let ?callstack = rootCallStack in readFile "config.txt" -- line 42 return (parseConfig s) }}} resp. {{{#!hs readConfig :: ?callstack::CallStack => IO Config readConfig = do s <- let ?callstack = rootCallStack `pushCallStack` ?callstack in readFile "config.txt" -- line 42 return (parseConfig s) }}} to implement the above. The implementation sketch is ad-hoc, and there might be more elegant variants. This is not not necessarily an advocation of such ?hiding internals?, but I think it should be possible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 4 17:18:10 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Nov 2015 17:18:10 -0000 Subject: [GHC] #11059: panic in type hole when using 'ScopedTypeVariables' In-Reply-To: <050.172dcf163f3236046d5eeddf3dba524c@haskell.org> References: <050.172dcf163f3236046d5eeddf3dba524c@haskell.org> Message-ID: <065.09d391904d7c7d6993594dc8343fc004@haskell.org> #11059: panic in type hole when using 'ScopedTypeVariables' ---------------------------------+---------------------------------------- Reporter: dimitri-xyz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by dimitri-xyz): I'm a newbie here. I don't know what is required to build HEAD, but I'll try to build it this weekend and update here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 4 17:23:52 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Nov 2015 17:23:52 -0000 Subject: [GHC] #11044: Parse error on empty multi-line deprecation warnings In-Reply-To: <044.eca441d1c47bb055a7995ead40767af4@haskell.org> References: <044.eca441d1c47bb055a7995ead40767af4@haskell.org> Message-ID: <059.fdd7674978da7d0cc2b659ed0aa6361c@haskell.org> #11044: Parse error on empty multi-line deprecation warnings -------------------------------------+------------------------------------- Reporter: inaki | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | parser/should_compile/T3303 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1433 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch * testcase: => parser/should_compile/T3303 * differential: => Phab:D1433 * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 4 17:33:15 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Nov 2015 17:33:15 -0000 Subject: [GHC] #11045: Loading temp shared object failed - undefined symbol In-Reply-To: <046.9d39dd7431e7e6dfe6663e1ceca6d812@haskell.org> References: <046.9d39dd7431e7e6dfe6663e1ceca6d812@haskell.org> Message-ID: <061.08efe6272140ef36e4546e9c5097a749@haskell.org> #11045: Loading temp shared object failed - undefined symbol -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Linking) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * component: Compiler => Compiler (Linking) Comment: Are you able to reproduce this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 4 17:44:35 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Nov 2015 17:44:35 -0000 Subject: [GHC] #11049: Allow CallStacks to be hidden or cut In-Reply-To: <046.99c74047c61a8c0886c2d3ab954b8b7d@haskell.org> References: <046.99c74047c61a8c0886c2d3ab954b8b7d@haskell.org> Message-ID: <061.018444e1cb1512554489b4603753e2bf@haskell.org> #11049: Allow CallStacks to be hidden or cut -------------------------------------+------------------------------------- Reporter: nomeata | Owner: gridaphobe 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: #11035 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gridaphobe): I think this is an interesting idea, and I think it could be implemented entirely in `base` without any additional compiler support. So I'm in favor of doing it; we can let users decide if the implementation hiding feature is useful. The one wrinkle is that this will only work when we have a full call- stack, ie every function in the path from `readConfig` to `error` '''must''' take a call-stack. Otherwise the chain will be broken (remember, call-stacks are just implicit parameters with a special rule for function calls) and we'll still see a partial call-stack. For example, if I change your example so that `readFile` does not take a call-stack {{{#!haskell readFile :: FilePath -> IO String readFile f = ... error "file not found" ... readConfig :: IO Config readConfig = do s <- let ?callstack = rootCallStack in readFile "config.txt" -- line 42 return (parseConfig s) }}} `readConfig` will still print a call-stack that leaks internals if `config.txt` does not exist. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 4 18:21:41 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Nov 2015 18:21:41 -0000 Subject: [GHC] #11059: panic in type hole when using 'ScopedTypeVariables' In-Reply-To: <050.172dcf163f3236046d5eeddf3dba524c@haskell.org> References: <050.172dcf163f3236046d5eeddf3dba524c@haskell.org> Message-ID: <065.9297a6924939609e4f6a09b3c6bac90a@haskell.org> #11059: panic in type hole when using 'ScopedTypeVariables' ---------------------------------+---------------------------------------- Reporter: dimitri-xyz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by goldfire): We generally prefer if you can reproduce the bug without external libraries. In this case, not only do you use `pipes` and `fingertree`, but you also use `pipes-concurrency`. The latter, sadly, does not build with HEAD because it depends on `stm`, which doesn't build. So I've tried testing this and failed, but you will too, with the exact same problem. Can you simplify your test case to remove the dependencies? If there are no packages used, it's much much easier for us to test. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 4 19:19:20 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Nov 2015 19:19:20 -0000 Subject: [GHC] #11049: Allow CallStacks to be hidden or cut In-Reply-To: <046.99c74047c61a8c0886c2d3ab954b8b7d@haskell.org> References: <046.99c74047c61a8c0886c2d3ab954b8b7d@haskell.org> Message-ID: <061.35ef298883d2a9d1420e78f72bc44d13@haskell.org> #11049: Allow CallStacks to be hidden or cut -------------------------------------+------------------------------------- Reporter: nomeata | Owner: gridaphobe 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: #11035 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): That's helpful. So we make public both `rootStack` and `pushCallStack`. And we allow implicit-parameter bindings for `?loc :: CallStack`. (I suppose that's always been possible, and you can use it already to install a `CallStack` from somewhere else. I guess that's an advantage.) Would you like to turn the description, and your comment:3, and any subsequent stuff, into a wiki page (perhaps the same page as the current `CallStack` one. Otherwise we have to mentally compose all these things in our heads. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 4 20:08:54 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Nov 2015 20:08:54 -0000 Subject: [GHC] #8761: Make pattern synonyms work with Template Haskell In-Reply-To: <047.c5d8ed063e9e82c354c50c5724ebe787@haskell.org> References: <047.c5d8ed063e9e82c354c50c5724ebe787@haskell.org> Message-ID: <062.09891bac112fcc545ffe7ff2552e951c@haskell.org> #8761: Make pattern synonyms work with Template Haskell -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by cocreature): * cc: cocreature (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 4 22:58:41 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Nov 2015 22:58:41 -0000 Subject: [GHC] #11049: Allow CallStacks to be hidden or cut In-Reply-To: <046.99c74047c61a8c0886c2d3ab954b8b7d@haskell.org> References: <046.99c74047c61a8c0886c2d3ab954b8b7d@haskell.org> Message-ID: <061.88a45bf4a5fb13b3e0abeb9a0625af09@haskell.org> #11049: Allow CallStacks to be hidden or cut -------------------------------------+------------------------------------- Reporter: nomeata | Owner: gridaphobe 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: #11035 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): > For example, if I change your example so that readFile does not take a call-stack... Right, but that is a deliberate decision by the author of `readFile` then; I?m fine with that. > Would you like to turn the description, and your comment:3, and any subsequent stuff, into a wiki page I can; gridaphobe, can you tell me where precisely you?d like to see this documentation? Or maybe it should rather go directly into the haddocks or the user guide? (Keeping docs good and up-to-date is tricky, so I?d aim for having just one place that documents stuff.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 4 23:01:39 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Nov 2015 23:01:39 -0000 Subject: [GHC] #11049: Allow CallStacks to be hidden or cut In-Reply-To: <046.99c74047c61a8c0886c2d3ab954b8b7d@haskell.org> References: <046.99c74047c61a8c0886c2d3ab954b8b7d@haskell.org> Message-ID: <061.050b362cd0e2bf1cbe9eca361ed113c2@haskell.org> #11049: Allow CallStacks to be hidden or cut -------------------------------------+------------------------------------- Reporter: nomeata | Owner: gridaphobe 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: #11035 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Let's initially have the overall design, movitation, examples, on a wiki page. That's what we usually do. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 4 23:50:22 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Nov 2015 23:50:22 -0000 Subject: [GHC] #4340: Add alignment to hsc2hs template In-Reply-To: <044.7302eb3b745a386507fb3de540273406@haskell.org> References: <044.7302eb3b745a386507fb3de540273406@haskell.org> Message-ID: <059.279ebfff33400bcd450603929809c1c2@haskell.org> #4340: Add alignment to hsc2hs template -------------------------------------+------------------------------------- Reporter: mitar | Owner: RyanGlScott Type: feature request | Status: new Priority: low | Milestone: 8.0.1 Component: Compiler (FFI) | 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: #10272 | Differential Rev(s): Phab:D1436 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * owner: => RyanGlScott * differential: => Phab:D1436 * related: => #10272 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 4 23:51:03 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Nov 2015 23:51:03 -0000 Subject: [GHC] #10272: hsc2hs : directive let cannot be handled in cross-compilation mode In-Reply-To: <044.8913742417593b59443e51343d8c3d48@haskell.org> References: <044.8913742417593b59443e51343d8c3d48@haskell.org> Message-ID: <059.0f4e212ae17e6e23291964ea1632e863@haskell.org> #10272: hsc2hs : directive let cannot be handled in cross-compilation mode -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: hsc2hs | Version: 7.11 Resolution: | Keywords: cross- | compiling Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #10070 | Differential Rev(s): Phab:D1436 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * differential: => Phab:D1436 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 5 01:28:08 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Nov 2015 01:28:08 -0000 Subject: [GHC] #11058: selected processor does not support ARM mode In-Reply-To: <046.179fa65419f6552c89ce7f996b230033@haskell.org> References: <046.179fa65419f6552c89ce7f996b230033@haskell.org> Message-ID: <061.b5729628e9cc9ad7763bec3ea9d5efbb@haskell.org> #11058: selected processor does not support ARM mode ----------------------------------------+------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------ Comment (by erikd): By setting the LLVM target to `armv4t-unknown-linux-gnueabihf`, adding `-float-abi=soft` to the LLVM ABI options and adding `-march=armv4t` to the GCC command line I got something that builds part of the way, but the `inplace/bin/ghc-stage2` binary segfaults on the first run. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 5 06:51:23 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Nov 2015 06:51:23 -0000 Subject: [GHC] #11061: GHC 7.10.3 RC1: build broken on OS X Message-ID: <047.2fb92e0b53c347aa06bd0382e7c67a8a@haskell.org> #11061: GHC 7.10.3 RC1: build broken on OS X -------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.3 Component: Build System | Version: 7.10.2 Keywords: | Operating System: MacOS X Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Richard reported on ghc-devs: > {{{ > checking for readelf... no > configure: error: cannot find readelf in your PATH > }}} OS X uses Mach-O not ELF. So `readelf` does not work on Mach-O binaries. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 5 08:32:29 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Nov 2015 08:32:29 -0000 Subject: [GHC] #11059: panic in type hole when using 'ScopedTypeVariables' In-Reply-To: <050.172dcf163f3236046d5eeddf3dba524c@haskell.org> References: <050.172dcf163f3236046d5eeddf3dba524c@haskell.org> Message-ID: <065.311425facc9f0b2eeb9d45a502cb4c2b@haskell.org> #11059: panic in type hole when using 'ScopedTypeVariables' ---------------------------------+---------------------------------------- Reporter: dimitri-xyz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by svenpanne): #10967 ;-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 5 10:55:48 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Nov 2015 10:55:48 -0000 Subject: [GHC] #11061: GHC 7.10.3 RC1: build broken on OS X In-Reply-To: <047.2fb92e0b53c347aa06bd0382e7c67a8a@haskell.org> References: <047.2fb92e0b53c347aa06bd0382e7c67a8a@haskell.org> Message-ID: <062.c7b8394abd81eaccaff2b50b4e5c4e0c@haskell.org> #11061: GHC 7.10.3 RC1: build broken on OS X -------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.10.3 Component: Build System | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: Indeed the configure check should be skipped on Darwin. This is fixed in 7f8fc1c9db5bef2dea05e001488d5bc7c8b38575. I'll push an rc2 with this and one other fix today. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 5 11:21:56 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Nov 2015 11:21:56 -0000 Subject: [GHC] #11046: lookupTypeName does not support type operators not starting with : In-Reply-To: <045.eabc8eeec9cc920f3e0838e9774eff4d@haskell.org> References: <045.eabc8eeec9cc920f3e0838e9774eff4d@haskell.org> Message-ID: <060.6fe65afb84dd79e328d70c70f80e056b@haskell.org> #11046: lookupTypeName does not support type operators not starting with : -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.2 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): Relevant commit 85926ae6c63a62e4f23423f220588875c8f1ab45: {{{ Author: Iavor S. Diatchki Date: Sun Jan 8 16:33:51 2012 -0800 Change -XTypeOperators to treat all type-operators as type- constructors. Previously, only type operators starting with ":" were type constructors, and writing "+" in a type resulted in a type variable. Now, type variables are always ordinary identifiers, and all operators are treated as constructors. One can still write type variables in infix form though, for example, "a `fun` b" is a type expression with 3 type variables: "a", "fun", and "b". Writing (+) in an import/export list always refers to the value (+) and not the type. To refer to the type one can write either "type (+)", or provide an explicit suobrdinate list (e.g., "(+)()"). For clarity, one can also combine the two, for example "type (+)(A,B,C)" is also accepted and means the same thing as "(+)(A,B,C)" (i.e., export the type (+), with the constructors A,B,and C). }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 5 12:42:01 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Nov 2015 12:42:01 -0000 Subject: [GHC] #11046: lookupTypeName does not support type operators not starting with : In-Reply-To: <045.eabc8eeec9cc920f3e0838e9774eff4d@haskell.org> References: <045.eabc8eeec9cc920f3e0838e9774eff4d@haskell.org> Message-ID: <060.59081e7e8778661101e3b8f33220b0db@haskell.org> #11046: lookupTypeName does not support type operators not starting with : -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | testsuite/tests/th/TH_lookupName.hs Blocked By: | Blocking: Related Tickets: #10583 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * testcase: => testsuite/tests/th/TH_lookupName.hs * related: => #10583 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 5 14:53:48 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Nov 2015 14:53:48 -0000 Subject: [GHC] #11009: Errors reading stdin on Windows In-Reply-To: <045.6536b0b9909b2bd209cff5be9e0bf17c@haskell.org> References: <045.6536b0b9909b2bd209cff5be9e0bf17c@haskell.org> Message-ID: <060.5f5ff0f8e3de451b5d5d2658b32c333a@haskell.org> #11009: Errors reading stdin on Windows -------------------------------------+------------------------------------- Reporter: ncreep | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ncreep): Thanks, I tried using `gdb`, after running the code, the command `where` says `No stack.`. I've no experience with `gdb` so maybe I'm doing something wrong. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 5 15:05:59 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Nov 2015 15:05:59 -0000 Subject: [GHC] #11059: panic in type hole when using 'ScopedTypeVariables' In-Reply-To: <050.172dcf163f3236046d5eeddf3dba524c@haskell.org> References: <050.172dcf163f3236046d5eeddf3dba524c@haskell.org> Message-ID: <065.be2a4f2bc38a4b2cfac570f81ead02cd@haskell.org> #11059: panic in type hole when using 'ScopedTypeVariables' -------------------------------------+------------------------------------- Reporter: dimitri-xyz | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10045 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * os: MacOS X => Unknown/Multiple * related: => #10045 Comment: goldfire: you can uncomment `BUILD_EXTRA_PKGS=YES` in your `mk/build.mk` file. `make` will then also build the packages that have tag=extra in the `./packages` file (currently `parallel` and `stm`). After doing so, and installing all the other packages, I get: {{{ $ ~/ghc-quick/inplace/bin/ghc-stage2 Test.hs [1 of 1] Compiling Main ( Test.hs, Test.o ) Test.hs:38:17: error: Found type wildcard ?_? standing for ?seqNum -> PQueue k value -> IORef (seqNum, PQueue k value) -> Proxy x' x () value m ()? Where: ?value? is a rigid type variable bound by the type signature for: mkConsecutive :: (Ord seqNum, Num seqNum) => (value -> seqNum) -> Int -> Pipe value value IO () at Test.hs:22:25 ?seqNum? is a rigid type variable bound by the type signature for: mkConsecutive :: (Ord seqNum, Num seqNum) => (value -> seqNum) -> Int -> Pipe value value IO () at Test.hs:22:31 ?k? is a rigid type variable bound by the inferred type of next :: (Ord k, MonadIO m) => seqNum -> PQueue k value -> IORef (seqNum, PQueue k value) -> Proxy x' x () value m () at Test.hs:39:9 ?m? is a rigid type variable bound by the inferred type of next :: (Ord k, MonadIO m) => seqNum -> PQueue k value -> IORef (seqNum, PQueue k value) -> Proxy x' x () value m () at Test.hs:39:9 ?x'? is a rigid type variable bound by the inferred type of next :: (Ord k, MonadIO m) => seqNum -> PQueue k value -> IORef (seqNum, PQueue k value) -> Proxy x' x () value m () at Test.hs:39:9 ?x? is a rigid type variable bound by the inferred type of next :: (Ord k, MonadIO m) => seqNum -> PQueue k value -> IORef (seqNum, PQueue k value) -> Proxy x' x () value m () at Test.hs:39:9 To use the inferred type, enable PartialTypeSignatures Relevant bindings include maxSize :: Int (bound at Test.hs:23:17) f :: value -> seqNum (bound at Test.hs:23:15) mkConsecutive :: (value -> seqNum) -> Int -> Pipe value value IO () (bound at Test.hs:23:1) In the type signature for: next :: _ In an equation for ?mkConsecutive?: mkConsecutive f maxSize = do { msg1 <- await; yield msg1; curRef <- liftIO $ newIORef (f msg1, empty); .... } where next :: _ next cur pq curRef = case minView pq of { Nothing -> liftIO $ writeIORef curRef ... Just (minVal, pq') -> ... } Test.hs:39:9: error: No instance for (Ord k) When checking that ?next? has the inferred type next :: forall k (m :: * -> *) x' x. seqNum -> PQueue k value -> IORef (seqNum, PQueue k value) -> Proxy x' x () value m () Probable cause: the inferred type is ambiguous In an equation for ?mkConsecutive?: mkConsecutive f maxSize = do { msg1 <- await; yield msg1; curRef <- liftIO $ newIORef (f msg1, empty); .... } where next :: _ next cur pq curRef = case minView pq of { Nothing -> liftIO $ writeIORef curRef ... Just (minVal, pq') -> ... } }}} So this indeed looks like a duplicate of #10045: a combination of a typed hole and a missing instance. dimitri-xyz: as a workaround, you can use `-fdefer-type-errors`, and you'll see those same two errors as warnings. I'm not adding another test, because of all the dependencies, and because we have plenty of tests for this bug already (another one in #10999). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 5 17:00:38 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Nov 2015 17:00:38 -0000 Subject: [GHC] #11062: Type families + hs-boot files = panic Message-ID: <047.7c49c2177d004f32c0696dfdb91a7434@haskell.org> #11062: Type families + hs-boot files = panic -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: high | 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 Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I have these modules: A.hs-boot: {{{ {-# LANGUAGE TypeFamilies #-} module A where type family F a }}} B.hs: {{{ {-# LANGUAGE TypeFamilies #-} module B where import {-# SOURCE #-} A type instance F Int = Bool }}} A.hs: {{{ {-# LANGUAGE TypeFamilies #-} module A where import B type family F a }}} And now this happens: {{{ rae:11:50:47 ~/temp/bug> ~/Documents/ghc-cur/inplace/bin/ghc-stage2 --version The Glorious Glasgow Haskell Compilation System, version 7.11.20151104 rae:11:50:50 ~/temp/bug> ~/Documents/ghc-cur/inplace/bin/ghc-stage2 -c A .hs-boot rae:11:50:52 ~/temp/bug> ~/Documents/ghc-cur/inplace/bin/ghc-stage2 -c B.hs rae:11:50:54 ~/temp/bug> ~/Documents/ghc-cur/inplace/bin/ghc-stage2 -c A.hs ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.11.20151104 for x86_64-apple-darwin): tcIfaceGlobal (local): not found: F [] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug rae:11:50:57 ~/temp/bug> }}} The problem occurs only in one-shot mode. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 5 17:02:49 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Nov 2015 17:02:49 -0000 Subject: [GHC] #11062: Type families + hs-boot files = panic In-Reply-To: <047.7c49c2177d004f32c0696dfdb91a7434@haskell.org> References: <047.7c49c2177d004f32c0696dfdb91a7434@haskell.org> Message-ID: <062.8d109f882e31bfd00cd2c76224a17535@haskell.org> #11062: Type families + hs-boot files = panic -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: high | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * Attachment "T11062.zip" added. Test case files -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 5 19:30:33 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Nov 2015 19:30:33 -0000 Subject: [GHC] #11062: Type families + hs-boot files = panic In-Reply-To: <047.7c49c2177d004f32c0696dfdb91a7434@haskell.org> References: <047.7c49c2177d004f32c0696dfdb91a7434@haskell.org> Message-ID: <062.cb8278dc63e0cd25a7ecb2200fdf9ea7@haskell.org> #11062: Type families + hs-boot files = panic -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: high | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): Oddly enough this is a regression from GHC 7.6.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 5 19:30:42 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Nov 2015 19:30:42 -0000 Subject: [GHC] #11062: Type families + hs-boot files = panic In-Reply-To: <047.7c49c2177d004f32c0696dfdb91a7434@haskell.org> References: <047.7c49c2177d004f32c0696dfdb91a7434@haskell.org> Message-ID: <062.0d2d2ddf457b00c63cbd06fc903aa5a0@haskell.org> #11062: Type families + hs-boot files = panic -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: high | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * cc: ezyang (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 5 22:41:21 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Nov 2015 22:41:21 -0000 Subject: [GHC] #10583: Chaos in Lexeme.hs In-Reply-To: <047.ca228b2a0d43586fb2828ecd680f46fc@haskell.org> References: <047.ca228b2a0d43586fb2828ecd680f46fc@haskell.org> Message-ID: <062.46daeb2c763497d8394d4db53df095ec@haskell.org> #10583: Chaos in Lexeme.hs -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire 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: 10582, 11046 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by oerjan): * cc: oerjan (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 6 05:03:55 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Nov 2015 05:03:55 -0000 Subject: [GHC] #11063: ghc -split-objs fails on Unicode file names Message-ID: <048.f9c863f2837410de9414e540724123e7@haskell.org> #11063: ghc -split-objs fails on Unicode file names -------------------------------------+------------------------------------- Reporter: strake888 | 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 Rev(s): | Wiki Page: -------------------------------------+------------------------------------- See enclosed example. {{{ $ chdir example $ ghc -split-objs Main [1 of 2] Compiling P?lda ( P?lda.hs, P?lda.o ) /usr/bin/ld: cannot find /home/strake/example/./P /usr/bin/ld: cannot find lda_o_split/P /usr/bin/ld: cannot find lda__1.o /usr/bin/ld: cannot find /home/strake/example/./P /usr/bin/ld: cannot find lda_o_split/P /usr/bin/ld: cannot find lda__2.o collect2: error: ld returned 1 exit status ???? $ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 6 05:04:17 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Nov 2015 05:04:17 -0000 Subject: [GHC] #11063: ghc -split-objs fails on Unicode file names In-Reply-To: <048.f9c863f2837410de9414e540724123e7@haskell.org> References: <048.f9c863f2837410de9414e540724123e7@haskell.org> Message-ID: <063.1c23d707684c5aaa4e7b6cd8a0a2a410@haskell.org> #11063: ghc -split-objs fails on Unicode file names -------------------------------------+------------------------------------- Reporter: strake888 | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by strake888): * Attachment "example.tar.gz" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 6 05:06:50 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Nov 2015 05:06:50 -0000 Subject: [GHC] #11063: ghc -split-objs fails on Unicode file names In-Reply-To: <048.f9c863f2837410de9414e540724123e7@haskell.org> References: <048.f9c863f2837410de9414e540724123e7@haskell.org> Message-ID: <063.bc2bb78674e4d940d90f511b442c8a15@haskell.org> #11063: ghc -split-objs fails on Unicode file names -------------------------------------+------------------------------------- Reporter: strake888 | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by strake888): GHC in this mode generates an ld script in compiler/main/DriverPipeline.hs with the paths to all the split obj files, which ld parses wrongly if they have such characters. I think double-quoting the paths written to this script would work but I have yet to test it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 6 05:18:30 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Nov 2015 05:18:30 -0000 Subject: [GHC] #11063: ghc -split-objs fails on Unicode file names In-Reply-To: <048.f9c863f2837410de9414e540724123e7@haskell.org> References: <048.f9c863f2837410de9414e540724123e7@haskell.org> Message-ID: <063.e8a73a241c7a72224d5531ef001f7180@haskell.org> #11063: ghc -split-objs fails on Unicode file names -------------------------------------+------------------------------------- Reporter: strake888 | Owner: strake888 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by strake888): * owner: => strake888 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 6 06:15:51 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Nov 2015 06:15: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.07b244c8a354e3d639a63473946723c1@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 Rev(s): Phab:D1441 Wiki Page: | -------------------------------------+------------------------------------- Changes (by msosn): * differential: => Phab:D1441 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 6 08:14:02 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Nov 2015 08:14:02 -0000 Subject: [GHC] #11058: selected processor does not support ARM mode In-Reply-To: <046.179fa65419f6552c89ce7f996b230033@haskell.org> References: <046.179fa65419f6552c89ce7f996b230033@haskell.org> Message-ID: <061.7ffdead9a63c3aa3d8c35b2c40e727bc@haskell.org> #11058: selected processor does not support ARM mode ----------------------------------------+------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------ Comment (by nomeata): Thanks for the progress so far. Do you already have an idea what might be causing the segfaults? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 6 08:26:18 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Nov 2015 08:26:18 -0000 Subject: [GHC] #11058: selected processor does not support ARM mode In-Reply-To: <046.179fa65419f6552c89ce7f996b230033@haskell.org> References: <046.179fa65419f6552c89ce7f996b230033@haskell.org> Message-ID: <061.8553b36dfe47e08b6303d3574fad88ce@haskell.org> #11058: selected processor does not support ARM mode ----------------------------------------+------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------ Comment (by erikd): Unfortunately I don't, and what's worse is that when I use GDB on the stage2 compiler GDB itself hangs. Once I execute the GDB `run` command, I never get a prompt and the program doesn't terminate either. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 6 10:22:12 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Nov 2015 10:22:12 -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.f57e526b5f6932b6f33b51bd18515cb1@haskell.org> #10870: PPC.Ppr: Shift by 32 bits is not allowed. ---------------------------------------+---------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.3 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 Rev(s): Phab:D1322 Wiki Page: | ---------------------------------------+---------------------------------- Changes (by nomeata): * status: closed => new * resolution: fixed => Comment: Sorry to be the bringer of bad news, but this seems to be still occurring in 7.10.3-rc1: https://buildd.debian.org/status/fetch.php?pkg=haskell-vector- algorithms&arch=powerpc&ver=0.7.0.1-2&stamp=1446804253 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 6 10:43:09 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Nov 2015 10:43:09 -0000 Subject: [GHC] #9591: Add custom "Wiki" field in Trac In-Reply-To: <048.abc646341c4c6a2ec973239fa3b2d045@haskell.org> References: <048.abc646341c4c6a2ec973239fa3b2d045@haskell.org> Message-ID: <063.dccd94b6148bafbe5923ee656a473eba@haskell.org> #9591: Add custom "Wiki" field in Trac -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: hvr Type: feature request | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jstolarek): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 6 11:12:37 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Nov 2015 11:12:37 -0000 Subject: [GHC] #1830: Automatic derivation of Lift In-Reply-To: <044.3eb409743bc4021eb94e63cb46f573bc@haskell.org> References: <044.3eb409743bc4021eb94e63cb46f573bc@haskell.org> Message-ID: <059.10d96088d563724156dc2f67e61f24f3@haskell.org> #1830: Automatic derivation of Lift -------------------------------------+------------------------------------- Reporter: guest | Owner: RyanGlScott Type: feature request | Status: closed Priority: normal | Milestone: ? Component: Template Haskell | Version: 6.8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1168 Wiki Page: | -------------------------------------+------------------------------------- Changes (by jstolarek): * status: new => closed * resolution: => fixed Comment: Phab revision is closed and the patches have been merged - I believe this ticket should also be closed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 6 11:37:47 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Nov 2015 11:37:47 -0000 Subject: [GHC] #4863: TH crashes if you reify the Name of a dfun In-Reply-To: <044.713ffb35d11ce342f1ff0a491439d522@haskell.org> References: <044.713ffb35d11ce342f1ff0a491439d522@haskell.org> Message-ID: <059.761034eee9662b6f9624994d38e622cc@haskell.org> #4863: TH crashes if you reify the Name of a dfun -------------------------------------+------------------------------------- Reporter: guest | Owner: simonpj Type: bug | Status: new Priority: low | Milestone: ? Component: Template Haskell | Version: 7.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jstolarek): * cc: goldfire, jstolarek (added) Comment: Is this problem still present in the current implementation of TH? `classInstances` (now: `reifyInstances`) returns a proper list of instance declarations. I don't see any `Name`s inside `InstanceD` constructor so I'm not sure if there's anything more to reify after calling `reifyInstance`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 6 14:37:27 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Nov 2015 14:37:27 -0000 Subject: [GHC] #11064: Call Arity has the trivial application case wrong Message-ID: <046.eb4c820640d5d418fe2e5ee76141b9f5@haskell.org> #11064: Call Arity has the trivial application case wrong -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata 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 Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In `e x`, the result of `x` is not shared in contrast to `e (f x)`, where CorePrep will turn it into `let y = f x in e x`. So in {{{ let f = ... in e (f x) }}} we know that f is called at most once, but in {{{ let f = ... in e f }}} we do not know that. Previously Call Arity would assume that in `e x`, `x` is evaluated at most once. This rarely would make a difference (the argument `x` is analized with an incoming arity of 0, so no eta-expansion would be done anyways), but of course this should still be fixed. I just validated a patch and will push shortly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 6 14:38:35 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Nov 2015 14:38:35 -0000 Subject: [GHC] #11064: Call Arity has the trivial application case wrong In-Reply-To: <046.eb4c820640d5d418fe2e5ee76141b9f5@haskell.org> References: <046.eb4c820640d5d418fe2e5ee76141b9f5@haskell.org> Message-ID: <061.cb9b05d8acde90c91b060762ede3e465@haskell.org> #11064: Call Arity has the trivial application case wrong -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"a58eeb7febd67c93dab82de7049ef1dcdecd34e9/ghc" a58eeb7/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a58eeb7febd67c93dab82de7049ef1dcdecd34e9" Call Arity: In "e x", the result of "x" is not shared in contrast to "e (f x)", where CorePrep will turn it into "let y = f x in e x". So in let f = ... in e (f x) we know that f is called at most once, but in let f = ... in e f we do not know that. Previously Call Arity would assume that in "e x", "x" is evaluated at most once. This rarely would make a difference (the argument "x" is analized with an incoming arity of 0, so no eta-expansion would be done anyways), but of course this should still be fixed. This fixes #11064. Note the corresponding code dmdTransformThunkDmd in DmdAnal. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 6 14:39:28 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Nov 2015 14:39:28 -0000 Subject: [GHC] #11064: Call Arity has the trivial application case wrong In-Reply-To: <046.eb4c820640d5d418fe2e5ee76141b9f5@haskell.org> References: <046.eb4c820640d5d418fe2e5ee76141b9f5@haskell.org> Message-ID: <061.f6868c3ce49e29a1667035431606abb3@haskell.org> #11064: Call Arity has the trivial application case wrong -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: merge 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => merge Comment: Pushed to master. I?d like to see this in 7.10.3, if possible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 6 14:46:53 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Nov 2015 14:46:53 -0000 Subject: [GHC] #11064: Call Arity has the trivial application case wrong In-Reply-To: <046.eb4c820640d5d418fe2e5ee76141b9f5@haskell.org> References: <046.eb4c820640d5d418fe2e5ee76141b9f5@haskell.org> Message-ID: <061.5e1e542798f412f15f644154deccc343@haskell.org> #11064: Call Arity has the trivial application case wrong -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata 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: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * milestone: => 7.10.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 6 14:48:33 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Nov 2015 14:48:33 -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.41a44198267c722f26b22f8b3d74789d@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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): > With paraffin something goes wrong Maybe this was due to #11064, I?ll revisit this ticket soonish. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 6 15:13:21 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Nov 2015 15:13:21 -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.1bd91bcf5134ec63171528d4245f6d9f@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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * cc: osa1 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 6 15:53:57 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Nov 2015 15:53:57 -0000 Subject: [GHC] #11007: Type family injectivity annotations ignored in hs-boot files In-Reply-To: <047.26e4b74bfa5db1c5fbbc0697a9084694@haskell.org> References: <047.26e4b74bfa5db1c5fbbc0697a9084694@haskell.org> Message-ID: <062.affbb34ae422bd9c0a04546cc14b898a@haskell.org> #11007: Type family injectivity annotations ignored in hs-boot files -------------------------------------+------------------------------------- Reporter: goldfire | Owner: jstolarek Type: bug | Status: new Priority: normal | Milestone: 8.0.1 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jstolarek): * owner: => jstolarek Comment: Duh. I tested this for open type families but not for closed ones. Will fix sometime soon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 6 16:33:17 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Nov 2015 16:33:17 -0000 Subject: [GHC] #11063: ghc -split-objs fails on Unicode file names In-Reply-To: <048.f9c863f2837410de9414e540724123e7@haskell.org> References: <048.f9c863f2837410de9414e540724123e7@haskell.org> Message-ID: <063.fe0823e1e4d63c931ba20912e5447dbe@haskell.org> #11063: ghc -split-objs fails on Unicode file names -------------------------------------+------------------------------------- Reporter: strake888 | Owner: strake888 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 Rev(s): Phab:D1442 Wiki Page: | -------------------------------------+------------------------------------- Changes (by strake888): * status: new => patch * differential: => Phab:D1442 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 6 17:28:19 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Nov 2015 17:28:19 -0000 Subject: [GHC] #11065: Outdated documentation for foldl and friends Message-ID: <047.712921fa5a5588273b6341e2632eef73@haskell.org> #11065: Outdated documentation for foldl and friends -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Documentation | 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): | Wiki Page: -------------------------------------+------------------------------------- Straight from `Data.Foldable`, here is the documentation for `foldl`: {{{ -- | Left-associative fold of a structure. -- -- @'foldl' f z = 'Prelude.foldl' f z . 'toList'@ }}} But, of course, `Prelude.foldl` is the same `foldl`! There are other functions with similar problems. When revising these, please put in (back?) examples of how these work, at least on lists. I've been doing functional programming for some time, and I still like to look at examples to make sure that I'm getting my `foldl` and `foldr` straight. Maybe it's because my brain is small, but we don't want to exclude people with small brains! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 6 20:55:38 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Nov 2015 20:55:38 -0000 Subject: [GHC] #10853: Refine addTopDecls In-Reply-To: <047.c86dd8a253022fe77935e07f26b94dc1@haskell.org> References: <047.c86dd8a253022fe77935e07f26b94dc1@haskell.org> Message-ID: <062.c16eed48b0d5ce23966f7f6ba8afc9e3@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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): It turns out that my proposal to change the treatment of regions is a bad idea. This is because `addTopDecls` is useful for generating new definitions that get used right away. If region D isn't available when type-checking region A, this isn't possible. Note that the fact that region D isn't available when ''renaming'' A is OK, as Template Haskell can use "exact" names. But this still could be cleaned up. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 6 20:57:36 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Nov 2015 20:57:36 -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.aa5b861040ab6a02f83060eec70d6257@haskell.org> #10828: TH could do a better job of representing GADTs -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature request | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I think, in light of comment:5, we should add proper GADT support in TH. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 6 21:01:32 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Nov 2015 21:01:32 -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.e1c002a8e8f025fd77adadb26452df1f@haskell.org> #10823: Don't mark functions with annotations as dead -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature request | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Where are we with this ticket? It looks like we have a sensible approach to the original poster's needs. And we've formulated (loosely) a way of keeping code alive. But does that new pragma have real clients who want it? Of course, we ''could'' do this, but ''should'' we? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 6 22:08:19 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Nov 2015 22:08:19 -0000 Subject: [GHC] #11066: Inacessible branch should be warning - otherwise breaks type soundness? Message-ID: <047.0785946e31f05741dc32414264d84d16@haskell.org> #11066: Inacessible branch should be warning - otherwise breaks type soundness? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.2 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): | Wiki Page: -------------------------------------+------------------------------------- GHC 7.10.2 reports inaccessible branches as a type error, and I think this is really a bug. First, the implicit thinking seems to be "why would a user want to write inaccessible cases, they'd be crazy!". But that only applies to human-written code. Program generators can have a great deal of trouble avoiding this error, unless they replicate the GHC type checker to predict the problem and prune branches. (That's why we are hitting this error and are stuck.) Second, it seems like this is a problem for type soundness. See the attached program where "step1" typechecks but "step2" does not. And yet, the operational semantics should allow step1 to reduce to step2. Indeed, in the "GADTs meet their match" paper it seems like the intent was to warn for these inaccessible cases, not error. For example, the paper contains the language: "If we warn that a right-hand side of a non-redundant clause is inaccessible," -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 6 22:08:50 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Nov 2015 22:08:50 -0000 Subject: [GHC] #11066: Inacessible branch should be warning - otherwise breaks type soundness? In-Reply-To: <047.0785946e31f05741dc32414264d84d16@haskell.org> References: <047.0785946e31f05741dc32414264d84d16@haskell.org> Message-ID: <062.62af9b129573e7bd8bbe7e4eddc9b083@haskell.org> #11066: Inacessible branch should be warning - otherwise breaks type soundness? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.2 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rrnewton): * Attachment "SimpleInaccessible.hs" added. Example program that will error with "inaccessible code" -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 6 22:09:23 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Nov 2015 22:09:23 -0000 Subject: [GHC] #11066: Inacessible branch should be warning - otherwise breaks type soundness? In-Reply-To: <047.0785946e31f05741dc32414264d84d16@haskell.org> References: <047.0785946e31f05741dc32414264d84d16@haskell.org> Message-ID: <062.24ea194032890a76611fd29214480c8c@haskell.org> #11066: Inacessible branch should be warning - otherwise breaks type soundness? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.2 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): Wiki Page: | -------------------------------------+------------------------------------- Description changed by rrnewton: Old description: > GHC 7.10.2 reports inaccessible branches as a type error, and I think > this is really a bug. > > First, the implicit thinking seems to be "why would a user want to > write inaccessible cases, they'd be crazy!". But that only applies to > human-written code. Program generators can have a great deal of > trouble avoiding this error, unless they replicate the GHC type > checker to predict the problem and prune branches. (That's why we are > hitting this error and are stuck.) > > Second, it seems like this is a problem for type soundness. See the > attached program where "step1" typechecks but "step2" does not. And yet, > the operational semantics should allow step1 to reduce to step2. > > Indeed, in the "GADTs meet their match" paper it seems like the intent > was to warn for these inaccessible cases, not error. For example, the > paper contains the language: > > "If we warn that a right-hand side of a non-redundant clause is > inaccessible," New description: GHC 7.10.2 reports inaccessible branches as a type error, and I think this is really a bug. First, the implicit thinking seems to be "why would a user want to write inaccessible cases, they'd be crazy!". But that only applies to human-written code. Program generators can have a great deal of trouble avoiding this error, unless they replicate the GHC type checker to predict the problem and prune branches. (That's why we are hitting this error and are stuck.) Second, it seems like this is a problem for type soundness. See the attached program where "step1" typechecks but "step2" does not. And yet, the operational semantics should allow step1 to reduce to step2. Indeed, in the "GADTs meet their match" paper it seems like the intent was to warn for these inaccessible cases, not error. For example, the paper contains the language: "If we warn that a right-hand side of a non-redundant clause is inaccessible,..." -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 6 22:21:41 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Nov 2015 22:21:41 -0000 Subject: [GHC] #11057: toIfaceIdDetails trace statement catches PatSynBuilder In-Reply-To: <046.6feaafdc65794c033bfadc6a62db1081@haskell.org> References: <046.6feaafdc65794c033bfadc6a62db1081@haskell.org> Message-ID: <061.9ba8ba80fa3d64264b29da21b85b3276@haskell.org> #11057: toIfaceIdDetails trace statement catches PatSynBuilder -------------------------------------+------------------------------------- Reporter: bgamari | Owner: mpickering Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 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 Rev(s): Phab:D1443 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => patch * differential: => Phab:D1443 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 7 00:59:49 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Nov 2015 00:59:49 -0000 Subject: [GHC] #10853: Refine addTopDecls In-Reply-To: <047.c86dd8a253022fe77935e07f26b94dc1@haskell.org> References: <047.c86dd8a253022fe77935e07f26b94dc1@haskell.org> Message-ID: <062.6a67e3377e60c3000bbbc3d09f16ca96@haskell.org> #10853: Refine addTopDecls -------------------------------------+------------------------------------- Reporter: goldfire | Owner: siddhanathan 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by siddhanathan): * owner: => siddhanathan -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 7 02:23:06 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Nov 2015 02:23:06 -0000 Subject: [GHC] #10279: panic on haskell-src-exts In-Reply-To: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> References: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> Message-ID: <066.ce921332717b6bc3f16b0e43d705c4fb@haskell.org> #10279: panic on haskell-src-exts -------------------------------------+------------------------------------- Reporter: throwaway123 | Owner: ezyang Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1342 Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Update: There's nothing to do about this issue. See my comment in Phabricator: https://phabricator.haskell.org/D1342#41793 We just need to clean the package and document things. This could probably be closed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 7 09:39:03 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Nov 2015 09:39:03 -0000 Subject: [GHC] #4837: Template Haskell does not work in a profiled compiler. In-Reply-To: <043.b5650b88723ece09a2484d5316810782@haskell.org> References: <043.b5650b88723ece09a2484d5316810782@haskell.org> Message-ID: <058.19aed4b100f553a8efd23694816f18d6@haskell.org> #4837: Template Haskell does not work in a profiled compiler. -------------------------------------+------------------------------------- Reporter: benl | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Profiling | Version: 7.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC doesn't work | Unknown/Multiple at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Marlow ): In [changeset:"ce1f1607ed7f8fedd2f63c8610cafefd59baaf32/ghc" ce1f1607/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ce1f1607ed7f8fedd2f63c8610cafefd59baaf32" Make GHCi & TH work when the compiler is built with -prof Summary: Amazingly, there were zero changes to the byte code generator and very few changes to the interpreter - mainly because we've used good abstractions that hide the differences between profiling and non-profiling. So that bit was pleasantly straightforward, but there were a pile of other wibbles to get the whole test suite through. Note that a compiler built with -prof is now like one built with -dynamic, in that to use TH you have to build the code the same way. For dynamic, we automatically enable -dynamic-too when TH is required, but we don't have anything equivalent for profiling, so you have to explicitly use -prof when building code that uses TH with a profiled compiler. For this reason Cabal won't work with TH. We don't expect to ship a profiled compiler, so I think that's OK. Test Plan: validate with GhcProfiled=YES in validate.mk Reviewers: goldfire, bgamari, rwbarton, austin, hvr, erikd, ezyang Reviewed By: ezyang Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1407 GHC Trac Issues: #4837, #545 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 7 09:39:03 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Nov 2015 09:39:03 -0000 Subject: [GHC] #545: GHCi + profiling doesn't work In-Reply-To: <049.b673ccee7e6889a7345a01acda87eed3@haskell.org> References: <049.b673ccee7e6889a7345a01acda87eed3@haskell.org> Message-ID: <064.f39ed2043ed9cddaf0b5d5225b099b52@haskell.org> #545: GHCi + profiling doesn't work -------------------------------------+------------------------------------- Reporter: nilsanders | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 5.0 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Marlow ): In [changeset:"ce1f1607ed7f8fedd2f63c8610cafefd59baaf32/ghc" ce1f1607/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ce1f1607ed7f8fedd2f63c8610cafefd59baaf32" Make GHCi & TH work when the compiler is built with -prof Summary: Amazingly, there were zero changes to the byte code generator and very few changes to the interpreter - mainly because we've used good abstractions that hide the differences between profiling and non-profiling. So that bit was pleasantly straightforward, but there were a pile of other wibbles to get the whole test suite through. Note that a compiler built with -prof is now like one built with -dynamic, in that to use TH you have to build the code the same way. For dynamic, we automatically enable -dynamic-too when TH is required, but we don't have anything equivalent for profiling, so you have to explicitly use -prof when building code that uses TH with a profiled compiler. For this reason Cabal won't work with TH. We don't expect to ship a profiled compiler, so I think that's OK. Test Plan: validate with GhcProfiled=YES in validate.mk Reviewers: goldfire, bgamari, rwbarton, austin, hvr, erikd, ezyang Reviewed By: ezyang Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1407 GHC Trac Issues: #4837, #545 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 7 09:41:01 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Nov 2015 09:41:01 -0000 Subject: [GHC] #545: GHCi + profiling doesn't work In-Reply-To: <049.b673ccee7e6889a7345a01acda87eed3@haskell.org> References: <049.b673ccee7e6889a7345a01acda87eed3@haskell.org> Message-ID: <064.a69b241e461a19f0ff46748d6c366ab6@haskell.org> #545: GHCi + profiling doesn't work -------------------------------------+------------------------------------- Reporter: nilsanders | Owner: simonmar Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 5.0 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 7 09:42:57 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Nov 2015 09:42:57 -0000 Subject: [GHC] #4837: Template Haskell does not work in a profiled compiler. In-Reply-To: <043.b5650b88723ece09a2484d5316810782@haskell.org> References: <043.b5650b88723ece09a2484d5316810782@haskell.org> Message-ID: <058.bf26eb5f1aa7a2b9a9834aeda2b1b473@haskell.org> #4837: Template Haskell does not work in a profiled compiler. -------------------------------------+------------------------------------- Reporter: benl | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Profiling | Version: 7.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC doesn't work | Unknown/Multiple at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 7 12:16:19 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Nov 2015 12:16:19 -0000 Subject: [GHC] #10942: CPP pragma ignored if top comments and Opt_KeepRawTokenStream In-Reply-To: <044.3dc1d52508bafa33dfb53526bcdd251c@haskell.org> References: <044.3dc1d52508bafa33dfb53526bcdd251c@haskell.org> Message-ID: <059.c621fca2714601b7933fc0a3e416413d@haskell.org> #10942: CPP pragma ignored if top comments and Opt_KeepRawTokenStream -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 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 Rev(s): Phab:D1444 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => patch * differential: => Phab:D1444 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 7 12:16:31 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Nov 2015 12:16:31 -0000 Subject: [GHC] #10942: CPP pragma ignored if top comments and Opt_KeepRawTokenStream In-Reply-To: <044.3dc1d52508bafa33dfb53526bcdd251c@haskell.org> References: <044.3dc1d52508bafa33dfb53526bcdd251c@haskell.org> Message-ID: <059.32097598d76066937179349bc355c9bf@haskell.org> #10942: CPP pragma ignored if top comments and Opt_KeepRawTokenStream -------------------------------------+------------------------------------- Reporter: alanz | Owner: mpickering Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 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 Rev(s): Phab:D1444 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * owner: alanz => mpickering -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 7 12:59:59 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Nov 2015 12:59:59 -0000 Subject: [GHC] #10955: GHC on windows does not resolve DLL dependencies In-Reply-To: <044.d1371f1a3dafc9d7220a00358a56f239@haskell.org> References: <044.d1371f1a3dafc9d7220a00358a56f239@haskell.org> Message-ID: <059.62b58d058385c75a15aa9ff48dc50775@haskell.org> #10955: GHC on windows does not resolve DLL dependencies -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Runtime System | Version: 7.10.2 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1340 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Tamar Christina ): In [changeset:"6e6438e15f33cb94ad6338e950e693f59d046385/ghc" 6e6438e1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6e6438e15f33cb94ad6338e950e693f59d046385" Allow the GHCi Linker to resolve related dependencies when loading DLLs Summary: GHCi does not correctly tell the Windows Loader how to handle dependencies to DLL's that are not on the standard Windows load path: 1. The directory from which the application loaded. 2. The current directory. 3. The system directory. Use the GetSystemDirectory function to get the path of this directory. 4. The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched. 5. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory. 6. The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the AppPaths registry key. The App Paths key is not used when computing the DLL search path. So what this means is given two DLLs `A` and `B` and `B` depending on `A`. If we put both DLLs into a new folder bin and then call GHC with: `ghc -L$(PWD)/bin -lB` the loading will fail as the Windows loader will try to load the dependency of `B` and fail since it cannot find `A`. *IMPORTANT* this patch drops XP Support. The APIs being used were natively added to Windows 8+ and backported to Windows 7 and Vista via a mandatory security patch (in 2011). This means that there is a chance that KB2533623 has not been installed on certain machines. For those machines I display a warning and temporarily expand the `PATH` to allow it to load. This patch will make sure that paths provided by the user with `-L` *and* the folder in which a DLL is found are added to the search path. It does so using one of two methods depending upon how new of a Windows version we are running on: - If the APIs are available it will use `addDllDirectory` and `removeDllDirectory`. The order of which these directories are searched is nondeterministic. - If the APIs are not available it means that we're running on a pretty old unpatched machine. But if it's being used in an environment with no internet access it may be the case. So if the APIs are not available we temporarily extend the `PATH` with the directories. A warning is also displayed to the user informing them that the linking may fail, and if it does, install the needed patch. The `PATH` variable has limitations. Test Plan: ./validate Added two new test T10955 and T10955dyn Reviewers: erikd, bgamari, thomie, hvr, austin Reviewed By: erikd, thomie Subscribers: #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D1340 GHC Trac Issues: #10955 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 7 13:01:42 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Nov 2015 13:01:42 -0000 Subject: [GHC] #10955: GHC on windows does not resolve DLL dependencies In-Reply-To: <044.d1371f1a3dafc9d7220a00358a56f239@haskell.org> References: <044.d1371f1a3dafc9d7220a00358a56f239@haskell.org> Message-ID: <059.5f650a881e90a68a593d0acf018679db@haskell.org> #10955: GHC on windows does not resolve DLL dependencies -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Runtime System | Version: 7.10.2 (Linker) | Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1340 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 7 13:06:29 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Nov 2015 13:06:29 -0000 Subject: [GHC] #3242: GHCi linker does not correctly locate static libraries under Windows (was: 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.07f4f3e37417168933c8feaf9ed67d1f@haskell.org> #3242: GHCi linker does not correctly locate static libraries under Windows ---------------------------------+----------------------------- Reporter: jeffz1 | Owner: Phyx- 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 Rev(s): Wiki Page: | ---------------------------------+----------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 7 14:28:32 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Nov 2015 14:28:32 -0000 Subject: [GHC] #10633: GHCi segfaults on arm In-Reply-To: <045.ce30a9b63cbcf433a0315ff9f9caf317@haskell.org> References: <045.ce30a9b63cbcf433a0315ff9f9caf317@haskell.org> Message-ID: <060.554439e4ba0022b702730382c977f75f@haskell.org> #10633: GHCi segfaults on arm -------------------------------+------------------------------ Reporter: Thra11 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.10.1 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+------------------------------ Comment (by Thra11): Confirmed fixed in 7.10.3-rc1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 7 16:58:36 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Nov 2015 16:58:36 -0000 Subject: [GHC] #11067: Spurious superclass cycle error with type equalities Message-ID: <045.f5d44ba3aad0bf1ca48ae450e6c33b15@haskell.org> #11067: Spurious superclass cycle error with type equalities -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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): | Wiki Page: -------------------------------------+------------------------------------- Some of us today had an idea how to repair Edward Kmett's regrettably unsound `Data.Constraint.Forall` module. The method works fine in some cases, but seems to occasionally trigger a spurious superclass cycle error. In the cases I've seen so far, it seems to happen when a class is defined with a `Forall` superclass, where that `Forall` itself has as parameter another class, that itself has a type equality superclass. Example file (a bit larger than necessary to show how a similar example without a type equality ''doesn't'' give an error): {{{#!haskell {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE TypeFamilies #-} import Data.Monoid import GHC.Exts (Constraint) type family Skolem (p :: k -> Constraint) :: k type family SkolemF (p :: k2 -> Constraint) (f :: k1 -> k2) :: k1 -- | A quantified constraint type Forall (p :: k -> Constraint) = p (Skolem p) type ForallF (p :: k2 -> Constraint) (f :: k1 -> k2) = p (f (SkolemF p f)) -- These work class ForallF Monoid t => Monoid1 t instance ForallF Monoid t => Monoid1 t class ForallF Monoid1 t => Monoid2 t instance ForallF Monoid1 t => Monoid2 t -- Changing f a ~ g a to, (Ord (f a), Ord (g a)), say, removes the error class (f a ~ g a) => H f g a instance (f a ~ g a) => H f g a -- This one gives a superclass cycle error. class Forall (H f g) => H1 f g instance Forall (H f g) => H1 f g }}} And the resulting error: {{{ Test.hs:31:1: Cycle in class declaration (via superclasses): H1 -> Forall -> H -> H In the class declaration for ?H1? Test.hs:31:1: Cycle in class declaration (via superclasses): H1 -> Forall -> H -> H In the class declaration for ?H1? }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 7 17:00:03 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Nov 2015 17:00:03 -0000 Subject: [GHC] #11067: Spurious superclass cycle error with type equalities In-Reply-To: <045.f5d44ba3aad0bf1ca48ae450e6c33b15@haskell.org> References: <045.f5d44ba3aad0bf1ca48ae450e6c33b15@haskell.org> Message-ID: <060.929425963f626e2a52b102bdb2f83311@haskell.org> #11067: Spurious superclass cycle error with type equalities -------------------------------------+------------------------------------- Reporter: oerjan | 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 rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by oerjan): * cc: oerjan (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 7 18:16:57 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Nov 2015 18:16:57 -0000 Subject: [GHC] #11067: Spurious superclass cycle error with type equalities In-Reply-To: <045.f5d44ba3aad0bf1ca48ae450e6c33b15@haskell.org> References: <045.f5d44ba3aad0bf1ca48ae450e6c33b15@haskell.org> Message-ID: <060.4aa6c678264d575f0fe1478db8dba2ea@haskell.org> #11067: Spurious superclass cycle error with type equalities -------------------------------------+------------------------------------- Reporter: oerjan | 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 rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by oerjan): Andr?s Kov?cs [https://github.com/ekmett/constraints/issues/11#issuecomment-154726144 found a workaround] for our use case: The error disappears if `Forall` etc. are made type synonym families rather than plain synonyms. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 7 19:06:55 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Nov 2015 19:06:55 -0000 Subject: [GHC] #11068: Make Generic/Generic1 methods inlinable Message-ID: <044.2644399b8f2d6a8d61669300e8f810a3@haskell.org> #11068: Make Generic/Generic1 methods inlinable -------------------------------------+------------------------------------- Reporter: glguy | 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 Rev(s): D1447 | Wiki Page: -------------------------------------+------------------------------------- Efficient code generation with GHC.Generics relies on the optimizer being able to completely remove the generic representation of a type. Marking these methods as inlinable ensures that this will be possible even for larger types. I'm working on techniques for transforming generically derived lenses and traversals which rely on taking advantage of the Functor and Applicative laws. This patch supports that work. https://github.com/glguy/generic-traverse -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 7 19:08:26 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Nov 2015 19:08:26 -0000 Subject: [GHC] #11068: Make Generic/Generic1 methods inlinable In-Reply-To: <044.2644399b8f2d6a8d61669300e8f810a3@haskell.org> References: <044.2644399b8f2d6a8d61669300e8f810a3@haskell.org> Message-ID: <059.8661c7c38b1164b7954309c4d86a0a92@haskell.org> #11068: Make Generic/Generic1 methods inlinable -------------------------------------+------------------------------------- Reporter: glguy | 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 Rev(s): Phab:D1447 Wiki Page: | -------------------------------------+------------------------------------- Changes (by glguy): * differential: D1447 => Phab:D1447 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 7 20:17:08 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Nov 2015 20:17:08 -0000 Subject: [GHC] #11067: Spurious superclass cycle error with type equalities In-Reply-To: <045.f5d44ba3aad0bf1ca48ae450e6c33b15@haskell.org> References: <045.f5d44ba3aad0bf1ca48ae450e6c33b15@haskell.org> Message-ID: <060.224e19b726a8f95ee736f84d5c707970@haskell.org> #11067: Spurious superclass cycle error with type equalities -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * component: Compiler => Compiler (Type checker) * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 7 20:30:44 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Nov 2015 20:30:44 -0000 Subject: [GHC] #11068: Make Generic/Generic1 methods inlinable In-Reply-To: <044.2644399b8f2d6a8d61669300e8f810a3@haskell.org> References: <044.2644399b8f2d6a8d61669300e8f810a3@haskell.org> Message-ID: <059.a271661596f96849c5ccebe32e61a60e@haskell.org> #11068: Make Generic/Generic1 methods inlinable -------------------------------------+------------------------------------- Reporter: glguy | 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 Rev(s): Phab:D1447 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dreixel): `INLINABLE` on these methods definitely sounds like a good idea to me. Are there any concerns regarding interface file size increase? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 7 20:34:08 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Nov 2015 20:34:08 -0000 Subject: [GHC] #11068: Make Generic/Generic1 methods inlinable In-Reply-To: <044.2644399b8f2d6a8d61669300e8f810a3@haskell.org> References: <044.2644399b8f2d6a8d61669300e8f810a3@haskell.org> Message-ID: <059.55d8e715331622e008993f071017ad2d@haskell.org> #11068: Make Generic/Generic1 methods inlinable -------------------------------------+------------------------------------- Reporter: glguy | 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 Rev(s): Phab:D1447 Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I remember chatting with some people at ICFP about optimizing Generics code. The problem was that sometimes GHC is able to optimize Generics-based code so that it doesn't use Generics methods anymore. For example, using Generics- based default method of `NFData` sometimes works well, generated code is same as hand-written code. But in some cases it never optimizes enough to eliminate Generics methods. For example, in my tests I was never able to eliminate Generics methods in Generics-based default implementation of `Binary`. I'm wondering if after this patch GHC is able to optimize such instances. @glguy have you tried anything like this? Looks like a good improvement to me, +1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 7 21:46:40 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Nov 2015 21:46:40 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMDczNDogcHByaW50IG9mIOKAmGxldOKAmSBp?= =?utf-8?q?nside_=E2=80=98do=E2=80=99_prints_invalid_Haskell?= In-Reply-To: <047.198f0614ed38423766e17028c03c3aa7@haskell.org> References: <047.198f0614ed38423766e17028c03c3aa7@haskell.org> Message-ID: <062.847486580d1ca0b525de48d5b5d8c06f@haskell.org> #10734: pprint of ?let? inside ?do? prints invalid Haskell -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: johnleo Type: bug | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by johnleo): * owner: => johnleo -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 7 21:48:51 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Nov 2015 21:48:51 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMDczNDogcHByaW50IG9mIOKAmGxldOKAmSBp?= =?utf-8?q?nside_=E2=80=98do=E2=80=99_prints_invalid_Haskell?= In-Reply-To: <047.198f0614ed38423766e17028c03c3aa7@haskell.org> References: <047.198f0614ed38423766e17028c03c3aa7@haskell.org> Message-ID: <062.aca359d26319cab205436bc14b606d6c@haskell.org> #10734: pprint of ?let? inside ?do? prints invalid Haskell -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: johnleo Type: bug | 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/T10734.hs Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by johnleo): * testcase: => th/T10734.hs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 7 22:32:48 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Nov 2015 22:32:48 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMDczNDogcHByaW50IG9mIOKAmGxldOKAmSBp?= =?utf-8?q?nside_=E2=80=98do=E2=80=99_prints_invalid_Haskell?= In-Reply-To: <047.198f0614ed38423766e17028c03c3aa7@haskell.org> References: <047.198f0614ed38423766e17028c03c3aa7@haskell.org> Message-ID: <062.63e0ce2d6e36c382c87576f968172f9a@haskell.org> #10734: pprint of ?let? inside ?do? prints invalid Haskell -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: johnleo Type: bug | 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/T10734.hs Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"be8858570274821546ccabf75fe01c3dad80e337/ghc" be885857/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="be8858570274821546ccabf75fe01c3dad80e337" fix #10734 by adding braces to pretty-printing of let inside do Test Plan: validate Reviewers: bgamari, austin, goldfire Reviewed By: goldfire Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1448 GHC Trac Issues: #10734 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 7 22:35:36 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Nov 2015 22:35:36 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMDczNDogcHByaW50IG9mIOKAmGxldOKAmSBp?= =?utf-8?q?nside_=E2=80=98do=E2=80=99_prints_invalid_Haskell?= In-Reply-To: <047.198f0614ed38423766e17028c03c3aa7@haskell.org> References: <047.198f0614ed38423766e17028c03c3aa7@haskell.org> Message-ID: <062.749fb8cac31c55105a87918cccea4eac@haskell.org> #10734: pprint of ?let? inside ?do? prints invalid Haskell -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: johnleo Type: bug | Status: closed Priority: normal | Milestone: 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/T10734.hs Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 7 23:10:24 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Nov 2015 23:10:24 -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.359e70036c22953c1bc9d9c1a3e5bcaf@haskell.org> #10902: Refactor type families in Template Haskell -------------------------------------+------------------------------------- Reporter: goldfire | Owner: johnleo 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by johnleo): * owner: => johnleo -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 7 23:50:20 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Nov 2015 23:50:20 -0000 Subject: [GHC] #11057: toIfaceIdDetails trace statement catches PatSynBuilder In-Reply-To: <046.6feaafdc65794c033bfadc6a62db1081@haskell.org> References: <046.6feaafdc65794c033bfadc6a62db1081@haskell.org> Message-ID: <061.52514adc3e619837b218544ecba8a1ef@haskell.org> #11057: toIfaceIdDetails trace statement catches PatSynBuilder -------------------------------------+------------------------------------- Reporter: bgamari | Owner: mpickering Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 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 Rev(s): Phab:D1443 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Matthew Pickering ): In [changeset:"22080113f02f6644e2a0e3ce8adb1502346ab3b4/ghc" 2208011/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="22080113f02f6644e2a0e3ce8adb1502346ab3b4" Remove PatSynBuilderId Summary: It was only used to pass field labels between the typechecker and desugarer. Instead we add an extra field the RecordCon to carry this information. Reviewers: austin, goldfire, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1443 GHC Trac Issues: #11057 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 7 23:53:25 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Nov 2015 23:53:25 -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.a56b36f485265204317fe98a18cadfb3@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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): My first step toward fixing this is prohibiting export of `newName` names. But it strikes me that a good approach is to avoid adding system names to the `GlobalRdrEnv`. `newName` names are indeed system names, and I think, in general, users should never be able to refer to system names in code. Is there a reason this is a bad approach? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 7 23:54:15 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Nov 2015 23:54:15 -0000 Subject: [GHC] #11044: Parse error on empty multi-line deprecation warnings In-Reply-To: <044.eca441d1c47bb055a7995ead40767af4@haskell.org> References: <044.eca441d1c47bb055a7995ead40767af4@haskell.org> Message-ID: <059.c75bca14d2300d0d4a1da73313dc22d0@haskell.org> #11044: Parse error on empty multi-line deprecation warnings -------------------------------------+------------------------------------- Reporter: inaki | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | parser/should_compile/T3303 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1433 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"8262c954ac3084f0dfcb6d5fa6e6172afd22eae7/ghc" 8262c95/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8262c954ac3084f0dfcb6d5fa6e6172afd22eae7" Parser: allow empty multi-line deprecation warnings This should work, {-# DEPRECATED someFunction [] #-} Test Plan: parser/should_compile/T3303 Reviewers: bgamari, austin Reviewed By: austin Subscribers: mpickering Differential Revision: https://phabricator.haskell.org/D1433 GHC Trac Issues: #11044 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 7 23:54:15 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Nov 2015 23:54:15 -0000 Subject: [GHC] #11063: ghc -split-objs fails on Unicode file names In-Reply-To: <048.f9c863f2837410de9414e540724123e7@haskell.org> References: <048.f9c863f2837410de9414e540724123e7@haskell.org> Message-ID: <063.dd8d0a6c1732002f37534ba2ea816dd7@haskell.org> #11063: ghc -split-objs fails on Unicode file names -------------------------------------+------------------------------------- Reporter: strake888 | Owner: strake888 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 Rev(s): Phab:D1442 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"0e40c01db99680902fda4b7a84d7f15a92502730/ghc" 0e40c01/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0e40c01db99680902fda4b7a84d7f15a92502730" Quote file paths in linker scripts Reviewers: bgamari, austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1442 GHC Trac Issues: #11063 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 7 23:54:23 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Nov 2015 23:54:23 -0000 Subject: [GHC] #11057: toIfaceIdDetails trace statement catches PatSynBuilder In-Reply-To: <046.6feaafdc65794c033bfadc6a62db1081@haskell.org> References: <046.6feaafdc65794c033bfadc6a62db1081@haskell.org> Message-ID: <061.2e00dcf4da433fdb215e21228c862e09@haskell.org> #11057: toIfaceIdDetails trace statement catches PatSynBuilder -------------------------------------+------------------------------------- Reporter: bgamari | Owner: mpickering Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1443 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 7 23:59:04 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Nov 2015 23:59:04 -0000 Subject: [GHC] #11046: lookupTypeName does not support type operators not starting with : In-Reply-To: <045.eabc8eeec9cc920f3e0838e9774eff4d@haskell.org> References: <045.eabc8eeec9cc920f3e0838e9774eff4d@haskell.org> Message-ID: <060.9d5d4ea613fa799c53a17648ef0fd48b@haskell.org> #11046: lookupTypeName does not support type operators not starting with : -------------------------------------+------------------------------------- Reporter: oerjan | Owner: albertus Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | testsuite/tests/th/TH_lookupName.hs, | testsuite/tests/th/T11046.hs Blocked By: | Blocking: Related Tickets: #10583 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by albertus): * owner: => albertus * testcase: testsuite/tests/th/TH_lookupName.hs => testsuite/tests/th/TH_lookupName.hs, testsuite/tests/th/T11046.hs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 8 02:03:49 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Nov 2015 02:03:49 -0000 Subject: [GHC] #11067: Spurious superclass cycle error with type equalities In-Reply-To: <045.f5d44ba3aad0bf1ca48ae450e6c33b15@haskell.org> References: <045.f5d44ba3aad0bf1ca48ae450e6c33b15@haskell.org> Message-ID: <060.820a0c4e30f3f37c1bc2dcf452440718@haskell.org> #11067: Spurious superclass cycle error with type equalities -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by oerjan): To prevent the `Skolem` from leaking via pattern matching, I had to change `Forall` to use a type class instead. I first tried {{{#!hs class p (Skolem p) => Forall (p :: k -> Constraint) instance p (Skolem p) => Forall (p :: k -> Constraint) }}} etc., but this made the cycle errors come back, even more widespread than before (`Monoid2` no longer worked). However, adding a closed type family in the right spot again worked to soothe GHC: {{{#!hs type family Forall (p :: k -> Constraint) where Forall p = Forall_ p class p (Skolem p) => Forall_ (p :: k -> Constraint) instance p (Skolem p) => Forall_ (p :: k -> Constraint) }}} This seems a bit silly :P (Also, the last instance above should have a `Forall_`, but the `_` is invisible, at least in preview...) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 8 06:17:58 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Nov 2015 06:17:58 -0000 Subject: [GHC] #10827: GHCi should support interpeting multiple packages/units with separate DynFlags In-Reply-To: <045.56917c0b2dd940e5429ceefba9639e36@haskell.org> References: <045.56917c0b2dd940e5429ceefba9639e36@haskell.org> Message-ID: <060.52dac2b4bcac78ba08c0da98d3669964@haskell.org> #10827: GHCi should support interpeting multiple packages/units with separate DynFlags -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHC API | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mgsloan): A couple other things that would be needed for proper multi-package ghci: 1. Per-package working directory, so that we can load files with relative paths, via TH. I'm imagining that this would work by changing the CWD before compiling a file or before running each splice. If we're allowing this bit of environment to vary, it also would be consistent to support different environment variables. I've never seen TH depend on that, though, so not very important.. 2. Per-package restriction of dependencies (-hide-all-packages / -package). Otherwise, it couldn't deal with the case where two of your packages depend on the same module name, imported from different packages. 3. Support for package qualified imports amongst your local packages. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 8 06:54:31 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Nov 2015 06:54:31 -0000 Subject: [GHC] #11069: :cd in GHCi unloads modules Message-ID: <046.f148df7c02b3f284ee9bbb87ae5f7b67@haskell.org> #11069: :cd in GHCi unloads modules -------------------------------------+------------------------------------- Reporter: mgsloan | Owner: Type: bug | Status: new Priority: low | Milestone: Component: GHCi | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If I run `stack ghci` in the [https://github.com/commercialhaskell/stack stack] repo, and then use `:cd`, I get the following: > Warning: changing directory causes all loaded modules to be unloaded, > because the search path has changed. And, indeed, all modules are unloaded. What's particularly strange about this is that in my case all of the paths provided on the commandline are absolute. Here's the output of ":show paths": > current working directory: > > /home/mgsloan/fpco/stack > > module import search paths: > > /home/mgsloan/fpco/stack/src > > /home/mgsloan/fpco/stack/.stack- work/dist/x86_64-linux/Cabal-1.22.4.0/build/autogen > > /home/mgsloan/fpco/stack/.stack- work/dist/x86_64-linux/Cabal-1.22.4.0/build > > /home/mgsloan/fpco/stack/src/main How about removing any dependency in GHC on the current working directory, and instead store it when the session is initialized? This is also necessary if we want to support per-package working directories, [https://ghc.haskell.org/trac/ghc/timeline?from=2015-11-08T06%3A17%3A58Z&precision=second details here]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 8 10:21:45 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Nov 2015 10:21:45 -0000 Subject: [GHC] #11044: Parse error on empty multi-line deprecation warnings In-Reply-To: <044.eca441d1c47bb055a7995ead40767af4@haskell.org> References: <044.eca441d1c47bb055a7995ead40767af4@haskell.org> Message-ID: <059.f5cb7f020d87e523cd225fd73835bf72@haskell.org> #11044: Parse error on empty multi-line deprecation warnings -------------------------------------+------------------------------------- Reporter: inaki | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 (Parser) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | parser/should_compile/T3303 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1433 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 8 10:27:49 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Nov 2015 10:27:49 -0000 Subject: [GHC] #11064: Call Arity has the trivial application case wrong In-Reply-To: <046.eb4c820640d5d418fe2e5ee76141b9f5@haskell.org> References: <046.eb4c820640d5d418fe2e5ee76141b9f5@haskell.org> Message-ID: <061.2e977184cbb67da8c536b0bacb5d322e@haskell.org> #11064: Call Arity has the trivial application case wrong -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata 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: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Is there some way we could formulate a test for this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 8 10:47:42 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Nov 2015 10:47:42 -0000 Subject: [GHC] #11069: :cd in GHCi unloads modules In-Reply-To: <046.f148df7c02b3f284ee9bbb87ae5f7b67@haskell.org> References: <046.f148df7c02b3f284ee9bbb87ae5f7b67@haskell.org> Message-ID: <061.2a1b9767e150e452243cb8c42d94c567@haskell.org> #11069: :cd in GHCi unloads modules -------------------------------------+------------------------------------- Reporter: mgsloan | Owner: Type: bug | Status: new Priority: low | Milestone: Component: GHCi | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): > How about removing any dependency in GHC on the current working directory, and instead store it when the session is initialized? Go ahead. GHCi is just as unmaintained as hpc, so it's all yours to fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 8 10:53:00 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Nov 2015 10:53:00 -0000 Subject: [GHC] #11070: Type-level arithmetic of sized-types has weaker inference power than in 7.8 Message-ID: <045.53eceb5327c44565612d8182117e7c77@haskell.org> #11070: Type-level arithmetic of sized-types has weaker inference power than in 7.8 -------------------------------------+------------------------------------- Reporter: cactus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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): | Wiki Page: -------------------------------------+------------------------------------- Given the following definitions (just a copy of the relevant bits from sized-types 0.3.5.1, to keep this example self-contained): {{{ -- Copied from sized-types 0.3.5.1 data X0 = X0 data N1 = N1 data X0_ a = X0_ Integer data X1_ a = X1_ Integer type X1 = X1_ X0 type X2 = X0_ (X1_ X0) class Size ix instance Size X0 instance Size a => Size (X1_ a) instance Size a => Size (X0_ a) type family APP0 a type instance APP0 X0 = X0 type instance APP0 N1 = X0_ N1 type instance APP0 (X1_ a) = X0_ (X1_ a) type instance APP0 (X0_ a) = X0_ (X0_ a) type family APP1 a type instance APP1 X0 = X1_ X0 type instance APP1 N1 = N1 type instance APP1 (X1_ a) = X1_ (X1_ a) type instance APP1 (X0_ a) = X1_ (X0_ a) type family SUCC a type instance SUCC X0 = X1_ X0 type instance SUCC N1 = X0 type instance SUCC (X1_ a) = APP0 (SUCC a) type instance SUCC (X0_ a) = APP1 a type family ADD a b type instance ADD a X0 = a type instance ADD X0 a = a type instance ADD X0 N1 = N1 type instance ADD N1 N1 = APP0 N1 type instance ADD N1 (X1_ b) = APP0 b type instance ADD N1 (X0_ b) = APP1 (ADD N1 b) type instance ADD (X1_ a) N1 = APP0 a type instance ADD (X0_ a) N1 = APP1 (ADD a N1) type instance ADD (X1_ a) (X1_ b) = APP0 (SUCC (ADD a b)) type instance ADD (X1_ a) (X0_ b) = APP1 (ADD a b) type instance ADD (X0_ a) (X1_ b) = APP1 (ADD a b) type instance ADD (X0_ a) (X0_ b) = APP0 (ADD a b) type family NOT a type instance NOT X0 = N1 type instance NOT N1 = X0 type instance NOT (X1_ a) = APP0 (NOT a) type instance NOT (X0_ a) = APP1 (NOT a) type SUB a b = ADD a (SUCC (NOT b)) }}} The following module typechecks with GHC 7.8.3: {{{ data B w = B (&*) :: (Size n, Size n', Size (ADD n' n), n ~ SUB (ADD n' n) n', n' ~ SUB (ADD n' n) n) => [(a, B n)] -> [(b, B n')] -> [((a, b), B (ADD n' n))] mks &* args = undefined foo :: [((), B X1)] foo = [((), B)] bar :: [(((), ()), B X2)] bar = [((), B)] &* foo }}} However, it fails with GHC 7.10.2, with {{{ /tmp/GHCBug.hs:70:7: Couldn't match type ?ADD X1 n0? with ?X0_ (X1_ X0)? The type variable ?n0? is ambiguous Expected type: [(((), ()), B X2)] Actual type: [(((), ()), B (ADD X1 n0))] In the expression: [((), B)] &* foo In an equation for ?bar?: bar = [((), B)] &* foo /tmp/GHCBug.hs:70:17: Occurs check: cannot construct the infinite type: n0 ~ ADD (ADD X1 n0) N1 The type variable ?n0? is ambiguous Expected type: SUB (ADD X1 n0) X1 Actual type: n0 In the expression: [((), B)] &* foo In an equation for ?bar?: bar = [((), B)] &* foo Failed, modules loaded: none. }}} The workaround/solution is to change the definition of `bar`: {{{ bar :: [(((), ()), B X2)] bar = [((), B :: B X1)] &* foo }}} This second version typechecks with GHC 7.10.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 8 10:54:42 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Nov 2015 10:54:42 -0000 Subject: [GHC] #11070: Type-level arithmetic of sized-types has weaker inference power than in 7.8 In-Reply-To: <045.53eceb5327c44565612d8182117e7c77@haskell.org> References: <045.53eceb5327c44565612d8182117e7c77@haskell.org> Message-ID: <060.3f1874c299aa958ae42d2ea51b8c7c21@haskell.org> #11070: Type-level arithmetic of sized-types has weaker inference power than in 7.8 -------------------------------------+------------------------------------- Reporter: cactus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by cactus): * keywords: => TypeFamilies -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 8 11:19:10 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Nov 2015 11:19:10 -0000 Subject: [GHC] #11066: Inacessible branch should be warning - otherwise breaks type soundness? In-Reply-To: <047.0785946e31f05741dc32414264d84d16@haskell.org> References: <047.0785946e31f05741dc32414264d84d16@haskell.org> Message-ID: <062.ede07d2ee7da13645423fe1578e830e9@haskell.org> #11066: Inacessible branch should be warning - otherwise breaks type soundness? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.2 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jstolarek): * cc: jstolarek (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 8 11:39:40 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Nov 2015 11:39:40 -0000 Subject: [GHC] #10827: GHCi should support interpeting multiple packages/units with separate DynFlags In-Reply-To: <045.56917c0b2dd940e5429ceefba9639e36@haskell.org> References: <045.56917c0b2dd940e5429ceefba9639e36@haskell.org> Message-ID: <060.707da2cb1904e513aed9f0e3f9b193ba@haskell.org> #10827: GHCi should support interpeting multiple packages/units with separate DynFlags -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHC API | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * cc: alanz (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 8 13:16:54 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Nov 2015 13:16:54 -0000 Subject: [GHC] #11071: The "Not in scope" error is misleading Message-ID: <047.e970b72d66ebf0753d36739a65af99a0@haskell.org> #11071: The "Not in scope" error is misleading -------------------------------------+------------------------------------- Reporter: mojojojo | 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 Rev(s): | Wiki Page: -------------------------------------+------------------------------------- E.g., if I have something like `Maybe.maybeToList` in a module, which does not have such an import, I get the following error: Not in scope: ?Maybe.maybeToList? Which leads the user to conclude that the `Maybe` namespace does not contain the `maybeToList` element, instead of informing that the `Maybe` namespace is not imported altogether instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 8 17:28:47 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Nov 2015 17:28:47 -0000 Subject: [GHC] #11066: Inacessible branch should be warning - otherwise breaks type soundness? In-Reply-To: <047.0785946e31f05741dc32414264d84d16@haskell.org> References: <047.0785946e31f05741dc32414264d84d16@haskell.org> Message-ID: <062.d955298dda88ef84edf1ad1a9c098155@haskell.org> #11066: Inacessible branch should be warning - otherwise breaks type soundness? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.2 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * cc: osa1 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 8 17:29:04 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Nov 2015 17:29:04 -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.03e8d207003cbfa88b2bbc1f8d627d81@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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gelisam): osa1, I am not that person, but here is an explanation. If you have a file called `./Foo.hs` and you try to import it, `ghci` tells you that it doesn't know about that file, because you haven't loaded it yet: {{{ $ ghci GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help Prelude> import Data.List : Could not find module ?Foo? It is not a module in the current program, or in any known package. }}} The solution is to run `:load Foo.hs` before `import Foo`. If you have a file called `./Data/List.hs`, this now conflicts with the `Data.List` from `base`, so you get a different message clarifying which module is not loaded: {{{ $ ghci GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help Prelude> import Data.List :1:1: attempting to use module ?Data.List? (./Data/List.hs) which is not loaded }}} The solution is to run `:load Data/List.hs` before `import Data.List`. Now without `-XNoImplicitPrelude`, `ghci` begins by running `import Prelude`, which normally succeeds by loading the Prelude from `base`, but in this case, since there is a `./Prelude.hs` file, `ghci` tells you that it can't use that file because it isn't loaded yet. Since the user didn't explicitly type `import Prelude`, the error message is confusing, so maybe there should be some special logic to give a different message in that case or even to implicitly `:load ./Prelude.hs`. Note, however, that there are other modules than Prelude which can trigger this error message when particular files are present and the user hasn't explicitly typed an import statement. If your `.ghci` has an `import Data.List` intended to import the `Data.List` from `base`, it will usually work, until you have a local file called `./Data/List.hs` in which case `ghci` will complain on startup with this same message that it can't use `./Data/List.hs` because it is not loaded. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 8 18:09:14 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Nov 2015 18:09:14 -0000 Subject: [GHC] #11071: The "Not in scope" error is misleading In-Reply-To: <047.e970b72d66ebf0753d36739a65af99a0@haskell.org> References: <047.e970b72d66ebf0753d36739a65af99a0@haskell.org> Message-ID: <062.c80d32e3024aea4e06492fae7607a263@haskell.org> #11071: The "Not in scope" error is misleading -------------------------------------+------------------------------------- Reporter: mojojojo | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I don't understand why would anyone conclude from this message: {{{ Not in scope: NameSpace.name }}} that the namespace doesn't define the name. The message doesn't say anything about something being defined or not, it's very clearly saying that the name is not in scope. It may be because of different reasons. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 8 18:14:06 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Nov 2015 18:14:06 -0000 Subject: [GHC] #11071: The "Not in scope" error is misleading In-Reply-To: <047.e970b72d66ebf0753d36739a65af99a0@haskell.org> References: <047.e970b72d66ebf0753d36739a65af99a0@haskell.org> Message-ID: <062.9e91c87e3bb76c031d15c3e2052702c1@haskell.org> #11071: The "Not in scope" error is misleading -------------------------------------+------------------------------------- Reporter: mojojojo | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mojojojo): Reference to a specific member implies that that particular member is the problem, while in reality it is the absence of the whole namespace that is the problem. In no way does the current message suggest that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 8 18:31:30 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Nov 2015 18:31:30 -0000 Subject: [GHC] #11071: The "Not in scope" error is misleading In-Reply-To: <047.e970b72d66ebf0753d36739a65af99a0@haskell.org> References: <047.e970b72d66ebf0753d36739a65af99a0@haskell.org> Message-ID: <062.8edd9e7b7176a0a6de3047fc680a0f38@haskell.org> #11071: The "Not in scope" error is misleading -------------------------------------+------------------------------------- Reporter: mojojojo | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jstolarek): Replying to [comment:2 mojojojo]: > while in reality it is the absence of the whole namespace that is the problem I disagree. If you have: ``` import Foo hiding ( bar ) ``` then `Foo` namespace is available, but any reference to `bar` will still result with "not in scope" error. I find the error message entirely correct and vote to close this ticket as "invalid". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 8 19:13:33 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Nov 2015 19:13:33 -0000 Subject: [GHC] #11071: The "Not in scope" error is misleading In-Reply-To: <047.e970b72d66ebf0753d36739a65af99a0@haskell.org> References: <047.e970b72d66ebf0753d36739a65af99a0@haskell.org> Message-ID: <062.994785f16eb0f24f849ac07fa9c2baf2@haskell.org> #11071: The "Not in scope" error is misleading -------------------------------------+------------------------------------- Reporter: mojojojo | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mojojojo): Replying to [comment:3 jstolarek]: You're missing the point here. The issue is that the message does not make sense specifically when the namespace is **not imported in any way**. It misleads the user to assume that it is imported but does not contain the member (or has it hidden), when the issue is absolutely different. Your example is simply not related to the issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 8 21:02:12 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Nov 2015 21:02:12 -0000 Subject: [GHC] #11072: Runtime linker doesn't search for DLLs referenced in import libraries on Windows Message-ID: <050.675e99e0c3128be1426b83f1c6310ea3@haskell.org> #11072: Runtime linker doesn't search for DLLs referenced in import libraries on Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2-rc2 (Linking) | Keywords: | Operating System: Windows Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- (This is adapted from the comments [https://github.com/bos/text- icu/issues/12#issuecomment-154452774 here].) On Windows, the GHC runtime linker only searches for DLLs that have the same names as the import libraries passed to `-l`. This can sometimes create problems, since a library name could be different from the DLL it needs. `text-icu` provides an example of this, since it needs the extra libraries `icuuc`, `icudt`, and `icuin`. However, if you download the [http://site .icu-project.org/download/56#TOC-ICU4C-Download official ICU 56 binaries], they are distributed with DLLs named `icuuc56.dll`, `icudt56.dll`, and `icuin56.dll`, rather than `icuuc.dll`, `icudt.dll`, and `icuin.dll`. This doesn't create any trouble for the linker at compile-time. In fact, if you compile this program {{{#!hs -- TextICU.hs import Data.Text.ICU.Break main = print Kana }}} with `ghc TextICU.hs` and then run `cygcheck ./TextICU.hs` without having the ICU4C `bin64` folder in your `PATH`, it ''appears'' to search for the right DLLs: {{{ $ cygcheck ./TextICU.hs ... cygcheck: track_down: could not find icuin56.dll cygcheck: track_down: could not find icuuc56.dll }}} But actually running the code reveals a different story: {{{ $ runghc TextICU.hs TextICU.hs: icuuc: The specified module could not be found. TextICU.hs: : can't load .so/.DLL for: icuuc.dll (addDLL: could not load DLL) }}} This demonstrates that the runtime linker behaves differently; it is dependent on what the linked libraries' names are. To confirm this, you can recompile `text-icu` with the following changes to `text-icu.cabal`: {{{ extra-libraries: icuuc56 if os(mingw32) extra-libraries: icuin56 icudt56 }}} Also make symlinks named `icuuc56.lib`, `icuin56.lib`, and `icudt56.lib` that refer to `icuuc.lib`, `icuin.lib`, and `licudt.lib`, respectively, in the ICU4C `lib64` directory. Now `cygcheck` and `ghc` agree on which DLLs to use: {{{ $ ghc TextICU.hs $ cygcheck ./TextICU.exe ... cygcheck: track_down: could not find icuin56.dll cygcheck: track_down: could not find icuuc56.dll $ runghc TextICU.hs TextICU.hs: icuuc56: The specified module could not be found. TextICU.hs: : can't load .so/.DLL for: icuuc56.dll (addDLL: could not load DLL) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 8 21:54:26 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Nov 2015 21:54:26 -0000 Subject: [GHC] #11058: selected processor does not support ARM mode In-Reply-To: <046.179fa65419f6552c89ce7f996b230033@haskell.org> References: <046.179fa65419f6552c89ce7f996b230033@haskell.org> Message-ID: <061.e28c4b6b8555b5d5ed5e00a2dc7ed87c@haskell.org> #11058: selected processor does not support ARM mode ----------------------------------------+------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------ Comment (by erikd): This gets stranger still. If I simply revert commit `933adc0f31164cb651d` (on master) it still doesn't build on `armel`. Going to try build the debian ghc-7.10.2 package just to make sure I know what I'm doing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 8 22:39:11 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Nov 2015 22:39:11 -0000 Subject: [GHC] #11071: "Not in scope" errors should be more informative for qualified names. (was: The "Not in scope" error is misleading) In-Reply-To: <047.e970b72d66ebf0753d36739a65af99a0@haskell.org> References: <047.e970b72d66ebf0753d36739a65af99a0@haskell.org> Message-ID: <062.eb15124c621a9146f21c50ca415a6246@haskell.org> #11071: "Not in scope" errors should be more informative for qualified names. -------------------------------------+------------------------------------- Reporter: mojojojo | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * type: bug => feature request Comment: No need to get excited. We have a track of giving rather verbose error messages that try to convey as much information as possible to the user. So simply add any useful additional information, such as: {{{ Not in scope: ?Maybe.maybeToList? No Module named Maybe is imported. }}} or {{{ Not in scope: ?Maybe.maybeToList? Module `Maybe` does not provide `maybeToList` }}} or {{{ Not in scope: ?Maybe.maybeToList? Your import of `Maybe` explicitly hides `maybeToList`. }}} for the three cases I can think of why some `Foo.bar` is not in scope. This would indeed be useful, and helpful in any case. It?s also not completely trivial, as there is a many-to-many mapping of modules and modules name in scope, due to qualified imports. Nevertheless, this looks like a nice newcomer task. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 8 23:21:39 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Nov 2015 23:21:39 -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.f232231185a5ed83edd53b9b546becad@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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by L29Ah): Yeah, that would be a nice thing to have. Now ghc build system is pissed given {{{ GhcStage2HcOpts = -optl-static -optl-pthread -static }}} {{{ /home/l29ah/projects/climate/buildroot-musl/output/host/usr/bin/../lib/gcc /arm-buildroot-linux-musleabihf/4.9.3/../../../../arm-buildroot-linux- musleabihf/bin/ld.gold: error: cannot find -lHStransformers-0.4.3.0-ghc7.11.20151108 /home/l29ah/projects/climate/buildroot-musl/output/host/usr/bin/../lib/gcc /arm-buildroot-linux-musleabihf/4.9.3/../../../../arm-buildroot-linux- musleabihf/bin/ld.gold: error: cannot find -lHStemplate- haskell-2.11.0.0-ghc7.11.20151108 /home/l29ah/projects/climate/buildroot-musl/output/host/usr/bin/../lib/gcc /arm-buildroot-linux-musleabihf/4.9.3/../../../../arm-buildroot-linux- musleabihf/bin/ld.gold: error: cannot find -lHSpretty-1.1.2.0-ghc7.11.20151108 /home/l29ah/projects/climate/buildroot-musl/output/host/usr/bin/../lib/gcc /arm-buildroot-linux-musleabihf/4.9.3/../../../../arm-buildroot-linux- musleabihf/bin/ld.gold: error: cannot find -lHSprocess-1.4.0.0-ghc7.11.20151108 ? }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 9 02:18:02 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Nov 2015 02:18:02 -0000 Subject: [GHC] #11073: GHC ASSERT when compiling Data.Sequences in the mono-traversable-0.10.0 Message-ID: <046.63424d3c1b78177ce6a10bd87299b1b9@haskell.org> #11073: GHC ASSERT when compiling Data.Sequences in the mono-traversable-0.10.0 --------------------------------+--------------------------------------- Reporter: highfly | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Linux Architecture: arm | Type of failure: Compile-time crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+--------------------------------------- GHC reports : {{{ [4 of 7] Compiling Data.Sequences ( src/Data/Sequences.hs, dist/build/Data/Sequences.o ) *** Parser: *** Renamer/typechecker: *** Deleting temp files: Deleting: /tmp/ghc12990_0/ghc_35.ll /tmp/ghc12990_0/ghc_1.hscpp Warning: deleting non-existent /tmp/ghc12990_0/ghc_35.ll *** Deleting temp dirs: Deleting: /tmp/ghc12990_0 ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for arm-unknown-linux): ASSERT failed! file compiler/typecheck/TcEvidence.hs line 597 Sym cobox_a2uDU Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 9 02:19:57 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Nov 2015 02:19:57 -0000 Subject: [GHC] #11073: GHC ASSERT when compiling Data.Sequences in the mono-traversable-0.10.0 In-Reply-To: <046.63424d3c1b78177ce6a10bd87299b1b9@haskell.org> References: <046.63424d3c1b78177ce6a10bd87299b1b9@haskell.org> Message-ID: <061.206d92bf30106a70f2fd04426da5694c@haskell.org> #11073: GHC ASSERT when compiling Data.Sequences in the mono-traversable-0.10.0 ---------------------------------------+------------------------------ Reporter: highfly | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Compile-time crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------------+------------------------------ Changes (by highfly): * Attachment "mono-traversable-0.10.0.log" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 9 03:39:23 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Nov 2015 03:39:23 -0000 Subject: [GHC] #11070: Type-level arithmetic of sized-types has weaker inference power than in 7.8 In-Reply-To: <045.53eceb5327c44565612d8182117e7c77@haskell.org> References: <045.53eceb5327c44565612d8182117e7c77@haskell.org> Message-ID: <060.d89b58eb7a98b385050fe9494e68bec5@haskell.org> #11070: Type-level arithmetic of sized-types has weaker inference power than in 7.8 -------------------------------------+------------------------------------- Reporter: cactus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by cactus: Old description: > Given the following definitions (just a copy of the relevant bits from > sized-types 0.3.5.1, to keep this example self-contained): > > {{{ > -- Copied from sized-types 0.3.5.1 > data X0 = X0 > data N1 = N1 > > data X0_ a = X0_ Integer > data X1_ a = X1_ Integer > type X1 = X1_ X0 > type X2 = X0_ (X1_ X0) > > class Size ix > instance Size X0 > instance Size a => Size (X1_ a) > instance Size a => Size (X0_ a) > > type family APP0 a > type instance APP0 X0 = X0 > type instance APP0 N1 = X0_ N1 > type instance APP0 (X1_ a) = X0_ (X1_ a) > type instance APP0 (X0_ a) = X0_ (X0_ a) > > type family APP1 a > type instance APP1 X0 = X1_ X0 > type instance APP1 N1 = N1 > type instance APP1 (X1_ a) = X1_ (X1_ a) > type instance APP1 (X0_ a) = X1_ (X0_ a) > > type family SUCC a > type instance SUCC X0 = X1_ X0 > type instance SUCC N1 = X0 > type instance SUCC (X1_ a) = APP0 (SUCC a) > type instance SUCC (X0_ a) = APP1 a > > type family ADD a b > type instance ADD a X0 = a > type instance ADD X0 a = a > type instance ADD X0 N1 = N1 > type instance ADD N1 N1 = APP0 N1 > type instance ADD N1 (X1_ b) = APP0 b > type instance ADD N1 (X0_ b) = APP1 (ADD N1 b) > type instance ADD (X1_ a) N1 = APP0 a > type instance ADD (X0_ a) N1 = APP1 (ADD a N1) > type instance ADD (X1_ a) (X1_ b) = APP0 (SUCC (ADD a b)) > type instance ADD (X1_ a) (X0_ b) = APP1 (ADD a b) > type instance ADD (X0_ a) (X1_ b) = APP1 (ADD a b) > type instance ADD (X0_ a) (X0_ b) = APP0 (ADD a b) > > type family NOT a > type instance NOT X0 = N1 > type instance NOT N1 = X0 > type instance NOT (X1_ a) = APP0 (NOT a) > type instance NOT (X0_ a) = APP1 (NOT a) > > type SUB a b = ADD a (SUCC (NOT b)) > > }}} > > The following module typechecks with GHC 7.8.3: > > {{{ > data B w = B > > (&*) :: (Size n, Size n', Size (ADD n' n), n ~ SUB (ADD n' n) n', n' ~ > SUB (ADD n' n) n) > => [(a, B n)] -> [(b, B n')] -> [((a, b), B (ADD n' n))] > mks &* args = undefined > > foo :: [((), B X1)] > foo = [((), B)] > > bar :: [(((), ()), B X2)] > bar = [((), B)] &* foo > }}} > > However, it fails with GHC 7.10.2, with > > {{{ > /tmp/GHCBug.hs:70:7: > Couldn't match type ?ADD X1 n0? with ?X0_ (X1_ X0)? > The type variable ?n0? is ambiguous > Expected type: [(((), ()), B X2)] > Actual type: [(((), ()), B (ADD X1 n0))] > In the expression: [((), B)] &* foo > In an equation for ?bar?: bar = [((), B)] &* foo > > /tmp/GHCBug.hs:70:17: > Occurs check: cannot construct the infinite type: > n0 ~ ADD (ADD X1 n0) N1 > The type variable ?n0? is ambiguous > Expected type: SUB (ADD X1 n0) X1 > Actual type: n0 > In the expression: [((), B)] &* foo > In an equation for ?bar?: bar = [((), B)] &* foo > Failed, modules loaded: none. > }}} > > The workaround/solution is to change the definition of `bar`: > > {{{ > bar :: [(((), ()), B X2)] > bar = [((), B :: B X1)] &* foo > }}} > > This second version typechecks with GHC 7.10.2. New description: Given the following definitions (just a copy of the relevant bits from sized-types 0.3.5.1, to keep this example self-contained): {{{ -- Copied from sized-types 0.3.5.1 data X0 = X0 data N1 = N1 data X0_ a = X0_ Integer data X1_ a = X1_ Integer type X1 = X1_ X0 type X2 = X0_ (X1_ X0) type family APP0 a type instance APP0 X0 = X0 type instance APP0 N1 = X0_ N1 type instance APP0 (X1_ a) = X0_ (X1_ a) type instance APP0 (X0_ a) = X0_ (X0_ a) type family APP1 a type instance APP1 X0 = X1_ X0 type instance APP1 N1 = N1 type instance APP1 (X1_ a) = X1_ (X1_ a) type instance APP1 (X0_ a) = X1_ (X0_ a) type family SUCC a type instance SUCC X0 = X1_ X0 type instance SUCC N1 = X0 type instance SUCC (X1_ a) = APP0 (SUCC a) type instance SUCC (X0_ a) = APP1 a type family ADD a b type instance ADD a X0 = a type instance ADD X0 a = a type instance ADD X0 N1 = N1 type instance ADD N1 N1 = APP0 N1 type instance ADD N1 (X1_ b) = APP0 b type instance ADD N1 (X0_ b) = APP1 (ADD N1 b) type instance ADD (X1_ a) N1 = APP0 a type instance ADD (X0_ a) N1 = APP1 (ADD a N1) type instance ADD (X1_ a) (X1_ b) = APP0 (SUCC (ADD a b)) type instance ADD (X1_ a) (X0_ b) = APP1 (ADD a b) type instance ADD (X0_ a) (X1_ b) = APP1 (ADD a b) type instance ADD (X0_ a) (X0_ b) = APP0 (ADD a b) type family NOT a type instance NOT X0 = N1 type instance NOT N1 = X0 type instance NOT (X1_ a) = APP0 (NOT a) type instance NOT (X0_ a) = APP1 (NOT a) type SUB a b = ADD a (SUCC (NOT b)) }}} The following module typechecks with GHC 7.8.3: {{{ data B w = B (&*) :: (n ~ SUB (ADD n' n) n', n' ~ SUB (ADD n' n) n) => [(a, B n)] -> [(b, B n')] -> [((a, b), B (ADD n' n))] mks &* args = undefined foo :: [((), B X1)] foo = [((), B)] bar :: [(((), ()), B X2)] bar = [((), B)] &* foo }}} However, it fails with GHC 7.10.2, with {{{ /tmp/GHCBug.hs:70:7: Couldn't match type ?ADD X1 n0? with ?X0_ (X1_ X0)? The type variable ?n0? is ambiguous Expected type: [(((), ()), B X2)] Actual type: [(((), ()), B (ADD X1 n0))] In the expression: [((), B)] &* foo In an equation for ?bar?: bar = [((), B)] &* foo /tmp/GHCBug.hs:70:17: Occurs check: cannot construct the infinite type: n0 ~ ADD (ADD X1 n0) N1 The type variable ?n0? is ambiguous Expected type: SUB (ADD X1 n0) X1 Actual type: n0 In the expression: [((), B)] &* foo In an equation for ?bar?: bar = [((), B)] &* foo Failed, modules loaded: none. }}} The workaround/solution is to change the definition of `bar`: {{{ bar :: [(((), ()), B X2)] bar = [((), B :: B X1)] &* foo }}} This second version typechecks with GHC 7.10.2. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 9 03:43:13 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Nov 2015 03:43:13 -0000 Subject: [GHC] #11070: Type-level arithmetic of sized-types has weaker inference power than in 7.8 In-Reply-To: <045.53eceb5327c44565612d8182117e7c77@haskell.org> References: <045.53eceb5327c44565612d8182117e7c77@haskell.org> Message-ID: <060.6482ae8638612ab9e9b3df494bd1dfb4@haskell.org> #11070: Type-level arithmetic of sized-types has weaker inference power than in 7.8 -------------------------------------+------------------------------------- Reporter: cactus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by cactus): The same behaviour can be observed with the closed-type-family version below: {{{ data X0 = X0 data N1 = N1 data X0_ a = X0_ Integer data X1_ a = X1_ Integer type X1 = X1_ X0 type X2 = X0_ (X1_ X0) type family APP0 a where APP0 X0 = X0 APP0 N1 = X0_ N1 APP0 (X1_ a) = X0_ (X1_ a) APP0 (X0_ a) = X0_ (X0_ a) type family APP1 a where APP1 X0 = X1_ X0 APP1 N1 = N1 APP1 (X1_ a) = X1_ (X1_ a) APP1 (X0_ a) = X1_ (X0_ a) type family SUCC a where SUCC X0 = X1_ X0 SUCC N1 = X0 SUCC (X1_ a) = APP0 (SUCC a) SUCC (X0_ a) = APP1 a type family ADD a b where ADD a X0 = a ADD X0 a = a ADD N1 N1 = APP0 N1 ADD N1 (X1_ b) = APP0 b ADD N1 (X0_ b) = APP1 (ADD N1 b) ADD (X1_ a) N1 = APP0 a ADD (X0_ a) N1 = APP1 (ADD a N1) ADD (X1_ a) (X1_ b) = APP0 (SUCC (ADD a b)) ADD (X1_ a) (X0_ b) = APP1 (ADD a b) ADD (X0_ a) (X1_ b) = APP1 (ADD a b) ADD (X0_ a) (X0_ b) = APP0 (ADD a b) type family NOT a where NOT X0 = N1 NOT N1 = X0 NOT (X1_ a) = APP0 (NOT a) NOT (X0_ a) = APP1 (NOT a) type SUB a b = ADD a (SUCC (NOT b)) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 9 04:11:03 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Nov 2015 04:11:03 -0000 Subject: [GHC] #10982: Warn about unused pattern variables in type families In-Reply-To: <048.414cea110a08b8e94adb14433ca6c307@haskell.org> References: <048.414cea110a08b8e94adb14433ca6c307@haskell.org> Message-ID: <063.68476bb64a2725b0f87acef09fab5baa@haskell.org> #10982: Warn about unused pattern variables in type families -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: msosn Type: feature request | Status: new Priority: normal | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by msosn): * owner: => msosn -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 9 09:54:15 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Nov 2015 09:54:15 -0000 Subject: [GHC] #11068: Make Generic/Generic1 methods inlinable In-Reply-To: <044.2644399b8f2d6a8d61669300e8f810a3@haskell.org> References: <044.2644399b8f2d6a8d61669300e8f810a3@haskell.org> Message-ID: <059.aa8f73ab94a8641fc04d3724c84dda58@haskell.org> #11068: Make Generic/Generic1 methods inlinable -------------------------------------+------------------------------------- Reporter: glguy | 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 Rev(s): Phab:D1447 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: kosmikus, dreixel (added) Comment: Sounds interesting! Do you have a human-readable description of * the problem you are trying to solve; e.g. is it precisely the problem described in [https://www.cs.ox.ac.uk/people/publications/date/JosePedro.Magalhaes.html Pedro's papers] "Optimisation of Generic Programs through Inlining" and "Optimizing SYB is Easy!")? * the approach you are taking to solve it? Adding Andres (kosmikus) who is in charge of generics in GHC, and Pedro (dreixel). Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 9 10:23:22 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Nov 2015 10:23:22 -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.b1f8bdf97e885218970b37e081999dde@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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): That sounds plausible to me. Names you export should be civilised. But how could they be exported anyway? You can't mention it in the export list, presumably. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 9 10:47:15 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Nov 2015 10:47:15 -0000 Subject: [GHC] #11074: invalid fixup in runtime linker Message-ID: <044.8a0aa9f1d3d6c6f83e1369f687f42004@haskell.org> #11074: invalid fixup in runtime linker -------------------------------------+------------------------------------- Reporter: Qinka | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: invalid fixup | Operating System: Windows in runtime linker | Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I don't know what was happened, while I was trying to use PostgreSQL. And the following is what is displayed. {{{ Prelude Database.PostgreSQL.LibPQ Data.ByteString.Internal> connectdb "d" : internal error: checkProddableBlock: invalid fixup in runtime linker: 000000000bec00e8 (GHC version 7.10.2 for x86_64_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. }}} PS: I try to install some kinds of PostgreSQL's packages. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 9 11:16:45 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Nov 2015 11:16:45 -0000 Subject: [GHC] #11071: "Not in scope" errors should be more informative for qualified names. In-Reply-To: <047.e970b72d66ebf0753d36739a65af99a0@haskell.org> References: <047.e970b72d66ebf0753d36739a65af99a0@haskell.org> Message-ID: <062.38eef204b9da7ebe4403dcb8dedfbb4a@haskell.org> #11071: "Not in scope" errors should be more informative for qualified names. -------------------------------------+------------------------------------- Reporter: mojojojo | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I think comment:5 has it right. Adding supplementary hints to a failed use of a qualified name would be a fine thing to do. Not entirely trivial to implement: the `GlobalRdrEnv` records what ''is'' in scope, not what is ''not'' in scope. So you'd have to go back to the original imports. Quite do-able though. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 9 11:31:37 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Nov 2015 11:31:37 -0000 Subject: [GHC] #11071: "Not in scope" errors should be more informative for qualified names. In-Reply-To: <047.e970b72d66ebf0753d36739a65af99a0@haskell.org> References: <047.e970b72d66ebf0753d36739a65af99a0@haskell.org> Message-ID: <062.0f948446be918c08e6d088d3176e3ef2@haskell.org> #11071: "Not in scope" errors should be more informative for qualified names. -------------------------------------+------------------------------------- Reporter: mojojojo | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mojojojo): I absolutely agree with the suggestions by @nomeata as well. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 9 11:59:17 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Nov 2015 11:59:17 -0000 Subject: [GHC] #11066: Inacessible branch should be warning - otherwise breaks type soundness? In-Reply-To: <047.0785946e31f05741dc32414264d84d16@haskell.org> References: <047.0785946e31f05741dc32414264d84d16@haskell.org> Message-ID: <062.3eb1377a37f0ad43371f26561fbdbd94@haskell.org> #11066: Inacessible branch should be warning - otherwise breaks type soundness? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.2 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm ok with making it a warning instead of an error. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 9 12:47:41 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Nov 2015 12:47:41 -0000 Subject: [GHC] #10583: Chaos in Lexeme.hs In-Reply-To: <047.ca228b2a0d43586fb2828ecd680f46fc@haskell.org> References: <047.ca228b2a0d43586fb2828ecd680f46fc@haskell.org> Message-ID: <062.f85ea5fc546adc81f0deeb6aa4f9e0b5@haskell.org> #10583: Chaos in Lexeme.hs -------------------------------------+------------------------------------- Reporter: goldfire | Owner: albertus 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: | testsuite/tests/th/T11046.hs Blocked By: | Blocking: 10582, 11046 Related Tickets: | Differential Rev(s): Phab:D1451 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * differential: => Phab:D1451 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 9 12:47:57 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Nov 2015 12:47:57 -0000 Subject: [GHC] #11046: lookupTypeName does not support type operators not starting with : In-Reply-To: <045.eabc8eeec9cc920f3e0838e9774eff4d@haskell.org> References: <045.eabc8eeec9cc920f3e0838e9774eff4d@haskell.org> Message-ID: <060.fc36ff0c2d9cab23c05a548b3bf77dc3@haskell.org> #11046: lookupTypeName does not support type operators not starting with : -------------------------------------+------------------------------------- Reporter: oerjan | Owner: albertus Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | testsuite/tests/th/TH_lookupName.hs, | testsuite/tests/th/T11046.hs Blocked By: | Blocking: Related Tickets: #10583 | Differential Rev(s): Phab:D1451 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * differential: => Phab:D1451 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 9 13:52:32 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Nov 2015 13:52:32 -0000 Subject: [GHC] #4931: hsc2hs emits invalid OPTIONS_GHC pragmas In-Reply-To: <044.1c25c557108c2107caf9aec19c931e7c@haskell.org> References: <044.1c25c557108c2107caf9aec19c931e7c@haskell.org> Message-ID: <059.bc7c88ae949bfb9f0b1030f96f91c363@haskell.org> #4931: hsc2hs emits invalid OPTIONS_GHC pragmas -------------------------------------+------------------------------------- Reporter: awson | Owner: thomie Type: bug | Status: new Priority: low | Milestone: 8.0.1 Component: hsc2hs | Version: 7.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: driver/T4931 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1452 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * keywords: newcomer => * owner: terrelln => thomie * differential: => Phab:D1452 * testcase: => driver/T4931 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 9 14:09:43 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Nov 2015 14:09:43 -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.e4903aefbf33d111e754c72641bb02f3@haskell.org> #4931: hsc2hs emits invalid OPTIONS_GHC pragmas -------------------------------------+------------------------------------- Reporter: awson | Owner: thomie Type: bug | Status: patch Priority: low | Milestone: 8.0.1 Component: hsc2hs | Version: 7.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: driver/T4931 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1452 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch Comment: The patch in Phab:D1452 doesn't handle `#define FOO "bar \"baz\""` (comment:8), but it does handle the example from the description: `#define FOO "bar baz"`. I still don't know if emitting `{-# OPTIONS_GHC -optc-DFOO=... #-}` makes sense at all, but oh well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 9 14:41:56 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Nov 2015 14:41:56 -0000 Subject: [GHC] #11074: invalid fixup in runtime linker In-Reply-To: <044.8a0aa9f1d3d6c6f83e1369f687f42004@haskell.org> References: <044.8a0aa9f1d3d6c6f83e1369f687f42004@haskell.org> Message-ID: <059.121590fa11e413f68cba9d14aa8f74d0@haskell.org> #11074: invalid fixup in runtime linker -------------------------------------+------------------------------------- Reporter: Qinka | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: invalid fixup | in runtime linker Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Qinka): * cc: gcc, version, 4.6.3, (rubenvb-4.6.3) (removed) Old description: > I don't know what was happened, while I was trying to use PostgreSQL. > > And the following is what is displayed. > > {{{ > Prelude Database.PostgreSQL.LibPQ Data.ByteString.Internal> connectdb "d" > : internal error: checkProddableBlock: invalid fixup in > runtime linker: 000000000bec00e8 > (GHC version 7.10.2 for x86_64_unknown_mingw32) > Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug > > This application has requested the Runtime to terminate it in an unusual > way. > Please contact the application's support team for more information. > }}} > > PS: I try to install some kinds of PostgreSQL's packages. New description: I don't know what was happened, while I was trying to use PostgreSQL. And the following is what is displayed. {{{ Prelude Database.PostgreSQL.LibPQ Data.ByteString.Internal> connectdb "d" : internal error: checkProddableBlock: invalid fixup in runtime linker: 000000000bec00e8 (GHC version 7.10.2 for x86_64_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. }}} PS: I try to install some kinds of PostgreSQL's packages, with ghc-7.10.2 and gcc-4.6.3, (rubenvb-4.6.3). -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 9 14:53:09 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Nov 2015 14:53:09 -0000 Subject: [GHC] #11074: invalid fixup in runtime linker In-Reply-To: <044.8a0aa9f1d3d6c6f83e1369f687f42004@haskell.org> References: <044.8a0aa9f1d3d6c6f83e1369f687f42004@haskell.org> Message-ID: <059.71c869589ed2752ed6e21832de1df480@haskell.org> #11074: invalid fixup in runtime linker -------------------------------------+------------------------------------- Reporter: Qinka | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: invalid fixup | in runtime linker Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Qinka): I had seen some tickets which has the same problem. But I could not find the way to solve it rightly. What should I do?? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 9 14:56:25 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Nov 2015 14:56:25 -0000 Subject: [GHC] #11007: Type family injectivity annotations ignored in hs-boot files In-Reply-To: <047.26e4b74bfa5db1c5fbbc0697a9084694@haskell.org> References: <047.26e4b74bfa5db1c5fbbc0697a9084694@haskell.org> Message-ID: <062.0b0d3b6f2e581e56488f34028b9f087e@haskell.org> #11007: Type family injectivity annotations ignored in hs-boot files -------------------------------------+------------------------------------- Reporter: goldfire | Owner: jstolarek Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T6018 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1453 Wiki Page: | -------------------------------------+------------------------------------- Changes (by jstolarek): * testcase: => typecheck/should_compile/T6018 * differential: => Phab:D1453 Comment: Richard, can you CC me on injectivity bugs that you report? This one nearly went past my radar. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 9 14:57:26 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Nov 2015 14:57:26 -0000 Subject: [GHC] #11074: invalid fixup in runtime linker In-Reply-To: <044.8a0aa9f1d3d6c6f83e1369f687f42004@haskell.org> References: <044.8a0aa9f1d3d6c6f83e1369f687f42004@haskell.org> Message-ID: <059.73dbbaa61f460431001fd93980976f79@haskell.org> #11074: invalid fixup in runtime linker -------------------------------------+------------------------------------- Reporter: Qinka | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: invalid fixup | in runtime linker Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Qinka): * priority: normal => highest -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 9 15:13:02 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Nov 2015 15:13:02 -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.d0dda570e9d48c6b5a3810297ce0f2a1@haskell.org> #10870: PPC.Ppr: Shift by 32 bits is not allowed. ---------------------------------------+---------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.3 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 Rev(s): Phab:D1322 Wiki Page: | ---------------------------------------+---------------------------------- Changes (by trommler): * Attachment "0001-PPC-nativeGen-fix-shift-right-arithmetic-31-bit.patch" added. ...and for arithmetic right shifts -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 9 15:18:19 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Nov 2015 15:18:19 -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.f0dd757fe27266479aa6d6182b74c676@haskell.org> #10870: PPC.Ppr: Shift by 32 bits is not allowed. ---------------------------------------+---------------------------------- Reporter: nomeata | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.3 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 Rev(s): Phab:D1322 Wiki Page: | ---------------------------------------+---------------------------------- Changes (by trommler): * status: new => infoneeded Comment: Replying to [comment:12 nomeata]: > Sorry to be the bringer of bad news, but this seems to be still occurring in 7.10.3-rc1: > > https://buildd.debian.org/status/fetch.php?pkg=haskell-vector- algorithms&arch=powerpc&ver=0.7.0.1-2&stamp=1446804253 Can you try the above patch (0001-PPC-nativeGen-fix-shift-right- arithmetic-31-bit.patch)? I could only eye-ball the code (no 32 bit installation here), but I am pretty sure this is the only case left that triggers the panic you are seeing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 9 15:30:58 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Nov 2015 15:30:58 -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.d0dda570e9d48c6b5a3810297ce0f2a1@haskell.org> #10870: PPC.Ppr: Shift by 32 bits is not allowed. ---------------------------------------+---------------------------------- Reporter: nomeata | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.3 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 Rev(s): Phab:D1322 Wiki Page: | ---------------------------------------+---------------------------------- Changes (by trommler): * Attachment "0001-PPC-nativeGen-fix-shift-right-arithmetic-31-bit.patch" removed. ...and for arithmetic right shifts -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 9 15:30:58 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Nov 2015 15:30:58 -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.42658cccd8b4e8b07f433c4cf9e14144@haskell.org> #10870: PPC.Ppr: Shift by 32 bits is not allowed. ---------------------------------------+---------------------------------- Reporter: nomeata | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.3 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 Rev(s): Phab:D1322 Wiki Page: | ---------------------------------------+---------------------------------- Changes (by trommler): * Attachment "0001-PPC-nativeGen-fix-shift-right-arithmetic-31-bit.patch" added. ...and for arithmetic right shifts -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 9 15:32:57 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Nov 2015 15:32: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.d36f2f25c76df481aaa4a2ccb48731ad@haskell.org> #10870: PPC.Ppr: Shift by 32 bits is not allowed. ---------------------------------------+---------------------------------- Reporter: nomeata | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.3 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 Rev(s): Phab:D1322 Wiki Page: | ---------------------------------------+---------------------------------- Changes (by trommler): * Attachment "0001-PPC-nativeGen-fix-shift-right-arithmetic-31-bit.patch" added. ...and for arithmetic right shifts -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 9 15:32:57 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Nov 2015 15:32: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.42658cccd8b4e8b07f433c4cf9e14144@haskell.org> #10870: PPC.Ppr: Shift by 32 bits is not allowed. ---------------------------------------+---------------------------------- Reporter: nomeata | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.3 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 Rev(s): Phab:D1322 Wiki Page: | ---------------------------------------+---------------------------------- Changes (by trommler): * Attachment "0001-PPC-nativeGen-fix-shift-right-arithmetic-31-bit.patch" removed. ...and for arithmetic right shifts -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 9 15:35:54 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Nov 2015 15:35:54 -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.fcaee78b4bcaf8ec1b0a4080b200a1f3@haskell.org> #10870: PPC.Ppr: Shift by 32 bits is not allowed. ---------------------------------------+---------------------------------- Reporter: nomeata | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.3 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 Rev(s): Phab:D1322 Wiki Page: | ---------------------------------------+---------------------------------- Comment (by nomeata): Thanks! I almost kicked off a full ghc package upload to Debian, but I better wait until you have reached the final version of your patch. (Interesting that trac does not display your updates to the patch, this might be very confusion when people talk about different instances of a patch.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 9 15:44:17 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Nov 2015 15:44:17 -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.5c357fc2d68a7aaa6a998016e984c0db@haskell.org> #10870: PPC.Ppr: Shift by 32 bits is not allowed. ---------------------------------------+---------------------------------- Reporter: nomeata | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.3 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 Rev(s): Phab:D1322 Wiki Page: | ---------------------------------------+---------------------------------- Comment (by trommler): Replying to [comment:14 nomeata]: > Thanks! I almost kicked off a full ghc package upload to Debian, but I better wait until you have reached the final version of your patch. (Interesting that trac does not display your updates to the patch, this might be very confusion when people talk about different instances of a patch.) Sorry about that! I forgot to refresh the patch and uploaded an old version that did not even compile three times. I used the replace attachment option for each upload. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 9 15:46:14 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Nov 2015 15:46:14 -0000 Subject: [GHC] #11066: Inacessible branch should be warning - otherwise breaks type soundness? In-Reply-To: <047.0785946e31f05741dc32414264d84d16@haskell.org> References: <047.0785946e31f05741dc32414264d84d16@haskell.org> Message-ID: <062.12ee8d02f8067c04f8de094545344dc8@haskell.org> #11066: Inacessible branch should be warning - otherwise breaks type soundness? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.2 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:D1454 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * differential: => Phab:D1454 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 9 16:04:04 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Nov 2015 16:04:04 -0000 Subject: [GHC] #11074: invalid fixup in runtime linker In-Reply-To: <044.8a0aa9f1d3d6c6f83e1369f687f42004@haskell.org> References: <044.8a0aa9f1d3d6c6f83e1369f687f42004@haskell.org> Message-ID: <059.de13937d505e627828ecbf771f99aa2a@haskell.org> #11074: invalid fixup in runtime linker -------------------------------------+------------------------------------- Reporter: Qinka | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: invalid fixup | in runtime linker Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: Phyx (added) * priority: highest => normal Comment: Qinka: can you describe more precisely what you are trying to accomplish. You mention "install some kinds of PostgreSQL's packages", which sounds very vague to me. See wiki:ReportABug#Fulldescription:whatinformationtoprovideinthebodyofyourbugreport. Downgrading to priority=normal, because there is no evidence that this is a regression from earlier GHC releases. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 9 16:06:06 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Nov 2015 16:06:06 -0000 Subject: [GHC] #11068: Make Generic/Generic1 methods inlinable In-Reply-To: <044.2644399b8f2d6a8d61669300e8f810a3@haskell.org> References: <044.2644399b8f2d6a8d61669300e8f810a3@haskell.org> Message-ID: <059.6d70ae423ff6500b1796808c503e73fa@haskell.org> #11068: Make Generic/Generic1 methods inlinable -------------------------------------+------------------------------------- Reporter: glguy | 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 Rev(s): Phab:D1447 Wiki Page: | -------------------------------------+------------------------------------- Comment (by glguy): Hi Simon, The problem I'm working on is indeed related to Jos?'s work. I'm solving the problem that GHC doesn't use Appliative and Functor laws to rewrite code using Haskell instead of rewrite rules. I "run" the code at a lifted version of the desired type `f` that uses the Applicative laws to rewrite a term to be left associated in the `<*>`s and using a single `<$>`. Using this technique allows me to derive efficient code that is generic in terms of Functor and Applicative on a case by case basis rather than with global rules. {{{ badTraversal :: Traversal' (Int,Int,Int) Int badTraversal f (x,y,z) = pure (\x' (y',z') -> (x',y',z')) <*> f x <*> ((,) <$> f y <*> f z) goodTraversal :: Traversal' (Int,Int,Int) Int goodTraversal = boggling badTraversal -- generated core is roughly: \f (x,y,z) -> (,,) <$> f x <*> f y <*> f z }}} The code from `badTraversal` could have been easily generated using GHC.Generics, but the efficient version can be recovered using the `boggling` operation defined in repository mentioned above. As far as my request to add the inline pragma, I think I might have misunderstood what GHC was doing. My goal was to ensure that from/to/from1/to1 would be able to inline across module boundaries even when their definitions were large due to the type being large. However after revisiting my test case I was struggling to reproduce that the change fixed anything, so I closed the change request (but forgot to change this ticket) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 9 16:30:25 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Nov 2015 16:30:25 -0000 Subject: [GHC] #11050: [bug] ModOrigin: hidden module redefined In-Reply-To: <049.f4e3e81343960e7ba9d67c8e78ae8ab2@haskell.org> References: <049.f4e3e81343960e7ba9d67c8e78ae8ab2@haskell.org> Message-ID: <064.992e5b9b723e506d3eede1156d28aa75@haskell.org> #11050: [bug] ModOrigin: hidden module redefined -------------------------------------+------------------------------------- Reporter: codeonwort | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): I opened https://github.com/valderman/haste-compiler/issues/349 for this. I don't know for sure if it is a bug in haste or in ghc/ghc-pkg (maybe ghc-pkg should reject such packages from being installed at all, since ghc chokes on them anyway?). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 9 16:45:32 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Nov 2015 16:45:32 -0000 Subject: [GHC] #11069: :cd in GHCi unloads modules In-Reply-To: <046.f148df7c02b3f284ee9bbb87ae5f7b67@haskell.org> References: <046.f148df7c02b3f284ee9bbb87ae5f7b67@haskell.org> Message-ID: <061.7c0d447289ff914edfb022e38ebae33a@haskell.org> #11069: :cd in GHCi unloads modules -------------------------------------+------------------------------------- Reporter: mgsloan | Owner: Type: bug | Status: new Priority: low | Milestone: Component: GHCi | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:1 thomie]: > > How about removing any dependency in GHC on the current working directory, and instead store it when the session is initialized? > > Go ahead. GHCi is just as unmaintained as hpc, so it's all yours to fix. Whoa. I don't think of GHCi as unmaintained. The debugger in GHCi is regrettably unmaintained. But the rest of it gets active work, no? And I don't agree with the proposed change. I may be an exception to the normal Haskell workflow, but I do most of my work in GHCi without reference to a cabalized package. (Usually, I'm just testing different constructs, not building a project intended for release.) I use `:cd` and expect it to change my working directory used for finding modules. If I understand correctly, the proposed change would eliminate this workflow. (I do find it annoying that all my modules get unloaded when I move directories, as that's not always my intent.) So I think a bit of a larger discussion is in order before making this breaking change. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 9 18:32:40 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Nov 2015 18:32:40 -0000 Subject: [GHC] #11070: Type-level arithmetic of sized-types has weaker inference power than in 7.8 In-Reply-To: <045.53eceb5327c44565612d8182117e7c77@haskell.org> References: <045.53eceb5327c44565612d8182117e7c77@haskell.org> Message-ID: <060.8c972ed9bcab46f0b1daed9082294528@haskell.org> #11070: Type-level arithmetic of sized-types has weaker inference power than in 7.8 -------------------------------------+------------------------------------- Reporter: cactus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I confirm this behavior. I'd love a second opinion, but I think this sort of trickery lies at the edge of what the solver can handle. Specifically, here is my analysis: 1. We're typechecking the body of `bar`, `[((), B)] &* foo`, at type `[(((), ()), B X2)]` 2. The type of `(&*)` tells us that `[((), B)]` has type `[(a, B n)]` for some `a` and `n`. Thus, `a` is `()`. 3. Similarly, we know that `foo` must have type `[(b, B n')]`. Thus, `b` is `()` and `n'` is `X1`, where that last fact comes from the signature on `foo`. 4. We must show that `ADD n' n` is `X2` (from `bar`'s signature). Rewriting, this is {{{ [W] c1 :: ADD X1 n ~ X2 }}} where `n` is a unification variable. 5. The type of `(&*)` also gives us {{{ [W] c2 :: n ~ SUB (ADD X1 n) X1 [W] c3 :: X1 ~ SUB (ADD X1 n) n }}} Now, here I think I see why GHC 7.8 and GHC 7.10 differ. 7.8 could rewrite wanteds with wanteds. That is, it could use `c2` or `c3` to try to solve `c1`. But 7.10 doesn't do this, because rewriting wanteds with wanteds gives terrible error messages sometimes. (To be fair, I don't actually see how this works out, after some effort. But I trust it does.) Is this a use case for rewriting wanteds with wanteds? Perhaps. But it also seems to require a non-terminating rewrite system, where `n` is rewritten with something involving `n`. I'm surprised that happened in either GHC version. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 9 18:37:52 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Nov 2015 18:37:52 -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.9d255f46e9ac3ca0402bf364683d2658@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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:14 simonpj]: > But how could they be exported anyway? You can't mention it in the export list, presumably. But you can. :( {{{ {-# LANGUAGE TemplateHaskell #-} module TestTH ( bar ) where import Language.Haskell.TH $( do bar <- newName "bar" return [ValD (VarP bar) (NormalB (ConE 'True)) []] ) }}} They also get exported with an omitted export list. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 9 18:45:52 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Nov 2015 18:45:52 -0000 Subject: [GHC] #11007: Type family injectivity annotations ignored in hs-boot files In-Reply-To: <047.26e4b74bfa5db1c5fbbc0697a9084694@haskell.org> References: <047.26e4b74bfa5db1c5fbbc0697a9084694@haskell.org> Message-ID: <062.acab19f6d704af038c049485e8c5f966@haskell.org> #11007: Type family injectivity annotations ignored in hs-boot files -------------------------------------+------------------------------------- Reporter: goldfire | Owner: jstolarek Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T6018 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1453 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Will do. Thanks for the fix! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 9 19:03:19 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Nov 2015 19:03:19 -0000 Subject: [GHC] #11074: invalid fixup in runtime linker In-Reply-To: <044.8a0aa9f1d3d6c6f83e1369f687f42004@haskell.org> References: <044.8a0aa9f1d3d6c6f83e1369f687f42004@haskell.org> Message-ID: <059.6078a90fe842f2b813962a5cf209bb26@haskell.org> #11074: invalid fixup in runtime linker -------------------------------------+------------------------------------- Reporter: Qinka | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: invalid fixup | in runtime linker Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): I think this is a duplicate of #10563 and should be fixed by #9907. Should be working in 7.10.3. Qinka: if you can provide instructions to reproduce it like @thomie mentioned I can confirm if it's fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 9 19:04:03 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Nov 2015 19:04:03 -0000 Subject: [GHC] #11074: invalid fixup in runtime linker In-Reply-To: <044.8a0aa9f1d3d6c6f83e1369f687f42004@haskell.org> References: <044.8a0aa9f1d3d6c6f83e1369f687f42004@haskell.org> Message-ID: <059.c00cc4a1d57de482c2f80970bd150948@haskell.org> #11074: invalid fixup in runtime linker -------------------------------------+------------------------------------- Reporter: Qinka | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: invalid fixup | in runtime linker Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * cc: Phyx (removed) * cc: Phyx- (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 9 19:11:47 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Nov 2015 19:11:47 -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.95901795dd7bcf202155e3dcfe3cc357@haskell.org> #10870: PPC.Ppr: Shift by 32 bits is not allowed. ---------------------------------------+---------------------------------- Reporter: nomeata | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.3 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 Rev(s): Phab:D1322 Wiki Page: | ---------------------------------------+---------------------------------- Changes (by trommler): * status: infoneeded => merge Comment: Replying to [comment:15 trommler]: > Replying to [comment:14 nomeata]: > > Thanks! I almost kicked off a full ghc package upload to Debian, but I better wait until you have reached the final version of your patch. (Interesting that trac does not display your updates to the patch, this might be very confusion when people talk about different instances of a patch.) > Sorry about that! I forgot to refresh the patch and uploaded an old version that did not even compile > three times. I used the replace attachment option for each upload. The patch is good. I verified on openSUSE build service. I looked at HEAD again and the code there is not correct for negative numbers. I will post a fix for HEAD on Phab shortly (I am still validating). Meanwhile `0001-PPC-nativeGen-fix-shift-right-arithmetic-31-bit.patch` can be merged into ghc-7.10. Once merged, please reopen, set milestone to 8.0.1 and assign to me (@trommler). Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 9 19:37:27 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Nov 2015 19:37:27 -0000 Subject: [GHC] #3242: GHCi linker does not correctly locate static libraries under Windows In-Reply-To: <045.426dc6319f98492c5b511466045bc0b5@haskell.org> References: <045.426dc6319f98492c5b511466045bc0b5@haskell.org> Message-ID: <060.53e7bc2684896dd2e66709689d977b41@haskell.org> #3242: GHCi linker does not correctly locate static libraries under Windows ---------------------------------+---------------------------------------- Reporter: jeffz1 | Owner: Phyx- Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.4.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: T3242 Blocked By: 3658 | Blocking: Related Tickets: #7097 | Differential Rev(s): Phab:D1455 Wiki Page: | ---------------------------------+---------------------------------------- Changes (by Phyx-): * status: new => patch * testcase: => T3242 * differential: => Phab:D1455 * architecture: x86 => Unknown/Multiple -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 9 20:24:05 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Nov 2015 20:24:05 -0000 Subject: [GHC] #4863: TH crashes if you reify the Name of a dfun In-Reply-To: <044.713ffb35d11ce342f1ff0a491439d522@haskell.org> References: <044.713ffb35d11ce342f1ff0a491439d522@haskell.org> Message-ID: <059.903f6e86cc9c5911588420305070e46e@haskell.org> #4863: TH crashes if you reify the Name of a dfun -------------------------------------+------------------------------------- Reporter: guest | Owner: simonpj Type: bug | Status: closed Priority: low | Milestone: ? Component: Template Haskell | Version: 7.0.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => fixed Comment: I agree. This ticket has been fixed over the course of time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 9 20:45:17 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Nov 2015 20:45:17 -0000 Subject: [GHC] #10776: DataKinds promotion of String -> Symbol and Natural -> Nat In-Reply-To: <048.67491201a04ddd5c5f8addf4fce96596@haskell.org> References: <048.67491201a04ddd5c5f8addf4fce96596@haskell.org> Message-ID: <063.4d7e88e9665f1bb56ea68267cf8f4048@haskell.org> #10776: DataKinds promotion of String -> Symbol and Natural -> Nat -------------------------------------+------------------------------------- Reporter: htebalaka | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: DataKinds Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dmcclean): A hearty amen on this one, especially unifying `Natural` with `Nat`. Regarding the `String` objection perhaps it would be better to merely flesh out `Symbol` at the term level? With an `IsString` instance and so forth? Because as mentioned unifying it with `String` is problematic since `String` is a type synonym for a list of characters. I also agree with Richard's comments regarding the desirability of type- level literals of all stripes (or at least other stripes). I'm not sure if floating-point numbers or characters specifically are useful, but integers and rationals most definitely are of use to the `dimensional` library. We have home-brewed ones, but it is a lot of machinery, isn't interoperable with the few other flavors of home-brewed ones on the market, and isn't the lifted version of `Rational` or `Integer` so you can't use the lifted kinds that go with the types of term-level structures that include rational or integers. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 9 20:45:45 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Nov 2015 20:45:45 -0000 Subject: [GHC] #10776: DataKinds promotion of String -> Symbol and Natural -> Nat In-Reply-To: <048.67491201a04ddd5c5f8addf4fce96596@haskell.org> References: <048.67491201a04ddd5c5f8addf4fce96596@haskell.org> Message-ID: <063.91b23477e90ecffa2b0e74222eb6068c@haskell.org> #10776: DataKinds promotion of String -> Symbol and Natural -> Nat -------------------------------------+------------------------------------- Reporter: htebalaka | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: DataKinds Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dmcclean): * cc: dmcclean (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 9 22:41:40 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Nov 2015 22:41:40 -0000 Subject: [GHC] #4863: TH crashes if you reify the Name of a dfun In-Reply-To: <044.713ffb35d11ce342f1ff0a491439d522@haskell.org> References: <044.713ffb35d11ce342f1ff0a491439d522@haskell.org> Message-ID: <059.0609f4729581c42876bf01fe0035fe8e@haskell.org> #4863: TH crashes if you reify the Name of a dfun -------------------------------------+------------------------------------- Reporter: guest | Owner: simonpj Type: bug | Status: closed Priority: low | Milestone: ? Component: Template Haskell | Version: 7.0.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Could someone add a regression test? Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 9 23:02:05 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Nov 2015 23:02:05 -0000 Subject: [GHC] #11055: GHC 7.8.4 crash on ARM while building Stack 0.1.7 In-Reply-To: <047.fb2a0236ca36949d692f2910f33633d4@haskell.org> References: <047.fb2a0236ca36949d692f2910f33633d4@haskell.org> Message-ID: <062.478ffc08a9ac5af916840e09ecb65fa5@haskell.org> #11055: GHC 7.8.4 crash on ARM while building Stack 0.1.7 ---------------------------------------+---------------------------------- Reporter: Lokathor | Owner: Type: bug | Status: infoneeded 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): Wiki Page: | ---------------------------------------+---------------------------------- Comment (by Lokathor): Alright, I guess the downloads directories are made before they're filled, and they're filled based on platform popularity as well. At the time of this writing, the 7.10.3-rc1 directory has an ARM build, the 7.10.3-rc2 does not, and the 7.10.3-rc3 directory is entirely empty. Using 7.10.3-rc1 I was able to build stack 0.1.7, and it seems to work. I also tried out another file that would always crash GHCi (but not GHC) in version 7.8.4, and using version 7.10.3-rc1 it did not crash ghci. I did however get a warning I've never seen before during the linking, about missing mapping symbols. I built another project just to be sure and it gave the same thing, all the messages are basically {{{ /usr/bin/ld.gold: warning: cannot scan executable section 1 of /home/daniel/dev/haizod/.cabal-sandbox/lib/arm-linux- ghc-7.10.2.20151030/netwo_EsGuXlNmVtd2gsY9SXPuBb/libHSnetwork- simple-0.4.0.4-G2iPUu3gNst2JPWvkDR4bl.a(TCP.o) for Cortex-A8 erratum because it has no mapping symbols. }}} Things *seem* to run fine despite the warning though. I'm going to use the newly built stack to rebuild stack itself, which should give it a fair shake, but it takes like a day to build all the dependencies and the binary together, so I'll get back on results from that tomorrow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 9 23:16:26 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Nov 2015 23:16:26 -0000 Subject: [GHC] #4863: TH crashes if you reify the Name of a dfun In-Reply-To: <044.713ffb35d11ce342f1ff0a491439d522@haskell.org> References: <044.713ffb35d11ce342f1ff0a491439d522@haskell.org> Message-ID: <059.763acbe0ee7221f877144cfbed4c1455@haskell.org> #4863: TH crashes if you reify the Name of a dfun -------------------------------------+------------------------------------- Reporter: guest | Owner: simonpj Type: bug | Status: closed Priority: low | Milestone: ? Component: Template Haskell | Version: 7.0.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): There's no need for one. This ticket had to do with `Name`s appearing in the TH AST where they no longer appear. Despite the ticket title, the underlying problem was a design goof, not an implementation one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 10 01:19:08 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Nov 2015 01:19:08 -0000 Subject: [GHC] #11075: Confusing parallel spark behaviour with safe FFI calls Message-ID: <045.aa23e7aefeffbe70dc2426bdbd5d297f@haskell.org> #11075: Confusing parallel spark behaviour with safe FFI calls -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 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 Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is a tricky problem, and I don't see any easy solution, but here it is for the sake of documenting and tracking... When we create a bunch of 'par' sparks, e.g. via a strategy, the expected behaviour is that we get one thread per core that will churn through those sparks, one by one. The one by one is important, each core/cap/hec is only actively evaluating one of these sparks at a time. It's not like we have a thread per spark and they're all evaluating in parallel. The parallelism is limited to the core count (well, cap/hec). However, if each of these sparks makes a safe FFI call then the one-by-one behaviour is broken. Instead we get an OS thread per spark all running concurrently. If one looks at the mechanisms in detail one can see why this happens, but the overall effect can be disastrous for performance. If we have a small number of cores e.g. 8 and a large number of sparks e.g. 1024, then spawning 1024 OS threads each of which has plenty of work to do is not a recipe for good performance. The OS will share the time fairly which means each thread will get terrible CPU cache utilisation. Think of something like big numerical calculations where the cache utilisation is critical: running 100s of OS threads per core doing numerical calculations will be much worse than running one thread that churns through the calculations sequentially. So why does this happen? Well, when a cap is idle the cap's scheduler checks if it has any sparks in its spark pool, or in other cap's spark pools. If there are sparks available it grabs one and starts a Haskell thread to run it. Now the Haskell thread makes a safe FFI call. That means the Haskell thread is put to sleep while the foreign call runs in a new OS thread. But this now means that the scheduler thinks that this cap is idle again (there are no runnable Haskell threads), so it grabs another spark. And so another OS thread gets made to run the FFI call. And again and again, until we've converted all the sparks and forked off loads of OS threads to run these FFI calls. The problem is that the scheduler cannot tell the difference between a safe FFI call that is blocking and taking no CPU time (like waiting on network IO) vs a safe FFI call that is not blocking and is fully utilising the CPU (like big numerical calculations). In the latter case we would really like to say that the cap is not really idle, we don't need to create more work to do. In the former case it's important to create more work to do. But there's no easy way to tell the difference between these two cases, so this is a hard problem to fix. If a programmer knows that this is what is going on then they can work around the problem by being very careful with the number of sparks they make (kind of losing some of the benefits of sparks) or they can make all the expensive FFI calls unsafe (which can be tricky when using reusable FFI binding libs). But in practice most GHC users will never figure out that this is what is happening (plausibly it might be possible from looking at the threadscope view very careful). So that's the conundrum: a problem that users will find hard to identify, and no easy automatic solution. Ho hum. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 10 01:32:36 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Nov 2015 01:32:36 -0000 Subject: [GHC] #11075: Confusing parallel spark behaviour with safe FFI calls In-Reply-To: <045.aa23e7aefeffbe70dc2426bdbd5d297f@haskell.org> References: <045.aa23e7aefeffbe70dc2426bdbd5d297f@haskell.org> Message-ID: <060.7c3d92f46e4253551a4127a5896ee1ae@haskell.org> #11075: Confusing parallel spark behaviour with safe FFI calls -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by duncan): So thoughtpolice has a very sensible suggestion: annotate this info in the FFI call. That is, rather than just safe and unsafe, we can add an extra bit to say it's safe but cpu intensive. Then the scheduler could keep note of this when it makes the new thread for the FFI call. When there are outstanding cpu intensive C calls that this cap is waiting on, then don't consider the cap idle for the purposes of grabbing and converting new sparks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 10 01:35:23 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Nov 2015 01:35:23 -0000 Subject: [GHC] #11075: Confusing parallel spark behaviour with safe FFI calls In-Reply-To: <045.aa23e7aefeffbe70dc2426bdbd5d297f@haskell.org> References: <045.aa23e7aefeffbe70dc2426bdbd5d297f@haskell.org> Message-ID: <060.5921c48051f55b186afec3cd388674ed@haskell.org> #11075: Confusing parallel spark behaviour with safe FFI calls -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * cc: thoughtpolice (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 10 02:04:11 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Nov 2015 02:04:11 -0000 Subject: [GHC] #11075: Confusing parallel spark behaviour with safe FFI calls In-Reply-To: <045.aa23e7aefeffbe70dc2426bdbd5d297f@haskell.org> References: <045.aa23e7aefeffbe70dc2426bdbd5d297f@haskell.org> Message-ID: <060.c140c4801ac312ecddfd67e284543814@haskell.org> #11075: Confusing parallel spark behaviour with safe FFI calls -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): I would totally use this for some of my ffi bindings, because they do quite a bit of compute! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 10 05:47:43 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Nov 2015 05:47:43 -0000 Subject: [GHC] #3021: A way to programmatically insert marks into heap profiling output In-Reply-To: <043.8f6f7af4d3cf139bc012e761a76247cb@haskell.org> References: <043.8f6f7af4d3cf139bc012e761a76247cb@haskell.org> Message-ID: <058.59807f7324c7abdea644b992af09ab14@haskell.org> #3021: A way to programmatically insert marks into heap profiling output -------------------------------------+------------------------------------- Reporter: SamB | Owner: Type: feature request | Status: new Priority: normal | Milestone: ? Component: Profiling | Version: 6.10.1 Resolution: | Keywords: profiling Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by maoe): * cc: maoe (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 10 06:38:57 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Nov 2015 06:38:57 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.e57afcb5baef666fa4658e3c3df14310@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 Rev(s): Phab:D202 #10833 | -------------------------------------+------------------------------------- Comment (by Jan Stolarek ): In [changeset:"3cfe60aebb9de2a1d897a111f779eacb6614b7cc/ghc" 3cfe60a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3cfe60aebb9de2a1d897a111f779eacb6614b7cc" Abstract TFs can have injectivity information Summary: For abstract type families we incorrectly rejected their injectivity annotation. Fixes #11007. Test Plan: #6018 Reviewers: goldfire, austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1453 GHC Trac Issues: #11007 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 10 06:38:58 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Nov 2015 06:38:58 -0000 Subject: [GHC] #11007: Type family injectivity annotations ignored in hs-boot files In-Reply-To: <047.26e4b74bfa5db1c5fbbc0697a9084694@haskell.org> References: <047.26e4b74bfa5db1c5fbbc0697a9084694@haskell.org> Message-ID: <062.986444c199139cea6ea4c4ef0f3966c6@haskell.org> #11007: Type family injectivity annotations ignored in hs-boot files -------------------------------------+------------------------------------- Reporter: goldfire | Owner: jstolarek Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T6018 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1453 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Jan Stolarek ): In [changeset:"3cfe60aebb9de2a1d897a111f779eacb6614b7cc/ghc" 3cfe60a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3cfe60aebb9de2a1d897a111f779eacb6614b7cc" Abstract TFs can have injectivity information Summary: For abstract type families we incorrectly rejected their injectivity annotation. Fixes #11007. Test Plan: #6018 Reviewers: goldfire, austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1453 GHC Trac Issues: #11007 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 10 06:39:23 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Nov 2015 06:39:23 -0000 Subject: [GHC] #11007: Type family injectivity annotations ignored in hs-boot files In-Reply-To: <047.26e4b74bfa5db1c5fbbc0697a9084694@haskell.org> References: <047.26e4b74bfa5db1c5fbbc0697a9084694@haskell.org> Message-ID: <062.b5d7406dfb74f63d2d3ae0dcbdc55721@haskell.org> #11007: Type family injectivity annotations ignored in hs-boot files -------------------------------------+------------------------------------- Reporter: goldfire | Owner: jstolarek Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.11 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T6018 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1453 Wiki Page: | -------------------------------------+------------------------------------- Changes (by jstolarek): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 10 08:13:01 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Nov 2015 08:13:01 -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.89c8ecdb370f5ce88671e5b3e3cffdbb@haskell.org> #10870: PPC.Ppr: Shift by 32 bits is not allowed. ---------------------------------------+---------------------------------- Reporter: nomeata | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.3 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 Rev(s): Phab:D1322 Wiki Page: | ---------------------------------------+---------------------------------- Comment (by nomeata): Yay, vector-algorithms built now on powerpc! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 10 08:38:24 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Nov 2015 08:38:24 -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.a585a2f1b30d1143309962d03c825703@haskell.org> #10870: PPC.Ppr: Shift by 32 bits is not allowed. ---------------------------------------+---------------------------------- Reporter: nomeata | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.3 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 Rev(s): Phab:D1322 Wiki Page: | ---------------------------------------+---------------------------------- Comment (by trommler): Replying to [comment:17 nomeata]: > Yay, vector-algorithms built now on powerpc! Excellent, I built on openSUSE build service, too. vector-algorithms builds fine but the testsuite is stuck forever on x86, x86_64, and powerpc. FWIW: powerpc64[le], is also stuck, but my compiler is patched with a back port of the NCG from 8.0. Do you see that, too? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 10 08:40:27 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Nov 2015 08:40:27 -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.e3f3d852226a6c709cc2fbabed17ab28@haskell.org> #10870: PPC.Ppr: Shift by 32 bits is not allowed. ---------------------------------------+---------------------------------- Reporter: nomeata | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.3 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 Rev(s): Phab:D1322 Wiki Page: | ---------------------------------------+---------------------------------- Comment (by nomeata): No, passes everywhere. But given the large output of the test suite, this sounds like https://github.com/haskell/cabal/issues/2398. Try to add the patch from https://github.com/haskell/cabal/pull/2913 and add `--show- details=direct`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 10 08:53:12 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Nov 2015 08:53:12 -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.4ca85f4414da0fdc3dfdc5fb4abecfc2@haskell.org> #10828: TH could do a better job of representing GADTs -------------------------------------+------------------------------------- Reporter: spinda | Owner: jstolarek Type: feature request | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jstolarek): * owner: => jstolarek Comment: I can work on implementing that, but I have one question: > I think, in light of comment:5, we should add proper GADT support in TH. Why "in light of comment:5"? I read through #10447 and I saw this example by Simon: {{{#!hs data T1 a where MkT1 :: (a~Int) => a -> T1 a data T2 a where MkT2 :: Int -> T2 Int data T3 a where MkT3 :: (a~Int) => a -> T3 Int }}} All these declarations can be represented in TH: {{{#!hs data T1 a = a ~ Int => MkT1 a data T2 a = a ~ Int => MkT2 Int data T3 a = forall b. (a ~ Int, b ~ Int) => MkT3 b }}} It is possible to automatically derive `Foldable` for all three declarations `T1`, `T2` and `T3`, both in GADT form as well as in the standard form given above, so `DerivingFoldable` makes no distinction between these three declarations. Are there other declarations where `Foldable` distinguishes the two forms? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 10 10:11:40 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Nov 2015 10:11:40 -0000 Subject: [GHC] #3589: Recompilation checker doesn't take into account CPP headers In-Reply-To: <047.5d4e10ff362a5a53fb60efa7fea2fd88@haskell.org> References: <047.5d4e10ff362a5a53fb60efa7fea2fd88@haskell.org> Message-ID: <062.31ac5c7259f72fcaf1f112c77586d4dc@haskell.org> #3589: Recompilation checker doesn't take into account CPP headers -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.4.1 Component: Compiler | Version: 6.10.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | driver/recomp011/recomp011 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * testcase: => driver/recomp011/recomp011 Comment: In commit 5262def14ba7b8b6c8d1aea6860226da65cc4248: {{{ Author: Simon Marlow Date: Fri Nov 18 12:40:47 2011 +0000 test for #3589 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 10 11:40:47 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Nov 2015 11:40:47 -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.646f1f8c5142d43b72c676842dea04bc@haskell.org> #10828: TH could do a better job of representing GADTs -------------------------------------+------------------------------------- Reporter: spinda | Owner: jstolarek Type: feature request | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jstolarek): My proposal would be to add the following constructor to `Con` data type: {{{#!hs | GadtC Name [StrictType] [Type] }}} where the last field stores list of constructor indices. Once we have this new constructor I would modify `DsMera` and `Convert` accordingly. Most importantly, GADT declarations would be now translated to use this new constructor instead of encoding that uses `ForallC` and `NormalC`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 10 14:20:29 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Nov 2015 14:20:29 -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.adc2b775b1a57cb52669faa0159323eb@haskell.org> #10828: TH could do a better job of representing GADTs -------------------------------------+------------------------------------- Reporter: spinda | Owner: jstolarek Type: feature request | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:8 jstolarek]: > It is possible to automatically derive `Foldable` for all three declarations `T1`, `T2` and `T3`, both in GADT form as well as in the standard form given above, so `DerivingFoldable` makes no distinction between these three declarations. I agree that deriving `Foldable` works for all of them, but does it do the same thing? I would expect not, from the commentary on #10447. Your `GadtC` is missing a place for a `[TyVarBndr]` (to store the quantified type variables, both universals and existentials) and a `Cxt` to store any extra constraints. It also forbids record syntax, but maybe we can live without GADT record syntax. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 10 14:30:57 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Nov 2015 14:30:57 -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.1417d28a4d46e1d3f956be588b8aa56a@haskell.org> #10828: TH could do a better job of representing GADTs -------------------------------------+------------------------------------- Reporter: spinda | Owner: jstolarek Type: feature request | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jstolarek): > Your `GadtC` is missing a place for a `[TyVarBndr]` (to store the quantified type variables, both universals and existentials) and a `Cxt` to store any extra constraints. My intention was to nest `GadtC` inside `ForallC`. Is there any reason why this wouldn't work? > It also forbids record syntax, but maybe we can live without GADT record syntax. Ok, I haven't thought about that one. TBH I think I have never used (or seen) GADTs with record syntax. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 10 14:36:23 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Nov 2015 14:36:23 -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.bfc274e74a7bb713f35a651bc9d7af9c@haskell.org> #10828: TH could do a better job of representing GADTs -------------------------------------+------------------------------------- Reporter: spinda | Owner: jstolarek Type: feature request | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:11 jstolarek]: > My intention was to nest `GadtC` inside `ForallC`. Is there any reason why this wouldn't work? Good point. That would work well. The documentation should make clear that, unlike other constructor forms, GADT constructors do ''not'' have the type variables from the declaration head in scope. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 10 14:46:47 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Nov 2015 14:46:47 -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.c5835ba0c8b884d061c5c127ae28615f@haskell.org> #10828: TH could do a better job of representing GADTs -------------------------------------+------------------------------------- Reporter: spinda | Owner: jstolarek Type: feature request | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jstolarek): Replying to [comment:12 goldfire]: > The documentation should make clear that, unlike other constructor forms, GADT constructors do ''not'' have the type variables from the declaration head in scope. Does that make a difference for TH representation (ie. `GadtC` data type)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 10 15:48:49 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Nov 2015 15:48:49 -0000 Subject: [GHC] #7983: Bug in hsc2hs --cross-safe In-Reply-To: <049.3ff36c949c6061d8d14e6939f732b877@haskell.org> References: <049.3ff36c949c6061d8d14e6939f732b877@haskell.org> Message-ID: <064.e76cf4c6b574be143349d86f90a53515@haskell.org> #7983: Bug in hsc2hs --cross-safe -------------------------------------+------------------------------------- Reporter: singpolyma | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: hsc2hs | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): This is caused by a regression in GCC from gcc-4.4 to gcc-4.6: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46028 {{{ $ cat Test_hsc_test0.c void _hsc2hs_test1() { static int test_array[(89.) > 0 ? 2 : 1]; } $ /usr/bin/gcc-4.4 -c ./Test_hsc_test0.c $ /usr/bin/gcc-4.6 -c ./Test_hsc_test0.c ./Test_hsc_test0.c: In function ?_hsc2hs_test1?: ./Test_hsc_test0.c:3:16: error: storage size of ?test_array? isn?t constant }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 10 16:05:50 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Nov 2015 16:05:50 -0000 Subject: [GHC] #11071: "Not in scope" errors should be more informative for qualified names. In-Reply-To: <047.e970b72d66ebf0753d36739a65af99a0@haskell.org> References: <047.e970b72d66ebf0753d36739a65af99a0@haskell.org> Message-ID: <062.fb8d032ac7e445d9a14babac20c6aa4e@haskell.org> #11071: "Not in scope" errors should be more informative for qualified names. -------------------------------------+------------------------------------- Reporter: mojojojo | Owner: nomeata 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * owner: => nomeata Old description: > E.g., if I have something like `Maybe.maybeToList` in a module, which > does not have such an import, I get the following error: > > Not in scope: ?Maybe.maybeToList? > > Which leads the user to conclude that the `Maybe` namespace does not > contain the `maybeToList` element, instead of informing that the `Maybe` > namespace is not imported altogether instead. New description: E.g., if I have something like `Maybe.maybeToList` in a module, which does not have such an import, I get the following error: Not in scope: ?Maybe.maybeToList? Which leads the user to conclude that the `Maybe` namespace does not contain the `maybeToList` element, instead of informing that the `Maybe` namespace is not imported altogether instead -- Comment: Looking at the code right now. The first case (`No Module named Maybe is imported.`) is pretty easy. The other cases are actually quite tricky. The semantics of import lists is rather involved, and the code in `filterImports` in `RnNames` is quite terse. Maybe it is better to simply remember the `mi_exports` of all modules, look up the name there, and if it is found, then conclude that it was the fault of the import list. OTOH, a perfect solution would actually suggest to add `D3` to the `C(D1,D2,D3)` in `import Foo (C(D1,D2))` if a data constructor `Foo.D3` is out of scope. I?ll see how far I get... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 10 16:21:23 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Nov 2015 16:21:23 -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.3368fbb04880d2e4c411bc513da77d63@haskell.org> #10828: TH could do a better job of representing GADTs -------------------------------------+------------------------------------- Reporter: spinda | Owner: jstolarek Type: feature request | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): No. But it does affect the code in Convert and !DsMeta. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 10 16:22:15 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Nov 2015 16:22:15 -0000 Subject: [GHC] #10462: GHCi doesn't work Any and missing RealWorld foreign prim imports In-Reply-To: <045.272515eb6529b0f69e6fb29bb854188b@haskell.org> References: <045.272515eb6529b0f69e6fb29bb854188b@haskell.org> Message-ID: <060.740651fe0f6f52bde1492a7c5ac0cd00@haskell.org> #10462: GHCi doesn't work Any and missing RealWorld foreign prim imports -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: patch Priority: low | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: prog014 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D1458 Wiki Page: | -------------------------------------+------------------------------------- Changes (by hsyl20): * testcase: => prog014 * differential: => D1458 * component: GHCi => Compiler (CodeGen) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 10 18:16:57 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Nov 2015 18:16:57 -0000 Subject: [GHC] #11076: Demand information of foreign calls is wrong Message-ID: <044.34bd2569f92bdaaaa2887dd523555186@haskell.org> #11076: Demand information of foreign calls is wrong -------------------------------------+------------------------------------- Reporter: luite | 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 Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Foreign calls of all types (including prim calls) use `mkFCallId` to create a fresh `Id` for each one. This Id claims to be strict in all arguments, which is not correct for foreign calls that allow lifted types to be passed. This also causes some trouble for GHCJS. I hope to get a fix in 7.10.3. Can we leave the strictness sig out entirely perhaps? Most arguments would be trivially strict since they're unboxed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 10 18:22:43 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Nov 2015 18:22:43 -0000 Subject: [GHC] #11076: Demand information of foreign calls is wrong In-Reply-To: <044.34bd2569f92bdaaaa2887dd523555186@haskell.org> References: <044.34bd2569f92bdaaaa2887dd523555186@haskell.org> Message-ID: <059.6d8df7172c5152a57fd6c5027e75d3e6@haskell.org> #11076: Demand information of foreign calls is wrong -------------------------------------+------------------------------------- Reporter: luite | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by luite): * Attachment "forDmd_prim.cmm" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 10 18:22:54 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Nov 2015 18:22:54 -0000 Subject: [GHC] #11076: Demand information of foreign calls is wrong In-Reply-To: <044.34bd2569f92bdaaaa2887dd523555186@haskell.org> References: <044.34bd2569f92bdaaaa2887dd523555186@haskell.org> Message-ID: <059.b749e3434bba0de3bdc0bdcf9987b86a@haskell.org> #11076: Demand information of foreign calls is wrong -------------------------------------+------------------------------------- Reporter: luite | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by luite): * Attachment "forDmd.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 10 18:23:04 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Nov 2015 18:23:04 -0000 Subject: [GHC] #11076: Demand information of foreign calls is wrong In-Reply-To: <044.34bd2569f92bdaaaa2887dd523555186@haskell.org> References: <044.34bd2569f92bdaaaa2887dd523555186@haskell.org> Message-ID: <059.2f41e5e15894e0042eef338ca3490721@haskell.org> #11076: Demand information of foreign calls is wrong -------------------------------------+------------------------------------- Reporter: luite | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by luite): * Attachment "ForDmdA.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 10 19:17:57 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Nov 2015 19:17: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.d2d379c1cea22fc3ac97b77331fe5dd9@haskell.org> #10870: PPC.Ppr: Shift by 32 bits is not allowed. -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1322, Wiki Page: | Phab:1459 -------------------------------------+------------------------------------- Changes (by trommler): * differential: Phab:D1322 => Phab:D1322, Phab:1459 Comment: I uploaded the fix for HEAD to Phabricator. Thanks to @nomeata for testing and also for the pointers in comment:19! To sum up: 1. Phab:1459 has the patch for HEAD 1. `0001-PPC-nativeGen-fix-shift-right-arithmetic-31-bit.patch` attached to this ticket has the patch for ghc-7.10 BTW: Is there a way to post a patch to a branch on Phabricator? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 10 21:01:56 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Nov 2015 21:01:56 -0000 Subject: [GHC] #11077: ghc panic: ieName failed pattern match Message-ID: <044.b5e110944e8e8d0263744f093ade93e9@haskell.org> #11077: ghc panic: ieName failed pattern match -------------------------------------+------------------------------------- Reporter: woehr | 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 Rev(s): | Wiki Page: -------------------------------------+------------------------------------- My custom prelude module is producing the following panic in ghc: {{{ : ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-linux): ieName failed pattern match! Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The module is as follows: {{{#!hs module Prelude ( module X , tshow ) where import BasePrelude as X import Data.Text as X (Text, pack, unpack) tshow :: Show a => a -> Text tshow = pack . show }}} In my cabal file I depend on base-noprelude and base-prelude and use the above as my custom Prelude module. The panic is triggered by ```tshow```. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 10 21:03:26 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Nov 2015 21:03:26 -0000 Subject: [GHC] #11077: ghc panic: ieName failed pattern match In-Reply-To: <044.b5e110944e8e8d0263744f093ade93e9@haskell.org> References: <044.b5e110944e8e8d0263744f093ade93e9@haskell.org> Message-ID: <059.c2a5f7cfd769d3ee7606a8525042518d@haskell.org> #11077: ghc panic: ieName failed pattern match -------------------------------------+------------------------------------- Reporter: woehr | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by woehr): I meant to specify that I depend on base-noprelude in place of base. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 10 21:25:42 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Nov 2015 21:25:42 -0000 Subject: [GHC] #11077: ghc panic: ieName failed pattern match In-Reply-To: <044.b5e110944e8e8d0263744f093ade93e9@haskell.org> References: <044.b5e110944e8e8d0263744f093ade93e9@haskell.org> Message-ID: <059.1c33b4c3b33bdd6757cbe9be3dce5824@haskell.org> #11077: ghc panic: ieName failed pattern match -------------------------------------+------------------------------------- Reporter: woehr | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): How do I reproduce the bug? I install the packages `base-noprelude` and `base-prelude`, and then..? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 10 21:53:04 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Nov 2015 21:53:04 -0000 Subject: [GHC] #11077: ghc panic: ieName failed pattern match In-Reply-To: <044.b5e110944e8e8d0263744f093ade93e9@haskell.org> References: <044.b5e110944e8e8d0263744f093ade93e9@haskell.org> Message-ID: <059.2a4ab33ecf7049c18bb1ecfdb9d6dc72@haskell.org> #11077: ghc panic: ieName failed pattern match -------------------------------------+------------------------------------- Reporter: woehr | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by woehr): * Attachment "ghc11077.7z" added. Test case -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 10 21:53:35 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Nov 2015 21:53:35 -0000 Subject: [GHC] #11077: ghc panic: ieName failed pattern match In-Reply-To: <044.b5e110944e8e8d0263744f093ade93e9@haskell.org> References: <044.b5e110944e8e8d0263744f093ade93e9@haskell.org> Message-ID: <059.14c6f2ecf11b290b9f7b75941e77ae0f@haskell.org> #11077: ghc panic: ieName failed pattern match -------------------------------------+------------------------------------- Reporter: woehr | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by woehr): I've added a test project that will reproduce the bug when "cabal build" is executed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 10 21:54:21 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Nov 2015 21:54:21 -0000 Subject: [GHC] #11076: Demand information of foreign calls is wrong In-Reply-To: <044.34bd2569f92bdaaaa2887dd523555186@haskell.org> References: <044.34bd2569f92bdaaaa2887dd523555186@haskell.org> Message-ID: <059.d31bf37f6f1f411d641694659e06ccf7@haskell.org> #11076: Demand information of foreign calls is wrong -------------------------------------+------------------------------------- Reporter: luite | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by luite): related GHCJS ticket: https://github.com/ghcjs/ghcjs/issues/443 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 10 21:55:03 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Nov 2015 21:55:03 -0000 Subject: [GHC] #11076: Demand information of foreign calls is wrong In-Reply-To: <044.34bd2569f92bdaaaa2887dd523555186@haskell.org> References: <044.34bd2569f92bdaaaa2887dd523555186@haskell.org> Message-ID: <059.1cba0a764bced612d580fb168bfc6da3@haskell.org> #11076: Demand information of foreign calls is wrong -------------------------------------+------------------------------------- Reporter: luite | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by luite): * milestone: => 7.10.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 10 23:07:25 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Nov 2015 23:07:25 -0000 Subject: [GHC] #11075: Confusing parallel spark behaviour with safe FFI calls In-Reply-To: <045.aa23e7aefeffbe70dc2426bdbd5d297f@haskell.org> References: <045.aa23e7aefeffbe70dc2426bdbd5d297f@haskell.org> Message-ID: <060.aad36579f7a53611b32d510bd3e948ce@haskell.org> #11075: Confusing parallel spark behaviour with safe FFI calls -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): Oh, I actually implemented this a while ago as an experiment. I called it `foreign import "nonblocking"`, the idea is very simple: just release the capability but don't wake up another worker. It's not perfect, we could still get a worker woken up under some circumstances, but I bet it would help. I'll dig up the patch and see if we can get it in. Also, what on earth are you doing making FFI calls from sparks :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 11 00:15:18 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Nov 2015 00:15:18 -0000 Subject: [GHC] #11077: ghc panic: ieName failed pattern match (-fwarn-missing-exported-sigs) (was: ghc panic: ieName failed pattern match) In-Reply-To: <044.b5e110944e8e8d0263744f093ade93e9@haskell.org> References: <044.b5e110944e8e8d0263744f093ade93e9@haskell.org> Message-ID: <059.5207ead7db94b5b13a270e37bfc0e75b@haskell.org> #11077: ghc panic: ieName failed pattern match (-fwarn-missing-exported-sigs) -------------------------------------+------------------------------------- Reporter: woehr | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: gridaphobe (added) Comment: Thanks! Reproducible with HEAD. It seems `-fwarn-missing-exported-sigs` (#2526) has something to do with it. {{{ $ cat T11077.hs module T11077 (module X, foo) where import Data.List as X foo = undefined $ ghc -c T11077.hs -fwarn-missing-exported-sigs ghc: panic! (the 'impossible' happened) (GHC version 7.11.20151104 for x86_64-unknown-linux): ieName failed pattern match! }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 11 00:57:28 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Nov 2015 00:57:28 -0000 Subject: [GHC] #11076: Demand information of foreign calls is wrong In-Reply-To: <044.34bd2569f92bdaaaa2887dd523555186@haskell.org> References: <044.34bd2569f92bdaaaa2887dd523555186@haskell.org> Message-ID: <059.9d275bd469676d025f1babf51ae5c4e9@haskell.org> #11076: Demand information of foreign calls is wrong -------------------------------------+------------------------------------- Reporter: luite | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by luite): Changing the argument demand type from `evalDmd` to `topDmd` (in `MkId.mkFCallId`) fixes the problem for this test case and for GHCJS, and other than a minor (and I think harmless) change in one of the `stranal` test cases doesn't cause any validate issues. I just want to make sure, is this a sane thing to do? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 11 01:24:20 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Nov 2015 01:24:20 -0000 Subject: [GHC] #11047: Provide call stacks in GHCi In-Reply-To: <047.3eb9c7a7d6579e45d15f3dffd3ade555@haskell.org> References: <047.3eb9c7a7d6579e45d15f3dffd3ade555@haskell.org> Message-ID: <062.da9c97108648484982423521df8ce3a9@haskell.org> #11047: Provide call stacks in GHCi -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #545, #4837 | Differential Rev(s): Phab:D1407 Wiki Page: | -------------------------------------+------------------------------------- Comment (by luite): GHCJSi also runs code in a separate process, which works in a similar way. I haven't merged it in the GHCJS master branch yet since it requires some horrible hacking (with lots of copy/paste) of the GHC bytecode interpreter to make it not try to load/run the BCO in its own process (and then segfault). GHCJSi is actually a lot simpler than GHCJS TH in terms of communication, it just sends new pieces of code to run, and there's an additional command to abort the running computation (with an async exception), however stepping/tracing/breakpoints are not yet supported (GHCJSi uses the usual code generator, there is no bytecode interpreter). The other reason for it still being experimental is that I haven't properly designed input/output yet, GHCJSi just prints all the stdout output from the underlying node.js process (or browser), which sometimes messes up the prompt. If anyone is interested in designing and implementing some proper process boundary protocol, let me know, I'd be happy to help (time permitting). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 11 01:41:33 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Nov 2015 01:41:33 -0000 Subject: [GHC] #11055: GHC 7.8.4 crash on ARM while building Stack 0.1.7 In-Reply-To: <047.fb2a0236ca36949d692f2910f33633d4@haskell.org> References: <047.fb2a0236ca36949d692f2910f33633d4@haskell.org> Message-ID: <062.e473aac82df227af1c4c64819ef96d4d@haskell.org> #11055: GHC 7.8.4 crash on ARM while building Stack 0.1.7 ---------------------------------------+---------------------------------- Reporter: Lokathor | Owner: Type: bug | Status: infoneeded 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): Wiki Page: | ---------------------------------------+---------------------------------- Comment (by Lokathor): Success. Stack was able to rebuild stack and also cabal. I'm still not sure how to run that testsuite summary thing though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 11 05:44:41 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Nov 2015 05:44:41 -0000 Subject: [GHC] #11078: Access to module renaming with reifyModule, in TemplateHaskell Message-ID: <049.31454990f3b91e72bda5a21e4cbbf2c4@haskell.org> #11078: Access to module renaming with reifyModule, in TemplateHaskell -------------------------------------+------------------------------------- Reporter: cipher1024 | 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 Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I am writing a bit of TemplateHaskell for stringing together QuickCheck style specifications. I require every module containing properties to export a symbol called ''axiom_set''. Then, my checkAxioms function finds all the ''axiom_set'' symbols from modules imported where I call checkAxioms. checkAxioms :: DecsQ checkAxioms = do ModuleInfo ms <- reifyModule =<< thisModule forM_ ms $ \mi@(Module _ m) -> do runIO . print =<< lookupValueName (modString m ++ ".axiom_set") The above code should find all the imported "axiom_set" symbols. However, if Module.Axioms defines axiom_set but that I imported as follows import Module.Axioms as MA my code can't find MA.axiom_set. I think either modString should return MA in the case of Module.Axioms or there should be a function that takes a symbol and a module and constructs a Name referring to the symbol in the module and considering possible renamings of modules. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 11 08:30:40 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Nov 2015 08:30:40 -0000 Subject: [GHC] #11078: Access to module renaming with reifyModule, in TemplateHaskell In-Reply-To: <049.31454990f3b91e72bda5a21e4cbbf2c4@haskell.org> References: <049.31454990f3b91e72bda5a21e4cbbf2c4@haskell.org> Message-ID: <064.68a157764cf2fde2157485de3659a5dd@haskell.org> #11078: Access to module renaming with reifyModule, in TemplateHaskell -------------------------------------+------------------------------------- Reporter: cipher1024 | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by jstolarek: Old description: > I am writing a bit of TemplateHaskell for stringing together QuickCheck > style specifications. I require every module containing properties to > export a symbol called ''axiom_set''. Then, my checkAxioms function finds > all the ''axiom_set'' symbols from modules imported where I call > checkAxioms. > > checkAxioms :: DecsQ > checkAxioms = do > ModuleInfo ms <- reifyModule =<< thisModule > forM_ ms $ \mi@(Module _ m) -> do > runIO . print =<< lookupValueName (modString m ++ ".axiom_set") > > The above code should find all the imported "axiom_set" symbols. However, > if Module.Axioms defines axiom_set but that I imported as follows > > import Module.Axioms as MA > > my code can't find MA.axiom_set. > > I think either modString should return MA in the case of Module.Axioms or > there should be a function that takes a symbol and a module and > constructs a Name referring to the symbol in the module and considering > possible renamings of modules. New description: I am writing a bit of TemplateHaskell for stringing together QuickCheck style specifications. I require every module containing properties to export a symbol called `axiom_set`. Then, my `checkAxioms` function finds all the `axiom_set` symbols from modules imported where I call `checkAxioms`. {{{#!hs checkAxioms :: DecsQ checkAxioms = do ModuleInfo ms <- reifyModule =<< thisModule forM_ ms $ \mi@(Module _ m) -> do runIO . print =<< lookupValueName (modString m ++ ".axiom_set") }}} The above code should find all the imported `axiom_set` symbols. However, if `Module.Axioms` defines `axiom_set` but that I imported as follows {{{#!hs import Module.Axioms as MA }}} my code can't find `MA.axiom_set`. I think either `modString` should return `MA` in the case of `Module.Axioms` or there should be a function that takes a symbol and a module and constructs a `Name` referring to the symbol in the module and considering possible renamings of modules. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 11 08:33:59 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Nov 2015 08:33:59 -0000 Subject: [GHC] #11078: Access to module renaming with reifyModule, in TemplateHaskell In-Reply-To: <049.31454990f3b91e72bda5a21e4cbbf2c4@haskell.org> References: <049.31454990f3b91e72bda5a21e4cbbf2c4@haskell.org> Message-ID: <064.88e80689fba2f8b714c5649706c0df3b@haskell.org> #11078: Access to module renaming with reifyModule, in TemplateHaskell -------------------------------------+------------------------------------- Reporter: cipher1024 | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jstolarek): * cc: jstolarek (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 11 08:49:44 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Nov 2015 08:49:44 -0000 Subject: [GHC] #11076: Demand information of foreign calls is wrong In-Reply-To: <044.34bd2569f92bdaaaa2887dd523555186@haskell.org> References: <044.34bd2569f92bdaaaa2887dd523555186@haskell.org> Message-ID: <059.6eb5bce3521fb3280801ca51e1d2ea4f@haskell.org> #11076: Demand information of foreign calls is wrong -------------------------------------+------------------------------------- Reporter: luite | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Luite, yes, I think that seems sane. Where precisely do you make this change? Please add a clear Note to explain, referencing the ticket and giving an example. It's late in the day for 7.10.3, but I'll leave that to Ben and Austin. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 11 09:08:43 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Nov 2015 09:08:43 -0000 Subject: [GHC] #11055: GHC 7.8.4 crash on ARM while building Stack 0.1.7 In-Reply-To: <047.fb2a0236ca36949d692f2910f33633d4@haskell.org> References: <047.fb2a0236ca36949d692f2910f33633d4@haskell.org> Message-ID: <062.19b59162b6c5ea4cfdb24e0db6908a0b@haskell.org> #11055: GHC 7.8.4 crash on ARM while building Stack 0.1.7 ---------------------------------------+------------------------------ Reporter: Lokathor | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.8.4 Resolution: worksforme | Keywords: Operating System: Linux | Architecture: arm Type of failure: Compile-time crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------------+------------------------------ Changes (by thomie): * status: infoneeded => closed * resolution: => worksforme * milestone: => 7.10.3 Comment: If 7.10.3-rc1 fixed the problem for you, then we can close this ticket. Thanks for reporting and testing. Great to know that stack works on arm now. Check #10376 for those warnings. Workaround: set `library-stripping: False` in `~/.cabal/config`. Check this list for open arm bugs: https://ghc.haskell.org/trac/ghc/query?status=!closed&architecture=arm&order=id -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 11 09:18:13 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Nov 2015 09:18:13 -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.c8d1b018bcab32df7185549dbfd1a419@haskell.org> #10828: TH could do a better job of representing GADTs -------------------------------------+------------------------------------- Reporter: spinda | Owner: jstolarek Type: feature request | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jstolarek): These are `Foldable` instances derived automatically for data types in comment:8 {{{#!hs instance Foldable T1 where foldr f z (MkT1 a1) = f a1 z foldMap f (MkT1 a1) = f a1 instance Foldable T1' where foldr f z (MkT1' a1) = f a1 z foldMap f (MkT1' a1) = f a1 instance Foldable T2 where foldr f z (MkT2 a1) = (\ b1 b2 -> b2) a1 z foldMap f (MkT2 a1) = (\ b1 -> mempty) a1 instance Foldable T2' where foldr f z (MkT2' a1) = (\ b1 b2 -> b2) a1 z foldMap f (MkT2' a1) = (\ b1 -> mempty) a1 instance Foldable T3 where foldr f z (MkT3 a1) = (\ b1 b2 -> b2) a1 z foldMap f (MkT3 a1) = (\ b1 -> mempty) a1 instance Foldable T3' where foldr f z (MkT3' a1) = (\ b1 b2 -> b2) a1 z foldMap f (MkT3' a1) = (\ b1 -> mempty) a1 }}} So `DerivingFoldable` does not distinguish between GADT and normal declarations - respective pairs of instances are identical. At least in this case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 11 09:53:25 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Nov 2015 09:53: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.6458e9316e1d91ee131fecb4658120c6@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 Ben Gamari ): In [changeset:"96621b1b4979f449e873513e9de8d806257c9493/ghc" 96621b1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="96621b1b4979f449e873513e9de8d806257c9493" Associate pattern synonyms with types in module exports This patch implements #10653. It adds the ability to bundle pattern synonyms with type constructors in export lists so that users can treat pattern synonyms more like data constructors. Updates haddock submodule. Test Plan: ./validate Reviewers: goldfire, austin, bgamari Reviewed By: bgamari Subscribers: simonpj, gridaphobe, thomie Differential Revision: https://phabricator.haskell.org/D1258 GHC Trac Issues: #10653 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 11 10:43:32 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Nov 2015 10:43:32 -0000 Subject: [GHC] #11066: Inacessible branch should be warning - otherwise breaks type soundness? In-Reply-To: <047.0785946e31f05741dc32414264d84d16@haskell.org> References: <047.0785946e31f05741dc32414264d84d16@haskell.org> Message-ID: <062.facb551db3ac32c2139d157d385c94b7@haskell.org> #11066: Inacessible branch should be warning - otherwise breaks type soundness? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 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:D1454 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 7.10.3 Comment: I'm going to try to get this into 7.10.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 11 10:49:27 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Nov 2015 10:49:27 -0000 Subject: [GHC] #11066: Inacessible branch should be warning - otherwise breaks type soundness? In-Reply-To: <047.0785946e31f05741dc32414264d84d16@haskell.org> References: <047.0785946e31f05741dc32414264d84d16@haskell.org> Message-ID: <062.b9acbaa8cc75e0c3d15175970571f64b@haskell.org> #11066: Inacessible branch should be warning - otherwise breaks type soundness? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 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:D1454 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): There was muttering on the Phab trail about details. Not sure it's converged enough to commit. I trust Richard's judgement on this. Sadly I have ~zero time this week or next. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 11 11:02:18 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Nov 2015 11:02:18 -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.0a32e336ba098e0e56724a19a84d3a51@haskell.org> #4931: hsc2hs emits invalid OPTIONS_GHC pragmas -------------------------------------+------------------------------------- Reporter: awson | Owner: thomie Type: bug | Status: patch Priority: low | Milestone: 8.0.1 Component: hsc2hs | Version: 7.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: driver/T4931 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1452 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"fbc2537c0b2cbe947684bb39669643f1ef9d96c0/ghc" fbc2537/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="fbc2537c0b2cbe947684bb39669643f1ef9d96c0" OPTIONS_GHC compiler flags may contain spaces (#4931) When a .hsc contains `#define FOO "bar baz"`, hsc2hs emits: {-# OPTIONS_GHC -optc-DFOO="bar baz" #-} Make sure GHC can compile this, by tweaking `HeaderInfo.getOptions` a bit. Test Plan: driver/T4931 Reviewers: austin, bgamari Reviewed By: bgamari Differential Revision: https://phabricator.haskell.org/D1452 GHC Trac Issues: #4931 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 11 11:07:37 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Nov 2015 11:07:37 -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.eea992cc8a0eeafa9375906ed11e114b@haskell.org> #4931: hsc2hs emits invalid OPTIONS_GHC pragmas -------------------------------------+------------------------------------- Reporter: awson | Owner: thomie Type: bug | Status: closed Priority: low | Milestone: 8.0.1 Component: hsc2hs | Version: 7.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: driver/T4931 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1452 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 11 11:22:06 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Nov 2015 11:22:06 -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.6bbefde74142fb9b9c77ef2d3c43333b@haskell.org> #10653: PatternSynonyms should be imported/exported as part of the wildcard notation -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: mpickering Type: feature request | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | 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 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 11 11:26:57 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Nov 2015 11:26:57 -0000 Subject: [GHC] #9988: Remove fun_id, is_infix from FunBind, as they are now in Match In-Reply-To: <044.a60b224ba7da7f43c70f7f0475934826@haskell.org> References: <044.a60b224ba7da7f43c70f7f0475934826@haskell.org> Message-ID: <059.c25ecb840bc0be6db5bb21ef583933b1@haskell.org> #9988: Remove fun_id, is_infix from FunBind, as they are now in Match -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: closed Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D639 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"f0f9365fd7fe1a4c06926f390a6183449c3c6332/ghc" f0f9365/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f0f9365fd7fe1a4c06926f390a6183449c3c6332" Remove fun_infix from Funbind, as it is now in Match One of the changes D538 introduced is to add `m_fun_id_infix` to `Match` ```lang=hs data Match id body = Match { m_fun_id_infix :: (Maybe (Located id,Bool)), -- fun_id and fun_infix for functions with multiple equations -- only present for a RdrName. See note [fun_id in Match] m_pats :: [LPat id], -- The patterns m_type :: (Maybe (LHsType id)), -- A type signature for the result of the match -- Nothing after typechecking m_grhss :: (GRHSs id body) } deriving (Typeable) ``` This was done to track the individual locations and fixity of the `fun_id` for each of the defining equations for a function when there are more than one. For example, the function `(&&&)` is defined with some prefix and some infix equations below. ```lang=hs (&&& ) [] [] = [] xs &&& [] = xs ( &&& ) [] ys = ys ``` This means that the fun_infix is now superfluous in the `FunBind`. This has not been removed as a potentially risky change just before 7.10 RC2, and so must be done after. This ticket captures that task, which includes processing these fields through the renamer and beyond. Ticket #9988 introduced these fields into `Match` through renaming, this ticket it to continue through type checking and then remove it from `FunBind` completely. The split happened so that #9988 could land in 7.10 Trac ticket : #10061 Test Plan: ./validate Reviewers: goldfire, austin, simonpj, bgamari Reviewed By: bgamari Subscribers: simonpj, thomie, mpickering Differential Revision: https://phabricator.haskell.org/D1285 GHC Trac Issues: #10061 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 11 11:26:57 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Nov 2015 11:26:57 -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.4af91983e709a086e6745bbc99b0b331@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 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"f0f9365fd7fe1a4c06926f390a6183449c3c6332/ghc" f0f9365/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f0f9365fd7fe1a4c06926f390a6183449c3c6332" Remove fun_infix from Funbind, as it is now in Match One of the changes D538 introduced is to add `m_fun_id_infix` to `Match` ```lang=hs data Match id body = Match { m_fun_id_infix :: (Maybe (Located id,Bool)), -- fun_id and fun_infix for functions with multiple equations -- only present for a RdrName. See note [fun_id in Match] m_pats :: [LPat id], -- The patterns m_type :: (Maybe (LHsType id)), -- A type signature for the result of the match -- Nothing after typechecking m_grhss :: (GRHSs id body) } deriving (Typeable) ``` This was done to track the individual locations and fixity of the `fun_id` for each of the defining equations for a function when there are more than one. For example, the function `(&&&)` is defined with some prefix and some infix equations below. ```lang=hs (&&& ) [] [] = [] xs &&& [] = xs ( &&& ) [] ys = ys ``` This means that the fun_infix is now superfluous in the `FunBind`. This has not been removed as a potentially risky change just before 7.10 RC2, and so must be done after. This ticket captures that task, which includes processing these fields through the renamer and beyond. Ticket #9988 introduced these fields into `Match` through renaming, this ticket it to continue through type checking and then remove it from `FunBind` completely. The split happened so that #9988 could land in 7.10 Trac ticket : #10061 Test Plan: ./validate Reviewers: goldfire, austin, simonpj, bgamari Reviewed By: bgamari Subscribers: simonpj, thomie, mpickering Differential Revision: https://phabricator.haskell.org/D1285 GHC Trac Issues: #10061 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 11 12:04:22 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Nov 2015 12:04:22 -0000 Subject: [GHC] #11022: Invalid ELF "note" section format In-Reply-To: <045.8f29382f96dd0bd7affe58790341c9d8@haskell.org> References: <045.8f29382f96dd0bd7affe58790341c9d8@haskell.org> Message-ID: <060.bd6475f835d18ee37531e7226e633292@haskell.org> #11022: Invalid ELF "note" section format ---------------------------+---------------------------------------- Reporter: hsyl20 | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Driver | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: POSIX | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1375 Wiki Page: | ---------------------------+---------------------------------------- Comment (by Ben Gamari ): In [changeset:"109d7ce85aadbd9fb7a322a0a83548e5d4e83926/ghc" 109d7ce/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="109d7ce85aadbd9fb7a322a0a83548e5d4e83926" Systools: read ELF section without calling readelf This patch tackles two issues: 1) GHC stores a "link info" string into a ELF section. Initially a section with type "note" was used but GHC didn't follow the ELF specification which specifies a record-based format for these sections. With D1375 we switched to a "progbits" section type for which there isn't any format constraint. This is an issue for D1242 which use GCC's --gc-sections which collects "unused" sections, such as our section containing link info... In this patch, we fall back to a section with type "note" but we respect the specified format. 2) Reading back the ELF section was done by parsing the result of a call to "readelf". Calling readelf is problematic because the program may not be available or it may be renamed on some platforms (see D1326). Moreover we have no garanty that its output layout will stay the same in future releases of readelf. Finally we would need to fix the parsing to support "note" sections because of 1. Instead, this patch proposes to use Data.Binary.Get to directly read the "link info" note into its section. ELF has a specification, hence it should work on every conforming platform. This patch "reverts" D1375, hence it supersedes D1432. It makes D1326 not necessary anymore. Test Plan: - recomp011 should pass (test that relinking is avoided when both "link info" match) - we should add a test for ELF objects with more than 0xff00 sections => added test "recomp015" - we should check that GAS generates 32-bit words with .int on every supported platform using ELF (or find a place where this is documented). harbomaster and I (@hsyl20) only tested on x86-64. On platforms where it is not true, it should make recomp011 fail. => tested to work on Linux/amd64, Solaris/i386 and OpenBSD/amd64 Reviewers: olsner, ony, thomie, kgardas, austin, bgamari Reviewed By: thomie, bgamari Subscribers: kgardas, rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D1381 GHC Trac Issues: #10974, #11022 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 11 12:04:22 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Nov 2015 12:04:22 -0000 Subject: [GHC] #10974: Fix SysTools.readElfSection on platforms where "readelf" have different name In-Reply-To: <042.e244cf8dc95faa52bdcffe7336aa317f@haskell.org> References: <042.e244cf8dc95faa52bdcffe7336aa317f@haskell.org> Message-ID: <057.3923eb9795ad0bd0f57f8110966c2bf3@haskell.org> #10974: Fix SysTools.readElfSection on platforms where "readelf" have different name -------------------------------------+------------------------------------- Reporter: ony | 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: Other | Test Case: | driver/recomp011 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1326 Wiki Page: | Phab:D1335 Phab:D1381 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"109d7ce85aadbd9fb7a322a0a83548e5d4e83926/ghc" 109d7ce/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="109d7ce85aadbd9fb7a322a0a83548e5d4e83926" Systools: read ELF section without calling readelf This patch tackles two issues: 1) GHC stores a "link info" string into a ELF section. Initially a section with type "note" was used but GHC didn't follow the ELF specification which specifies a record-based format for these sections. With D1375 we switched to a "progbits" section type for which there isn't any format constraint. This is an issue for D1242 which use GCC's --gc-sections which collects "unused" sections, such as our section containing link info... In this patch, we fall back to a section with type "note" but we respect the specified format. 2) Reading back the ELF section was done by parsing the result of a call to "readelf". Calling readelf is problematic because the program may not be available or it may be renamed on some platforms (see D1326). Moreover we have no garanty that its output layout will stay the same in future releases of readelf. Finally we would need to fix the parsing to support "note" sections because of 1. Instead, this patch proposes to use Data.Binary.Get to directly read the "link info" note into its section. ELF has a specification, hence it should work on every conforming platform. This patch "reverts" D1375, hence it supersedes D1432. It makes D1326 not necessary anymore. Test Plan: - recomp011 should pass (test that relinking is avoided when both "link info" match) - we should add a test for ELF objects with more than 0xff00 sections => added test "recomp015" - we should check that GAS generates 32-bit words with .int on every supported platform using ELF (or find a place where this is documented). harbomaster and I (@hsyl20) only tested on x86-64. On platforms where it is not true, it should make recomp011 fail. => tested to work on Linux/amd64, Solaris/i386 and OpenBSD/amd64 Reviewers: olsner, ony, thomie, kgardas, austin, bgamari Reviewed By: thomie, bgamari Subscribers: kgardas, rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D1381 GHC Trac Issues: #10974, #11022 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 11 12:04:22 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Nov 2015 12:04:22 -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.a9d9e8edfe0275215ed920d1a53d01de@haskell.org> #10870: PPC.Ppr: Shift by 32 bits is not allowed. -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1322, Wiki Page: | Phab:1459 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"fb0d5120d383324c6934144b938525378e3ade75/ghc" fb0d512/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="fb0d5120d383324c6934144b938525378e3ade75" nativeGen.PPC: Fix shift arith. right > 31 bits Arithmetic right shifts of more than 31 bits set all bits to the sign bit on PowerPC. iThe assembler does not allow shift amounts larger than 32 so do an arithemetic right shift of 31 bit instead. Fixes #10870 Test Plan: validate (especially on powerpc) Reviewers: austin, erikd, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1459 GHC Trac Issues: #10870 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 11 12:04:22 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Nov 2015 12:04:22 -0000 Subject: [GHC] #10462: GHCi doesn't work Any and missing RealWorld foreign prim imports In-Reply-To: <045.272515eb6529b0f69e6fb29bb854188b@haskell.org> References: <045.272515eb6529b0f69e6fb29bb854188b@haskell.org> Message-ID: <060.84fe963c1e0e5589863a73fad6ef38e7@haskell.org> #10462: GHCi doesn't work Any and missing RealWorld foreign prim imports -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: patch Priority: low | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: prog014 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D1458 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"badf5d54907a5a5e9224c44310f991a52379b4c1/ghc" badf5d5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="badf5d54907a5a5e9224c44310f991a52379b4c1" Detect invalid foreign imports in bytecode compiler The bytecode compiler doesn't handle every foreign import calling convention. Instead of crashing during the generation of the foreign call, we display an error. Fix lint warnings Test Plan: prog014 ghci test added Reviewers: austin, hvr, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1458 GHC Trac Issues: #10462 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 11 12:05:54 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Nov 2015 12:05:54 -0000 Subject: [GHC] #11071: "Not in scope" errors should be more informative for qualified names. In-Reply-To: <047.e970b72d66ebf0753d36739a65af99a0@haskell.org> References: <047.e970b72d66ebf0753d36739a65af99a0@haskell.org> Message-ID: <062.12e54feb5feb761754215f3fb5616e17@haskell.org> #11071: "Not in scope" errors should be more informative for qualified names. -------------------------------------+------------------------------------- Reporter: mojojojo | Owner: nomeata Type: feature request | 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 Rev(s): Phab:D1462 Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => patch * differential: => Phab:D1462 * milestone: => 8.0.1 Comment: Got something nice; I?m quite happy with it so far. Let?s see how many corner cases arise :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 11 12:19:01 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Nov 2015 12:19:01 -0000 Subject: [GHC] #10974: Fix SysTools.readElfSection on platforms where "readelf" have different name In-Reply-To: <042.e244cf8dc95faa52bdcffe7336aa317f@haskell.org> References: <042.e244cf8dc95faa52bdcffe7336aa317f@haskell.org> Message-ID: <057.b513593879532e3d67c49c4164bcf607@haskell.org> #10974: Fix SysTools.readElfSection on platforms where "readelf" have different name -------------------------------------+------------------------------------- Reporter: ony | 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: Other | Test Case: | driver/recomp011 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1326 Wiki Page: | Phab:D1335 Phab:D1381 -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 11 12:20:31 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Nov 2015 12:20:31 -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.86ff82841f49daee93fc00c47baddedc@haskell.org> #10870: PPC.Ppr: Shift by 32 bits is not allowed. -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 (CodeGen) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1322, Wiki Page: | Phab:1459 -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 11 12:24:37 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Nov 2015 12:24:37 -0000 Subject: [GHC] #11076: Demand information of foreign calls is wrong In-Reply-To: <044.34bd2569f92bdaaaa2887dd523555186@haskell.org> References: <044.34bd2569f92bdaaaa2887dd523555186@haskell.org> Message-ID: <059.195d09d00ea61e0e5b10c91398e7cbdf@haskell.org> #11076: Demand information of foreign calls is wrong -------------------------------------+------------------------------------- Reporter: luite | 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: | Differential Rev(s): Phab:D1407 Wiki Page: | -------------------------------------+------------------------------------- Changes (by luite): * differential: => Phab:D1407 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 11 12:25:47 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Nov 2015 12:25:47 -0000 Subject: [GHC] #11076: Demand information of foreign calls is wrong In-Reply-To: <044.34bd2569f92bdaaaa2887dd523555186@haskell.org> References: <044.34bd2569f92bdaaaa2887dd523555186@haskell.org> Message-ID: <059.7f8a948b497f2d07b0d880007755fd89@haskell.org> #11076: Demand information of foreign calls is wrong -------------------------------------+------------------------------------- Reporter: luite | 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: | Differential Rev(s): Phab:D1464 Wiki Page: | -------------------------------------+------------------------------------- Changes (by luite): * differential: Phab:D1407 => Phab:D1464 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 11 12:35:32 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Nov 2015 12:35:32 -0000 Subject: [GHC] #11076: Demand information of foreign calls is wrong In-Reply-To: <044.34bd2569f92bdaaaa2887dd523555186@haskell.org> References: <044.34bd2569f92bdaaaa2887dd523555186@haskell.org> Message-ID: <059.68cdbd1cacf7f303113f33299be37b1c@haskell.org> #11076: Demand information of foreign calls is wrong -------------------------------------+------------------------------------- Reporter: luite | 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: | Differential Rev(s): Phab:D1464 Wiki Page: | -------------------------------------+------------------------------------- Comment (by luite): See diff. I'll update the expected test results once my validate run finishes. Should I also add the attached test case to the testsuite? If it's too late for 7.10.3 then feel free to remove the milestone and just merge in HEAD, I'll try to find a workaround then. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 11 12:41:28 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Nov 2015 12:41:28 -0000 Subject: [GHC] #11076: Demand information of foreign calls is wrong In-Reply-To: <044.34bd2569f92bdaaaa2887dd523555186@haskell.org> References: <044.34bd2569f92bdaaaa2887dd523555186@haskell.org> Message-ID: <059.6ca5ef07cc9d8ca0e22bbb8176a918c0@haskell.org> #11076: Demand information of foreign calls is wrong -------------------------------------+------------------------------------- Reporter: luite | 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: | Differential Rev(s): Phab:D1464 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I think we can swing 7.10.3. Can you add your testcase to the patch, however? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 11 12:48:35 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Nov 2015 12:48:35 -0000 Subject: [GHC] #9758: By default, testsuite should clean up after successful tests In-Reply-To: <045.6afbb9f1f5e466d1289d5bd3af0bb1ad@haskell.org> References: <045.6afbb9f1f5e466d1289d5bd3af0bb1ad@haskell.org> Message-ID: <060.e6ca6838530ede44a044e59aef3b98dd@haskell.org> #9758: By default, testsuite should clean up after successful tests -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: low | Milestone: Component: Test Suite | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): I often run `make test` in the `testsuite/tests` directory itself, and this this bytes. I suggest to simply make `CLEANUP=1` the default, and if someone needs to build an individual test _and keep the output_ (which I expect is the exception), then have him say `CLEANUP=0` explicitly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 11 13:54:48 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Nov 2015 13:54:48 -0000 Subject: [GHC] #11076: Demand information of foreign calls is wrong In-Reply-To: <044.34bd2569f92bdaaaa2887dd523555186@haskell.org> References: <044.34bd2569f92bdaaaa2887dd523555186@haskell.org> Message-ID: <059.fd284342bb2da89f9e93e104ed48b7b6@haskell.org> #11076: Demand information of foreign calls is wrong -------------------------------------+------------------------------------- Reporter: luite | 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: | Differential Rev(s): Phab:D1464 Wiki Page: | -------------------------------------+------------------------------------- Comment (by luite): I've added the test case from this ticket. Does the change in strictness signature for T8598 look ok? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 11 13:59:27 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Nov 2015 13:59:27 -0000 Subject: [GHC] #11078: Access to module renaming with reifyModule, in TemplateHaskell In-Reply-To: <049.31454990f3b91e72bda5a21e4cbbf2c4@haskell.org> References: <049.31454990f3b91e72bda5a21e4cbbf2c4@haskell.org> Message-ID: <064.266970ac85ff238a63d0e89ca496f98e@haskell.org> #11078: Access to module renaming with reifyModule, in TemplateHaskell -------------------------------------+------------------------------------- Reporter: cipher1024 | Owner: Type: feature request | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * milestone: => 8.0.1 Comment: Good point. What about this design: {{{ data ModuleInfo = ModuleInfo [ModuleImport] data ModuleImport = ModuleImport Module -- ^ imported module Bool -- ^ qualified? (Maybe String) -- ^ synonym [Name] -- ^ imported names data Module = Module PkgName ModName -- as it is today }}} I'm not sure that GHC can fully populate `ModuleImport` given the information that it has to hand. But if we could build `ModuleImport`s, would this solve your problem? One further refinement is to enable querying of whether or not the user specified an import list or if simply all names were imported. But I'm less convinced of the need for that at this point. It would be lovely if someone were to do this for 8.0! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 11 14:01:58 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Nov 2015 14:01:58 -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.234f5959a590bb57e6a5bd928d85b7c4@haskell.org> #10828: TH could do a better job of representing GADTs -------------------------------------+------------------------------------- Reporter: spinda | Owner: jstolarek Type: feature request | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Good. I understood you to mean previously that the three forms had the same `Foldable` instance -- not that primed forms matched the unprimed forms, as you've clarified here. So fixing this is a bit less compelling. But I still think it would be nice, given that TH is meant to reflect Haskell syntax, and it fails miserably in this corner. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 11 14:48:27 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Nov 2015 14:48:27 -0000 Subject: [GHC] #11078: Access to module renaming with reifyModule, in TemplateHaskell In-Reply-To: <049.31454990f3b91e72bda5a21e4cbbf2c4@haskell.org> References: <049.31454990f3b91e72bda5a21e4cbbf2c4@haskell.org> Message-ID: <064.cd20db01e11de69bfb5cde4700dc9485@haskell.org> #11078: Access to module renaming with reifyModule, in TemplateHaskell -------------------------------------+------------------------------------- Reporter: cipher1024 | Owner: Type: feature request | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by cipher1024): Yes, I believe that would do the trick nicely. Instead of a Maybe String, you could have a String stand for the synonym. Whenever the import is not renamed, it would hold the exact name of the imported module. After thinking some more about your proposal, I'm really liking the list of names. That should simplify my design significantly. How hard do you think it will be to implement? Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 11 14:52:12 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Nov 2015 14:52:12 -0000 Subject: [GHC] #11078: Access to module renaming with reifyModule, in TemplateHaskell In-Reply-To: <049.31454990f3b91e72bda5a21e4cbbf2c4@haskell.org> References: <049.31454990f3b91e72bda5a21e4cbbf2c4@haskell.org> Message-ID: <064.31f2126fcf3693f089ce04210e845a8a@haskell.org> #11078: Access to module renaming with reifyModule, in TemplateHaskell -------------------------------------+------------------------------------- Reporter: cipher1024 | Owner: Type: feature request | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * cc: osa1 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 11 14:57:46 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Nov 2015 14:57:46 -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.fafe6ac7982e8b40781b45b60e75cdbe@haskell.org> #10828: TH could do a better job of representing GADTs -------------------------------------+------------------------------------- Reporter: spinda | Owner: jstolarek Type: feature request | 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 Rev(s): Phab:D1465 Wiki Page: | -------------------------------------+------------------------------------- Changes (by jstolarek): * differential: => Phab:D1465 Comment: I'll continue the discussion on Phab. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 11 15:49:06 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Nov 2015 15:49:06 -0000 Subject: [GHC] #11079: Add ability to access and generate haddock-style comments through template haskell Message-ID: <045.ea998818dfe9c428db1d751652cf3a01@haskell.org> #11079: Add ability to access and generate haddock-style comments through template haskell -------------------------------------+------------------------------------- Reporter: ekmett | 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 Rev(s): | Wiki Page: -------------------------------------+------------------------------------- We've had a number of suggestions throughout the last few years that we either by default or by option permit the copying of comments from the original field to the lenses we generates via `template-haskell`. There isn't a way to do this currently. Ideally we'd be able to access the haddocks associated with a name and generate comments as a form of declaration suitable for the top level or in a class definition. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 11 15:49:55 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Nov 2015 15:49:55 -0000 Subject: [GHC] #11079: Add ability to access and generate haddock-style comments through template haskell In-Reply-To: <045.ea998818dfe9c428db1d751652cf3a01@haskell.org> References: <045.ea998818dfe9c428db1d751652cf3a01@haskell.org> Message-ID: <060.abcd0378486f3290c04d5145701f6ab9@haskell.org> #11079: Add ability to access and generate haddock-style comments through template haskell -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5467 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ekmett): * status: new => closed * resolution: => duplicate * related: => #5467 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 11 15:51:30 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Nov 2015 15:51:30 -0000 Subject: [GHC] #5467: Template Haskell: support for Haddock comments In-Reply-To: <046.e4a8d15ae2317226a67b074817a4dd39@haskell.org> References: <046.e4a8d15ae2317226a67b074817a4dd39@haskell.org> Message-ID: <061.0586723ea59258fa26de1bc89887e3b5@haskell.org> #5467: Template Haskell: support for Haddock comments -------------------------------------+------------------------------------- Reporter: reinerp | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.2.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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): This has been the cause of a standing issue for `lens` for some time. https://github.com/ekmett/lens/issues/614 is the latest incarnation of it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 11 15:51:52 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Nov 2015 15:51:52 -0000 Subject: [GHC] #5467: Template Haskell: support for Haddock comments In-Reply-To: <046.e4a8d15ae2317226a67b074817a4dd39@haskell.org> References: <046.e4a8d15ae2317226a67b074817a4dd39@haskell.org> Message-ID: <061.32dc8727c8e72e9159220fd876762d21@haskell.org> #5467: Template Haskell: support for Haddock comments -------------------------------------+------------------------------------- Reporter: reinerp | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.2.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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ekmett): * cc: ekmett (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 11 18:04:24 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Nov 2015 18:04:24 -0000 Subject: [GHC] #11067: Spurious superclass cycle error with type equalities In-Reply-To: <045.f5d44ba3aad0bf1ca48ae450e6c33b15@haskell.org> References: <045.f5d44ba3aad0bf1ca48ae450e6c33b15@haskell.org> Message-ID: <060.7856d9776daeef10c4ee8071276170fb@haskell.org> #11067: Spurious superclass cycle error with type equalities -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by oerjan): After meditating on the [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/type- class-extensions.html#superclass-rules User's Guide's] "A superclass context for a class C is allowed if, after expanding type synonyms to their right-hand-sides, and uses of classes (other than C) to their superclasses, C does not occur syntactically in the context." I've concluded that the behavior I'm seeing, even if strange, is exactly as advertised. Type families and equations are not expanded, but their arguments are checked for whether a class occurs cyclically there. Thus dependent on where in the hierarchy it is placed, a type family can either: * prevent cycle detection by hiding the cyclic use inside an instance (and our workaround in the new `Data.Constraint.Forall` depends on this), or * trigger spurious cycle detection by one of its arguments containing a class that is never actually be used as a constraint. (In our case, the `Skolem`s are essentially phantom type arguments.) On the plus side, the first case can be used to encode superclass recursion when GHC does not otherwise understand that it is harmless. On the minus side, the first case can probably get GHC's constraint resolution to loop if there actually *is* a real constraint cycle or infinite expansion. (Wild idea: would it be possible to use lazy breadth first search to make some infinite superclass hierarchies actually work?) However, I would say the plus side is big: there really *should* be a way for the programmer to encode a terminating superclass recursion if they know what they're doing. Of course a more intentionally enabled method might be better. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 11 20:54:08 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Nov 2015 20:54:08 -0000 Subject: [GHC] #11080: Open data kinds Message-ID: <047.64e06093644ddd3cb76b94e28bef420a@haskell.org> #11080: Open data kinds -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: Type: feature | Status: new request | Priority: low | Milestone: Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When we need type level symbols, we used to only have one option, `EmptyDataDecls`. The symbolic type parameters would be given kind `*`, but the convention would be to use types that are (mostly) uninhabited and that were made for the purpose of serving as symbols. For an example of this see http://hackage.haskell.org/package/servant-0.4.4.5/docs/Servant- API-ContentTypes.html. Now we also have the `Symbol` kind which can serve a similar purpose. Neither of these options is fully satisfactory for examples like servant's type-level encoding of content types, or the `units` libraries type-level encoding of physical dimensions, for the following reasons: We would prefer to give these types a kind other than `*` both because they are uninhabited and because we wish to provide documentation of what types are acceptable in these parameter positions. But the only facility we have for creating new kinds is `DataKinds`, and the kinds it creates are all closed. This is problematic because we wish to allow client modules to declare new content types or new physical dimensions. We could provide "newkind" wrappers around `Symbol` using `DataKinds`, but that runs in to name collision issues. The `EmptyDataDecls` solution is superior here because types with the same name declared in different modules remain distinct. Instead I propose the addition of a new feature where data kinds can be open. In a discussion at https://github.com/bjornbm/dimensional-dk/issues/96 in which @goldfire participated, we arrived at the following proposal for concrete syntax, but certainly there are many possible variations one could imagine which might have equal or greater merit: {{{#!hs -- declares a new kind which initially has no inhabitants data open ContentType -- declares a new type of kind ContentType, which is distinct -- from any others that may have been declared elsewhere, -- even if they have the same non-module-qualified name data constructor JSON :: ContentType }}} (@goldfire raised the possibility of one day interpreting the same `data constructor ...` syntax at the type level to declare inhabited types for which some constructors are defined in one module but which are open to extension with new constructors by other modules, but that is a distinct issue in all other ways apart from possibly wishing to share syntax.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 11 23:29:28 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Nov 2015 23:29:28 -0000 Subject: [GHC] #10172: Cross-platform sed In-Reply-To: <045.1be076a91930fb4fb7093c910a217d5c@haskell.org> References: <045.1be076a91930fb4fb7093c910a217d5c@haskell.org> Message-ID: <060.105789542de89cfd62db46b6e121a407@haskell.org> #10172: Cross-platform sed ---------------------------------+---------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.11 Resolution: | Keywords: Operating System: Solaris | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by thomie): kgardas: in Phab:D1467, we need to do some arithmetic. Does running `echo $((2*1000 + 16*10 + 0))` in the shell result in `2160` on all your systems? Or is it better to use `expr`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 12 05:35:20 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Nov 2015 05:35:20 -0000 Subject: [GHC] #10989: :ctags and :etags command can receive haskell source files as a parameter In-Reply-To: <045.de3e950ef6c4dee2c0f5411e366ebc4e@haskell.org> References: <045.de3e950ef6c4dee2c0f5411e366ebc4e@haskell.org> Message-ID: <060.81439999765dab01d1737631e94af86a@haskell.org> #10989: :ctags and :etags command can receive haskell source files as a parameter -------------------------------------+------------------------------------- Reporter: hugomg | Owner: tvv Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.10.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by tvv): * owner: => tvv -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 12 10:29:48 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Nov 2015 10:29:48 -0000 Subject: [GHC] #9314: Each object file in a static archive file (.a) is loaded into its own mmap()ed page In-Reply-To: <052.69f389ede5e82026cc5c1d8ff164657e@haskell.org> References: <052.69f389ede5e82026cc5c1d8ff164657e@haskell.org> Message-ID: <067.605efd1984afb0135ba3e4b0e4ad03c1@haskell.org> #9314: Each object file in a static archive file (.a) is loaded into its own mmap()ed page -------------------------------------+------------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Runtime System | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D985 Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): Phab:D985 has been merged into into Phab:D975, which has been merged into HEAD, but I'm not seeing the huge improvements that hsyl20 mentioned in comment:16. ||= GHC =||= RSS =|| || 7.11.20151111 (HEAD) || 123M || || 7.10.2 || 142M || || 7.8.4 || 131M || || 7.6.3 || 41M || I compile `ghc A.hs -package ghc -package ghc-paths`, then run `./A`, look at the `RES` column in `top`, and convert from Kb to Mb. What am I missing? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 12 10:35:11 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Nov 2015 10:35:11 -0000 Subject: [GHC] #9314: Each object file in a static archive file (.a) is loaded into its own mmap()ed page In-Reply-To: <052.69f389ede5e82026cc5c1d8ff164657e@haskell.org> References: <052.69f389ede5e82026cc5c1d8ff164657e@haskell.org> Message-ID: <067.67315acf7217d0090d4e3297a23184eb@haskell.org> #9314: Each object file in a static archive file (.a) is loaded into its own mmap()ed page -------------------------------------+------------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Runtime System | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => new * differential: Phab:D985 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 12 13:31:18 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Nov 2015 13:31:18 -0000 Subject: [GHC] #11075: Confusing parallel spark behaviour with safe FFI calls In-Reply-To: <045.aa23e7aefeffbe70dc2426bdbd5d297f@haskell.org> References: <045.aa23e7aefeffbe70dc2426bdbd5d297f@haskell.org> Message-ID: <060.1f76b3fec697138d4f94656194c0f650@haskell.org> #11075: Confusing parallel spark behaviour with safe FFI calls -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by duncan): Thanks Simon! To answer your Q, linear algebra :-) To be clear: this isn't critical for my application, but I can see how people following a pure parallelism strategy would hit this and it'd be jolly confusing. I've now got a different solution using explicit IO threads. Less elegant but works well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 12 14:12:57 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Nov 2015 14:12:57 -0000 Subject: [GHC] #11071: "Not in scope" errors should be more informative for qualified names. In-Reply-To: <047.e970b72d66ebf0753d36739a65af99a0@haskell.org> References: <047.e970b72d66ebf0753d36739a65af99a0@haskell.org> Message-ID: <062.059a99da10cc75426566d3210b650b49@haskell.org> #11071: "Not in scope" errors should be more informative for qualified names. -------------------------------------+------------------------------------- Reporter: mojojojo | Owner: nomeata Type: feature request | 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 Rev(s): Phab:D1462 Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): Looking at the code, it doesn't seem too difficult to also improve the error message for cases (3) and (4) (from comment:5) when using //unqualified// imports. For example: {{{ import Data.Map import Data.List hiding (transpose) f = transpose }}} This could show the same message as when `f = Data.List.transpose`: `"Perhaps you want to remove ?transpose? from the explicit hiding list in the import of ?Data.List?"`, because only `Data.List` exports `transpose`; `Data.Map` doesn't. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 12 14:31:15 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Nov 2015 14:31:15 -0000 Subject: [GHC] #11071: "Not in scope" errors should be more informative for qualified names. In-Reply-To: <047.e970b72d66ebf0753d36739a65af99a0@haskell.org> References: <047.e970b72d66ebf0753d36739a65af99a0@haskell.org> Message-ID: <062.a234b23d3e0982a2eb72af2575fc8abe@haskell.org> #11071: "Not in scope" errors should be more informative for qualified names. -------------------------------------+------------------------------------- Reporter: mojojojo | Owner: nomeata Type: feature request | 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 Rev(s): Phab:D1462 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Yes, that idea crossed my mind as well. Would you suggest I include in ?Phab:D1462, or should we, in the interest of self-contained and reasonably sized patches land that first before I implement that variant as well? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 12 14:40:35 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Nov 2015 14:40:35 -0000 Subject: [GHC] #11080: Open data kinds In-Reply-To: <047.64e06093644ddd3cb76b94e28bef420a@haskell.org> References: <047.64e06093644ddd3cb76b94e28bef420a@haskell.org> Message-ID: <062.d97244231046d1183bff277e0676176c@haskell.org> #11080: Open data kinds -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: Type: feature request | Status: new Priority: low | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jstolarek): * cc: jstolarek (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 12 14:54:43 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Nov 2015 14:54:43 -0000 Subject: [GHC] #11076: Demand information of foreign calls is wrong In-Reply-To: <044.34bd2569f92bdaaaa2887dd523555186@haskell.org> References: <044.34bd2569f92bdaaaa2887dd523555186@haskell.org> Message-ID: <059.92c1b49f0d5d36bc00951f8b9e9f3453@haskell.org> #11076: Demand information of foreign calls is wrong -------------------------------------+------------------------------------- Reporter: luite | 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: | Differential Rev(s): Phab:D1464 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"e090f1bc14b5bf1deeef1c753c1145c162c0d27f/ghc" e090f1b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e090f1bc14b5bf1deeef1c753c1145c162c0d27f" Change demand information for foreign calls Foreign calls may not be strict for lifted arguments. Fixes Trac #11076. Test Plan: ./validate Reviewers: simonpj, bgamari, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1464 GHC Trac Issues: #11076 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 12 14:54:43 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Nov 2015 14:54:43 -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.e0f72f55702990b5a1ebe6ffd7b48a30@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 Rev(s): Phab:D1242 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"4a32bf925b8aba7885d9c745769fe84a10979a53/ghc" 4a32bf9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4a32bf925b8aba7885d9c745769fe84a10979a53" Implement function-sections for Haskell code, #8405 This adds a flag -split-sections that does similar things to -split-objs, but using sections in single object files instead of relying on the Satanic Splitter and other abominations. This is very similar to the GCC flags -ffunction-sections and -fdata-sections. The --gc-sections linker flag, which allows unused sections to actually be removed, is added to all link commands (if the linker supports it) so that space savings from having base compiled with sections can be realized. Supported both in LLVM and the native code-gen, in theory for all architectures, but really tested on x86 only. In the GHC build, a new SplitSections variable enables -split-sections for relevant parts of the build. Test Plan: validate with both settings of SplitSections Reviewers: dterei, Phyx, austin, simonmar, thomie, bgamari Reviewed By: simonmar, thomie, bgamari Subscribers: hsyl20, erikd, kgardas, thomie Differential Revision: https://phabricator.haskell.org/D1242 GHC Trac Issues: #8405 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 12 14:54:43 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Nov 2015 14:54:43 -0000 Subject: [GHC] #10678: integer-gmp's runS seems unnecessarily expensive In-Reply-To: <047.1e3027d49179affc6473e88cc8dec51a@haskell.org> References: <047.1e3027d49179affc6473e88cc8dec51a@haskell.org> Message-ID: <062.3da2daa27d4a754b5ef842db472a8d26@haskell.org> #10678: integer-gmp's runS seems unnecessarily expensive -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1103 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"351de169e14ad9277aaca653df4a3753c151f7bb/ghc" 351de169/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="351de169e14ad9277aaca653df4a3753c151f7bb" New magic function for applying realWorld# Test Plan: validate Reviewers: goldfire, erikd, rwbarton, simonpj, austin, simonmar, hvr Reviewed By: simonpj Subscribers: simonmar, thomie Differential Revision: https://phabricator.haskell.org/D1103 GHC Trac Issues: #10678 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 12 16:10:37 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Nov 2015 16:10:37 -0000 Subject: [GHC] #10678: integer-gmp's runS seems unnecessarily expensive In-Reply-To: <047.1e3027d49179affc6473e88cc8dec51a@haskell.org> References: <047.1e3027d49179affc6473e88cc8dec51a@haskell.org> Message-ID: <062.75bdd75fbb5ebc0bb288d99f3d562dd9@haskell.org> #10678: integer-gmp's runS seems unnecessarily expensive -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 (CodeGen) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1103 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 12 16:11:16 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Nov 2015 16:11:16 -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.8adbd9c387894656d03f684de493aa7a@haskell.org> #8405: experiment with using function-sections for linking (for smaller libs and executables) -------------------------------------+------------------------------------- Reporter: carter | Owner: olsner Type: task | Status: closed Priority: normal | 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 Rev(s): Phab:D1242 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: We now have support for this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 12 16:35:44 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Nov 2015 16:35:44 -0000 Subject: [GHC] #9314: Each object file in a static archive file (.a) is loaded into its own mmap()ed page In-Reply-To: <052.69f389ede5e82026cc5c1d8ff164657e@haskell.org> References: <052.69f389ede5e82026cc5c1d8ff164657e@haskell.org> Message-ID: <067.c260c95d4291284dad52d8ea218107b3@haskell.org> #9314: Each object file in a static archive file (.a) is loaded into its own mmap()ed page -------------------------------------+------------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Runtime System | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hsyl20): @simonmar wrote: "I like not having to memcpy all the memory for an object file into the 1-2GB region, we just mmap it - this is also useful because various tools (like perf) understand the mapping and can give symbol names. For .a files I think it's fine to memcpy the bits though." (https://phabricator.haskell.org/D985#26591) I think that's why D975 doesn't bring the memory improvement while D985 did. Maybe we should add a flag (or use -g) to switch between the mmap mode that tools like perf understand and the memcpy mode that is much cheaper (the latter becoming the default mode). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 12 19:21:44 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Nov 2015 19:21:44 -0000 Subject: [GHC] #11018: ApiAnnotations: Add SourceText for unicode tokens In-Reply-To: <044.b2f994e490e36bcbf86a1f576ead0ae0@haskell.org> References: <044.b2f994e490e36bcbf86a1f576ead0ae0@haskell.org> Message-ID: <059.db0e0da624d5005c6540e9e6688a8047@haskell.org> #11018: ApiAnnotations: Add SourceText for unicode tokens -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alanz): mpickering, are you planning on tackling this? Looks like I may have some time now if not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 12 19:30:02 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Nov 2015 19:30:02 -0000 Subject: [GHC] #11018: ApiAnnotations: Add SourceText for unicode tokens In-Reply-To: <044.b2f994e490e36bcbf86a1f576ead0ae0@haskell.org> References: <044.b2f994e490e36bcbf86a1f576ead0ae0@haskell.org> Message-ID: <059.0876ec48a19bff24366602f44c0bcafc@haskell.org> #11018: ApiAnnotations: Add SourceText for unicode tokens -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): No. Go for it. For the purpose of this ticket, I will also add that I think adding a flag `IsUnicodeSyntax` is better than adding `SourceText`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 12 19:34:32 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Nov 2015 19:34:32 -0000 Subject: [GHC] #10942: CPP pragma ignored if top comments and Opt_KeepRawTokenStream In-Reply-To: <044.3dc1d52508bafa33dfb53526bcdd251c@haskell.org> References: <044.3dc1d52508bafa33dfb53526bcdd251c@haskell.org> Message-ID: <059.bcc512fdb47945f694620b30eefd2d57@haskell.org> #10942: CPP pragma ignored if top comments and Opt_KeepRawTokenStream -------------------------------------+------------------------------------- Reporter: alanz | Owner: mpickering Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 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 Rev(s): Phab:D1444 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"5d6133bec0f682e86ee31bbdb6d82e6fb2ede8f7/ghc" 5d6133b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5d6133bec0f682e86ee31bbdb6d82e6fb2ede8f7" Ignore comments in getOptions When Opt_KeepRawTokenStream is turned on then getOptions fails to find the language pragmas which can cause unexpected parse errors when using the GHC API. A simple solution is to make it skip over any comments in the token stream. Test Plan: ./validate Reviewers: austin, bgamari Subscribers: alanz, thomie Differential Revision: https://phabricator.haskell.org/D1444 GHC Trac Issues: #10942 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 12 19:35:01 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Nov 2015 19:35:01 -0000 Subject: [GHC] #10942: CPP pragma ignored if top comments and Opt_KeepRawTokenStream In-Reply-To: <044.3dc1d52508bafa33dfb53526bcdd251c@haskell.org> References: <044.3dc1d52508bafa33dfb53526bcdd251c@haskell.org> Message-ID: <059.f016f3fcd5355131e4db38cd224b9226@haskell.org> #10942: CPP pragma ignored if top comments and Opt_KeepRawTokenStream -------------------------------------+------------------------------------- Reporter: alanz | Owner: mpickering Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 (Parser) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1444 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 13 00:55:53 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Nov 2015 00:55:53 -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.c6d30017705bad8c3236c8994704f320@haskell.org> #8990: Performance tests behave differently depending on presence of .hi file (even with -fforce-recomp) -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * owner: przembot => * status: patch => new * differential: Phab:D1267 => Comment: On the Phabricator CR, Simon Marlow pointed out that pretending the interface file doesn't exist when forcing recompilation can result in gratuitous changes to the timestamp on the interface file. So we can't take this approach; let's just remove hi files before perf tests. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 13 01:18:56 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Nov 2015 01:18: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.bd9291417f72463a0f7218ef4ad3ad49@haskell.org> #10653: PatternSynonyms should be imported/exported as part of the wildcard notation -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: mpickering Type: feature request | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | 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 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): Hey guys, could we please get an update to `Note [Parents]` describing what it is meant when `Parent` is `PatternSynonym`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 13 01:27:01 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Nov 2015 01:27:01 -0000 Subject: [GHC] #9314: Each object file in a static archive file (.a) is loaded into its own mmap()ed page In-Reply-To: <052.69f389ede5e82026cc5c1d8ff164657e@haskell.org> References: <052.69f389ede5e82026cc5c1d8ff164657e@haskell.org> Message-ID: <067.6dca1e77631196941221906df6ae5620@haskell.org> #9314: Each object file in a static archive file (.a) is loaded into its own mmap()ed page -------------------------------------+------------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Runtime System | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hsyl20): I have created a diff to put the fix back: Phab:D1470 It shouldn't be an issue for perf-like tools because the mmap's I replaced with m32_alloc's were not mapping a file. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 13 03:16:38 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Nov 2015 03:16:38 -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.5b738933caeed9f06e2d1d04b2114fde@haskell.org> #8405: experiment with using function-sections for linking (for smaller libs and executables) -------------------------------------+------------------------------------- Reporter: carter | Owner: olsner Type: task | Status: closed Priority: normal | 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 Rev(s): Phab:D1242 Wiki Page: | -------------------------------------+------------------------------------- Comment (by refold): Awesome, thanks to everyone involved! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 13 03:36:23 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Nov 2015 03:36:23 -0000 Subject: [GHC] #11078: Access to module renaming with reifyModule, in TemplateHaskell In-Reply-To: <049.31454990f3b91e72bda5a21e4cbbf2c4@haskell.org> References: <049.31454990f3b91e72bda5a21e4cbbf2c4@haskell.org> Message-ID: <064.12d4b24f577c26d0d325c4928cf9c756@haskell.org> #11078: Access to module renaming with reifyModule, in TemplateHaskell -------------------------------------+------------------------------------- Reporter: cipher1024 | Owner: Type: feature request | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): > How hard do you think it will be to implement? I don't know. But I do know I don't have time to do this for 8.0, so if I'm the one implementing, then it is ? hard. But I'm happy to advise someone else. :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 13 06:38:57 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Nov 2015 06:38:57 -0000 Subject: [GHC] #10250: API Annotations : add Locations in hsSyn where layout occurs In-Reply-To: <044.e9f7429502526fbd11c0a38b5739b89e@haskell.org> References: <044.e9f7429502526fbd11c0a38b5739b89e@haskell.org> Message-ID: <059.6b6016d32660a8c00cb221d1e0b8b061@haskell.org> #10250: API Annotations : add Locations in hsSyn where layout occurs -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: task | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | Phab:D815,Phab:D1370 -------------------------------------+------------------------------------- Comment (by Alan Zimmerman ): In [changeset:"2290c8bd8c3faee0cb7dc1c2c7951bb9d5e3ebf9/ghc" 2290c8b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2290c8bd8c3faee0cb7dc1c2c7951bb9d5e3ebf9" APIAnnotations:add Locations in hsSyn for layout Summary: At the moment ghc-exactprint, which uses the GHC API Annotations to provide a framework for roundtripping Haskell source code with optional AST edits, has to implement a horrible workaround to manage the points where layout needs to be captured. These are MatchGroup HsDo HsCmdDo HsLet LetStmt HsCmdLet GRHSs To provide a more natural representation, the contents subject to layout rules need to be wrapped in a SrcSpan. This commit does this. Trac ticket #10250 Test Plan: ./validate Reviewers: hvr, goldfire, bgamari, austin, mpickering Reviewed By: mpickering Subscribers: thomie, mpickering Differential Revision: https://phabricator.haskell.org/D1370 GHC Trac Issues: #10250 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 13 07:20:00 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Nov 2015 07:20:00 -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.02cdefbd68afdc1e278d1c86b0584464@haskell.org> #10061: Remove fun_infix from Funbind, as it is now in Match -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1-rc2 Resolution: fixed | 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 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 13 09:14:41 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Nov 2015 09:14:41 -0000 Subject: [GHC] #11071: "Not in scope" errors should be more informative for qualified names. In-Reply-To: <047.e970b72d66ebf0753d36739a65af99a0@haskell.org> References: <047.e970b72d66ebf0753d36739a65af99a0@haskell.org> Message-ID: <062.ef7781673cb5f8368cec12309b6b1227@haskell.org> #11071: "Not in scope" errors should be more informative for qualified names. -------------------------------------+------------------------------------- Reporter: mojojojo | Owner: nomeata Type: feature request | 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 Rev(s): Phab:D1462 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"e66f79dfb22031dd3f75dd3eb341e8269ab51d83/ghc" e66f79df/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e66f79dfb22031dd3f75dd3eb341e8269ab51d83" Give helpful advice when a fully qualified name is not in scope This implements #11071. It needs to thread through a GlobalRdrEnv corresponding to the export list of the module if its exports were not restricted. A refactoring of ImportedModsVal into a proper data type follows. Differential Revision: https://phabricator.haskell.org/D1462 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 13 09:26:06 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Nov 2015 09:26:06 -0000 Subject: [GHC] #11071: "Not in scope" errors should be more informative for qualified names. In-Reply-To: <047.e970b72d66ebf0753d36739a65af99a0@haskell.org> References: <047.e970b72d66ebf0753d36739a65af99a0@haskell.org> Message-ID: <062.9b366217eee9caa4dff998f0749213fc@haskell.org> #11071: "Not in scope" errors should be more informative for qualified names. -------------------------------------+------------------------------------- Reporter: mojojojo | Owner: nomeata Type: feature request | 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 Rev(s): Phab:D1462 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): First version landed. I?ll leave this open to implement thomie?s suggestions (which will necessarily include a special case for this: {{{ foo is not in scope. You have not imported anything, not even Prelude. You are on your own! }}} (The more common, new cases will be: Printing nothing if no restricted import exists or no restricted import exports `foo`, and the usual list from above if one or more restricted unqualified import could be made to provide `foo`.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 13 10:13:59 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Nov 2015 10:13: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.cae22a04047115657f28f4a6ee43c115@haskell.org> #10653: PatternSynonyms should be imported/exported as part of the wildcard notation -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: mpickering Type: feature request | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | 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 Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I have added a note now. Is that clearer? Do you think more explanation is needed? https://github.com/ghc/ghc/commit/8868ff3eb742977c5de2609f7d748f4ff8882d6d -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 13 11:17:43 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Nov 2015 11:17:43 -0000 Subject: [GHC] #10989: :ctags and :etags command can receive haskell source files as a parameter In-Reply-To: <045.de3e950ef6c4dee2c0f5411e366ebc4e@haskell.org> References: <045.de3e950ef6c4dee2c0f5411e366ebc4e@haskell.org> Message-ID: <060.6e822fc3c4763fcd639df8f323d5394c@haskell.org> #10989: :ctags and :etags command can receive haskell source files as a parameter -------------------------------------+------------------------------------- Reporter: hugomg | Owner: tvv Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.10.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://phabricator.haskell.org/D1471 -------------------------------------+------------------------------------- Changes (by tvv): * differential: => https://phabricator.haskell.org/D1471 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 13 12:30:45 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Nov 2015 12:30:45 -0000 Subject: [GHC] #10678: integer-gmp's runS seems unnecessarily expensive In-Reply-To: <047.1e3027d49179affc6473e88cc8dec51a@haskell.org> References: <047.1e3027d49179affc6473e88cc8dec51a@haskell.org> Message-ID: <062.c731c9bdb5178d39ee976f3bcacd31b9@haskell.org> #10678: integer-gmp's runS seems unnecessarily expensive -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 (CodeGen) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1103 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): https://perf.haskell.org/ghc/#revision/351de169e14ad9277aaca653df4a3753c151f7bb looks great, good job! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 13 13:03:39 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Nov 2015 13:03:39 -0000 Subject: [GHC] #10989: :ctags and :etags command can receive haskell source files as a parameter In-Reply-To: <045.de3e950ef6c4dee2c0f5411e366ebc4e@haskell.org> References: <045.de3e950ef6c4dee2c0f5411e366ebc4e@haskell.org> Message-ID: <060.bc7bcd8ebbe3f43c9e6812ebd2f80b71@haskell.org> #10989: :ctags and :etags command can receive haskell source files as a parameter -------------------------------------+------------------------------------- Reporter: hugomg | Owner: tvv Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.10.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1471 Wiki Page: | -------------------------------------+------------------------------------- Changes (by tvv): * differential: https://phabricator.haskell.org/D1471 => Phab:D1471 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 13 13:14:31 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Nov 2015 13:14:31 -0000 Subject: [GHC] #10989: :ctags and :etags command can receive haskell source files as a parameter In-Reply-To: <045.de3e950ef6c4dee2c0f5411e366ebc4e@haskell.org> References: <045.de3e950ef6c4dee2c0f5411e366ebc4e@haskell.org> Message-ID: <060.d2b06c08b3ca5d54b5c17eaff12bc790@haskell.org> #10989: :ctags and :etags command can receive haskell source files as a parameter -------------------------------------+------------------------------------- Reporter: hugomg | Owner: tvv Type: feature request | Status: patch Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.10.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1471 Wiki Page: | -------------------------------------+------------------------------------- Changes (by tvv): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 13 13:28:34 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Nov 2015 13:28:34 -0000 Subject: [GHC] #11072: Runtime linker doesn't search for DLLs referenced in import libraries on Windows In-Reply-To: <050.675e99e0c3128be1426b83f1c6310ea3@haskell.org> References: <050.675e99e0c3128be1426b83f1c6310ea3@haskell.org> Message-ID: <065.1eafc34f8b63a1112ea61cc312ca7c02@haskell.org> #11072: Runtime linker doesn't search for DLLs referenced in import libraries on Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2-rc2 (Linking) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Matt): I have been playing with this for few months now and i have my own patched GHC that can in rather hackish way resolve real DLL name from import library. It does so by guessing it from 2 symbol names that only seem to appear in import libraries. However its not 100% accurate. I have been looking for better way to find that info and and so far i found that in all import libraries DLL name seems to be in {{{.idata$7}}} section in some random object file. Also most object files have {{{.idata$7}}} section, but all but that one have either no data associated with it or some have just NULLs stored in there. I'm now working on little test program that will parse import library and try to extract DLL name from {{{.idata$7}}} section. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 13 13:48:21 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Nov 2015 13:48:21 -0000 Subject: [GHC] #11081: Implement Introspective Template Haskell Message-ID: <047.67eb7661a40be634ed16872d272a44ca@haskell.org> #11081: Implement Introspective Template Haskell -------------------------------------+------------------------------------- Reporter: goldfire | 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 Rev(s): | Wiki Page: | TemplateHaskell/Introspective -------------------------------------+------------------------------------- This ticket is to track commentary and reactions to TemplateHaskell/Introspective, and to help the proposal not get lost. Contrary to the title of this ticket, it is not yet resolved that Introspective Template Haskell should ever be implemented. But with some of the support that it's gotten, it seemed appropriate to make a ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 13 13:56:26 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Nov 2015 13:56:26 -0000 Subject: [GHC] #11081: Implement Introspective Template Haskell In-Reply-To: <047.67eb7661a40be634ed16872d272a44ca@haskell.org> References: <047.67eb7661a40be634ed16872d272a44ca@haskell.org> Message-ID: <062.00b8e0cb22560f14153f8c17a52d7ce1@haskell.org> #11081: Implement Introspective Template Haskell -------------------------------------+------------------------------------- Reporter: goldfire | 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 Rev(s): Wiki Page: | TemplateHaskell/Introspective | -------------------------------------+------------------------------------- Changes (by jstolarek): * cc: jstolarek (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 13 13:59:17 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Nov 2015 13:59:17 -0000 Subject: [GHC] #11080: Open data kinds In-Reply-To: <047.64e06093644ddd3cb76b94e28bef420a@haskell.org> References: <047.64e06093644ddd3cb76b94e28bef420a@haskell.org> Message-ID: <062.79714fd78f9125e1cdea18ec3811ed48@haskell.org> #11080: Open data kinds -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: Type: feature request | Status: new Priority: low | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Simon PJ, Stephanie Weirich, Andres L?h, Kenny Foner, and I discussed this recently, and we didn't spot any problems with the proposal, neither in terms of theory nor implementation. * Question: can open kinds be parameterized? Answer: Yes. Example: {{{ data open Dimension :: * data constructor Length :: Dimension data open Unit :: Dimension -> * data constructor Meter :: Unit 'Length data constructor Foot :: Unit 'Length }}} * Alternative syntax: `data constructor` is noisy. Just omit, allowing a declaration like `Length :: Dimension`. Objection: this overlaps with a naked top-level Template Haskell splice. * Alternative syntax: `data constructor` is noisy. How about this: {{{ data open Unit :: * data extension Unit where Meter :: Unit Foot :: Unit }}} My (Richard's) objection: But this grouping of `Meter` and `Foot` is meaningless. Breaking up the group is the same as grouping. It's just syntactic. But this isn't a hard objection if others like the idea. * Related topic: What about other design points as explored in comment:6:ticket:9840? In particular, how does this relate to non- generative, non-injective symbols whose equational theory is given by a plugin? (Non-generative, non-injective symbols whose equational theory is given by GHC are known as type families.) Defining such a symbol was the point of #9840 to begin with, and we settled on an empty closed type family as the nearest approximation. After some discussion, it seemed that the open kind proposal was separate enough that these don't need to be considered together. But a suggestion for a unifying syntax would be welcome! Bottom line: let's do it, once we decide on a syntax. I still favor the syntax proposed, with `data constructor`. Other opinions are welcome. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 13 14:17:20 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Nov 2015 14:17:20 -0000 Subject: [GHC] #11082: Tweak workflow around overlong lines Message-ID: <047.824d6cc980bf9acce584f8e65211c327@haskell.org> #11082: Tweak workflow around overlong lines -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Build System | 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): | Wiki Page: -------------------------------------+------------------------------------- [https://mail.haskell.org/pipermail/ghc-devs/2015-November/010373.html This thread] discussed potential changes to the way the GHC dev workflow deals with overlong lines. This ticket summarizes the discussion. '''Initial complaint:''' arc/Phab is too heavy-handed about overlong lines. Almost all patchers have to write a vacuous "explanation" for them, and the overlong line warnings clutter code reviews. '''Initial suggestion:''' After `arc diff` is run, it will count the number of overlong lines before and after the patch. If there are more after, have the last thing `arc diff` outputs be a stern telling-off of the dev, along the lines of {{{ Before your patch, 15 of the edited lines were over 80 characters. Now, a whopping 28 of them are. Can't you do better? Please? }}} '''Reactions:''' * +1 * Even the delta in overlong lines is bad, because perhaps a small refactor added to the length of an identifier. * We might just want to reject code with overlong lines. Then the problem would really go away. It favors one-time work over many-time maintenance burden. (Austin's point, +1 by Alexander Berntsen) * This would cause more work and would increase the barrier to contribution. And sometimes it's appropriate/more readable to have overlong lines. * 80 is too small. 120 (SPJ)? 132 (Ed Kmett)? * And a small limit discourages informative identifiers. * Just drop the column limit entirely. * Why 80? Because two 80-column buffers fit nicely side-by-side on small laptop screens. Three such columns fit nicely on monitors. Several (4 emails) echoed this point. Bottom line: no one expressed liking the status quo (though Simon M called it "not terrible"). If we're to choose a limit, a choice of 80 seemed to appease the plurality of respondents. Two respondents advocate enforcing the limit. I count four respondents rejecting hard enforcement. In my (surely biased) view, this means that we should implement my original proposal. :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 13 14:38:29 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Nov 2015 14:38:29 -0000 Subject: [GHC] #11082: Tweak workflow around overlong lines In-Reply-To: <047.824d6cc980bf9acce584f8e65211c327@haskell.org> References: <047.824d6cc980bf9acce584f8e65211c327@haskell.org> Message-ID: <062.60bfab37d21e364040ba484c3e9431ab@haskell.org> #11082: Tweak workflow around overlong lines -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: task | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I also like your original proposal. This technique is known as ratcheting (http://chrisstevenson.me/development/2008/03/11/fixing-broken-windows- with-ratcheting.html). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 13 15:19:45 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Nov 2015 15:19:45 -0000 Subject: [GHC] #11082: Tweak workflow around overlong lines In-Reply-To: <047.824d6cc980bf9acce584f8e65211c327@haskell.org> References: <047.824d6cc980bf9acce584f8e65211c327@haskell.org> Message-ID: <062.2cb3efed68569c7483db3afa4f4cd952@haskell.org> #11082: Tweak workflow around overlong lines -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: task | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): In the module I'm editing today `rnStmtsWithFreeVars` has 18 characters, or 25% of my total column budget, not counting the (essential) indentation. I hear what you say about laptop screens, and I'll accept the Will of the majority, but 80 still seems terribly short to me. In these days of wide- screen format for movies, can you really not get more than two columns of 80 chars? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 13 16:06:31 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Nov 2015 16:06:31 -0000 Subject: [GHC] #11047: Provide call stacks in GHCi In-Reply-To: <047.3eb9c7a7d6579e45d15f3dffd3ade555@haskell.org> References: <047.3eb9c7a7d6579e45d15f3dffd3ade555@haskell.org> Message-ID: <062.4912a345065e72da82d3ffcb48be569e@haskell.org> #11047: Provide call stacks in GHCi -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #545, #4837 | Differential Rev(s): Phab:D1407 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Marlow ): In [changeset:"8988be8561ce0857f3befd6ab3b6c29060685c0a/ghc" 8988be8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8988be8561ce0857f3befd6ab3b6c29060685c0a" Make 'error' include the CCS call stack when profiled Summary: The idea here is that this gives a more detailed stack trace in two cases: 1. With `-prof` and `-fprof-auto` 2. In GHCi (see #11047) Example, with an error inserted in nofib/shootout/binary-trees: ``` $ ./Main 3 Main: z CallStack (from ImplicitParams): error, called at Main.hs:67:29 in main:Main CallStack (from -prof): Main.check' (Main.hs:(67,1)-(68,82)) Main.check (Main.hs:63:1-21) Main.stretch (Main.hs:32:35-57) Main.main.c (Main.hs:32:9-57) Main.main (Main.hs:(27,1)-(43,42)) Main.CAF () ``` This doesn't quite obsolete +RTS -xc, which also attempts to display more information in the case when the error is in a CAF, but I'm exploring other solutions to that. Includes submodule updates. Test Plan: validate Reviewers: simonpj, ezyang, gridaphobe, bgamari, hvr, austin Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1426 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 13 17:54:05 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Nov 2015 17:54:05 -0000 Subject: [GHC] #11082: Tweak workflow around overlong lines In-Reply-To: <047.824d6cc980bf9acce584f8e65211c327@haskell.org> References: <047.824d6cc980bf9acce584f8e65211c327@haskell.org> Message-ID: <062.dbcfadb0bde698234189d7925f8930e5@haskell.org> #11082: Tweak workflow around overlong lines -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: task | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jstolarek): Copy-paste from ghc-devs (since Richard requested): Firstly, I hate explaining myself to Arcanist. When prompted to explain the reason for too long lines I typically enter "wontfix" without thinking too much. Secondly, I really don't like how warnings clutter code reviews. I have my Emacs highlight text beyond 80th column with a really ugly colour, so I strive real hard to maintain 80-column limit whenever possible. But sometimes fitting in that limit is nearly impossible: imagine being in a let nested in a do-notation nested in a guard nested in a where clause. Approx. 15-20 columns are lost for the indentation. Nevertheless I would support introducing a hard limit on having no more than 80 columns. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 13 17:55:35 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Nov 2015 17:55:35 -0000 Subject: [GHC] #11082: Tweak workflow around overlong lines In-Reply-To: <047.824d6cc980bf9acce584f8e65211c327@haskell.org> References: <047.824d6cc980bf9acce584f8e65211c327@haskell.org> Message-ID: <062.bce51e5db2e6cd8460629a5283ec7670@haskell.org> #11082: Tweak workflow around overlong lines -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: task | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by diatchki): I'd also vote for formatting that fits in 80 characters. I typically work with two editors open next to each other: usually one for editing code, and one for browsing code, and it is really nice not to have to constantly scroll or switch between windows. I follow the 80 character limit on all projects I work with, and I find that it is not very hard to format code to fit in the window, even when there are long name. To do that I either use more but shorter lines, or I name large sub-expressions. I think both of those contribute to the readability of the code. Of course, that's quite subjective. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 13 18:15:22 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Nov 2015 18:15:22 -0000 Subject: [GHC] #11080: Open data kinds In-Reply-To: <047.64e06093644ddd3cb76b94e28bef420a@haskell.org> References: <047.64e06093644ddd3cb76b94e28bef420a@haskell.org> Message-ID: <062.a387b39b8dfa50a90be7508bceda19ff@haskell.org> #11080: Open data kinds -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: Type: feature request | Status: new Priority: low | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jstolarek): Can I join in? I'd like to work on the implementation. Unless someone has already volunteered? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 13 20:43:15 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Nov 2015 20:43:15 -0000 Subject: [GHC] #11078: Access to module renaming with reifyModule, in TemplateHaskell In-Reply-To: <049.31454990f3b91e72bda5a21e4cbbf2c4@haskell.org> References: <049.31454990f3b91e72bda5a21e4cbbf2c4@haskell.org> Message-ID: <064.83d872c04ba1216dcd5d42c0a7a52b3d@haskell.org> #11078: Access to module renaming with reifyModule, in TemplateHaskell -------------------------------------+------------------------------------- Reporter: cipher1024 | Owner: Type: feature request | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I think I can implement this. When's the deadline for 8.0 patches? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 13 20:51:19 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Nov 2015 20:51:19 -0000 Subject: [GHC] #11083: Documentation clarification for Data.List.isSubsequenceOf Message-ID: <043.e69eb5fdb16ef2a225fec4c141703786@haskell.org> #11083: Documentation clarification for Data.List.isSubsequenceOf -------------------------------------+------------------------------------- Reporter: jura | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Documentation | Version: 7.10.2 Keywords: Data.List, | Operating System: Unknown/Multiple isSubsequenceOf | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In order to clarify the difference between isInfixOf and isSubsequenceOf, I submit a patch which changes the wording from "The 'isSubsequenceOf' function takes two lists and returns 'True' if the first list is a subsequence of the second list." to "The 'isSubsequenceOf' function takes two lists and returns 'True' if all the elements of the first list occur, in order, in the second. The elements do not have to occur consecutively." -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 13 20:52:02 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Nov 2015 20:52:02 -0000 Subject: [GHC] #11083: Documentation clarification for Data.List.isSubsequenceOf In-Reply-To: <043.e69eb5fdb16ef2a225fec4c141703786@haskell.org> References: <043.e69eb5fdb16ef2a225fec4c141703786@haskell.org> Message-ID: <058.1ddad8fcf34ee6fbb24c076d538365ed@haskell.org> #11083: Documentation clarification for Data.List.isSubsequenceOf -------------------------------------+------------------------------------- Reporter: jura | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Documentation | Version: 7.10.2 Resolution: | Keywords: Data.List, | isSubsequenceOf Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jura): * Attachment "0001-Data.List.isSubsequenceOf-documentation- clarificatio.patch" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 13 22:58:01 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Nov 2015 22:58:01 -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.55d347f3a1702397684cc6a4e5e1bd18@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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AlexanderThiemann): Just a side note: the same thing happens when you use `instance` instead of `type`. This is probably broken for all "reserved" identifiers? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 14 00:42:13 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Nov 2015 00:42:13 -0000 Subject: [GHC] #8947: Depending on hint/ghc API fixes the binary version I can use In-Reply-To: <042.0b84808e71990b7e49b9c7a55ecf27f4@haskell.org> References: <042.0b84808e71990b7e49b9c7a55ecf27f4@haskell.org> Message-ID: <057.7e32c126ef8c77d746303e4acb9911b6@haskell.org> #8947: Depending on hint/ghc API fixes the binary version I can use -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * keywords: backpack => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 14 00:43:05 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Nov 2015 00:43:05 -0000 Subject: [GHC] #10622: Rename Backpack packages to units In-Reply-To: <045.e723515149f295a7a83a3d60032cca8e@haskell.org> References: <045.e723515149f295a7a83a3d60032cca8e@haskell.org> Message-ID: <060.9887b18f23bf0fdddf8cc1fbcc071504@haskell.org> #10622: Rename Backpack packages to units -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1057 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => fixed Comment: This was fixed in b92a51f5e235fc22a9ae0d76735b50f095665fb7 and 5b0191f74ab05b187f81ea037623338a615b1619 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 14 00:43:44 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Nov 2015 00:43:44 -0000 Subject: [GHC] #10690: Save merged signatures to disk In-Reply-To: <045.25a62546e19528fda1b12c19e43ea653@haskell.org> References: <045.25a62546e19528fda1b12c19e43ea653@haskell.org> Message-ID: <060.61807d621b2db351162fa614f366b4e1@haskell.org> #10690: Save merged signatures to disk -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: closed Priority: normal | Milestone: 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 Rev(s): Phab:D1098 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => fixed Comment: This was committed to HEAD but we're going to take a different approach to this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 14 00:46:03 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Nov 2015 00:46:03 -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.af15bf52d933362280c824eea49818cd@haskell.org> #10871: Implement "fat" interface files which can be directly compiled without source -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: lowest | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * priority: normal => lowest Comment: We have decided to can fat interfaces for Backpack. There might be other uses for this feature but this patchset will have to be picked up when there's another customer for the use-case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 14 01:38:19 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Nov 2015 01:38:19 -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.23d9fd428e9f11d578641a71a1f22efc@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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Yes, that's right. I hope to fix this for 8.0, but time is short right now! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 14 02:12:09 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Nov 2015 02:12:09 -0000 Subject: [GHC] #11084: Some type families don't reduce with :kind! Message-ID: <047.af59c4538fa4f004723d249cfac399d5@haskell.org> #11084: Some type families don't reduce with :kind! -------------------------------------+------------------------------------- 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 Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Sadly, I'm unable to reproduce this without `singletons`. :( Observe: {{{ > ghci GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help Prelude> import Data.Promotion.Prelude -- singletons-2.0.1 Prelude Data.Promotion.Prelude> :kind! Lookup 'True '[ '(True, True) ] Lookup 'True '[ '(True, True) ] :: Maybe Bool = Data.Singletons.Prelude.List.Case_1628035408 'True 'True 'True '[] (Data.Singletons.Apply (Data.Singletons.Apply (:==$) 'True) 'True) Prelude Data.Promotion.Prelude> :kind! Lookup 'True '[ '(True, True) ] Lookup 'True '[ '(True, True) ] :: Maybe Bool = JustSym1 'True }}} Note that the exact same command run twice yields different results. I tried peeking at `-ddump-tc-trace` but got nothing of use. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 14 15:43:37 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Nov 2015 15:43:37 -0000 Subject: [GHC] #11080: Open data kinds In-Reply-To: <047.64e06093644ddd3cb76b94e28bef420a@haskell.org> References: <047.64e06093644ddd3cb76b94e28bef420a@haskell.org> Message-ID: <062.f72bcf5ab44302a92b78e793981b5533@haskell.org> #11080: Open data kinds -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: Type: feature request | Status: new Priority: low | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dmcclean): I'm not sure who you're asking, but I'll weigh in that as far as I know nobody has begun any implementation work yet and your contribution would probably be welcome. Personally implementing this is way over my head, so I can't offer to help myself. I do like the alternative syntax proposal `data Extension Unit where ...`. It's true that the grouping is semantically meaningless, but it does seem more similar to existing syntax. Also if this were to later be extended to allow adding new constructors to open types of kind `*` this syntax would seem to more naturally support adding new GADT style constructors. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 14 16:26:45 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Nov 2015 16:26:45 -0000 Subject: [GHC] #11072: Runtime linker doesn't search for DLLs referenced in import libraries on Windows In-Reply-To: <050.675e99e0c3128be1426b83f1c6310ea3@haskell.org> References: <050.675e99e0c3128be1426b83f1c6310ea3@haskell.org> Message-ID: <065.df5d9913104179560e781fa859b19f53@haskell.org> #11072: Runtime linker doesn't search for DLLs referenced in import libraries on Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2-rc2 (Linking) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Hi Matt, I am happy for you to take this over if you want. I haven't had the time to start on it yet or to take a look at what's involved in implementing it. So it is still up for grabs :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 14 16:40:00 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Nov 2015 16:40:00 -0000 Subject: [GHC] #11085: Relying on the existence of CallStack in 7.10 breaks bootstrappability with 7.10.1 Message-ID: <045.d96082fb405c80a5f3677e98b1672baa@haskell.org> #11085: Relying on the existence of CallStack in 7.10 breaks bootstrappability with 7.10.1 -------------------------------------+------------------------------------- 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: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): D1472 | Wiki Page: -------------------------------------+------------------------------------- 7.10.2 added the CallStack mechanism, and GHC already relies on this while being built. Unfortunately, it is enabled with "GLASGOW_HASKELL >= 710", which also applies to GHC 7.10.1, which does not have CallStack, and fails building the stage-1 compiler because the symbol is not found. This patch makes the CPP directive more strict, requiring more than 7.10 instead of at least. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 14 16:40:23 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Nov 2015 16:40:23 -0000 Subject: [GHC] #11085: Relying on the existence of CallStack in 7.10 breaks bootstrappability with 7.10.1 In-Reply-To: <045.d96082fb405c80a5f3677e98b1672baa@haskell.org> References: <045.d96082fb405c80a5f3677e98b1672baa@haskell.org> Message-ID: <060.0959565e0bce08ce6e585b95044f08ee@haskell.org> #11085: Relying on the existence of CallStack in 7.10 breaks bootstrappability with 7.10.1 -------------------------------------+------------------------------------- Reporter: quchen | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D1472 Wiki Page: | -------------------------------------+------------------------------------- Changes (by quchen): * status: new => patch * version: 7.10.2 => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 14 16:48:45 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Nov 2015 16:48:45 -0000 Subject: [GHC] #11085: Relying on the existence of CallStack in 7.10 breaks bootstrappability with 7.10.1 In-Reply-To: <045.d96082fb405c80a5f3677e98b1672baa@haskell.org> References: <045.d96082fb405c80a5f3677e98b1672baa@haskell.org> Message-ID: <060.260c61747e16738a0dc4c00662dbb70f@haskell.org> #11085: Relying on the existence of CallStack in 7.10 breaks bootstrappability with 7.10.1 -------------------------------------+------------------------------------- Reporter: quchen | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D1472 Wiki Page: | -------------------------------------+------------------------------------- Comment (by quchen): Patch is on Phab. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 14 16:53:59 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Nov 2015 16:53:59 -0000 Subject: [GHC] #11085: Relying on the existence of CallStack in 7.10 breaks bootstrappability with 7.10.1 In-Reply-To: <045.d96082fb405c80a5f3677e98b1672baa@haskell.org> References: <045.d96082fb405c80a5f3677e98b1672baa@haskell.org> Message-ID: <060.850466fd85acd0a18e9acd4e2ff4aeff@haskell.org> #11085: Relying on the existence of CallStack in 7.10 breaks bootstrappability with 7.10.1 -------------------------------------+------------------------------------- Reporter: quchen | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1472 Wiki Page: | -------------------------------------+------------------------------------- Changes (by quchen): * differential: D1472 => Phab:D1472 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 14 17:26:05 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Nov 2015 17:26:05 -0000 Subject: [GHC] #11018: ApiAnnotations: Add SourceText for unicode tokens In-Reply-To: <044.b2f994e490e36bcbf86a1f576ead0ae0@haskell.org> References: <044.b2f994e490e36bcbf86a1f576ead0ae0@haskell.org> Message-ID: <059.df86056a250bf888a866253b73d9ec44@haskell.org> #11018: ApiAnnotations: Add SourceText for unicode tokens -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1473 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * differential: => Phab:D1473 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 14 17:49:44 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Nov 2015 17:49:44 -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.778972698ee8f60e5ca1097709a9466d@haskell.org> #8405: experiment with using function-sections for linking (for smaller libs and executables) -------------------------------------+------------------------------------- Reporter: carter | Owner: olsner Type: task | Status: closed Priority: normal | 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 Rev(s): Phab:D1242 Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): Wow. Great! Would this make it practical to disable stripping on libraries and executables (so that dwarf metadata could be available by default?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 14 18:37:47 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Nov 2015 18:37:47 -0000 Subject: [GHC] #11018: ApiAnnotations: Add SourceText for unicode tokens In-Reply-To: <044.b2f994e490e36bcbf86a1f576ead0ae0@haskell.org> References: <044.b2f994e490e36bcbf86a1f576ead0ae0@haskell.org> Message-ID: <059.6f1d39a130505a48daf90e2f69f57213@haskell.org> #11018: ApiAnnotations: Add SourceText for unicode tokens -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1473 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 14 19:01:25 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Nov 2015 19:01:25 -0000 Subject: [GHC] #11091: Fix MonadFail warnings Message-ID: <045.9ee4c703624749a10bd1943bc0d2d686@haskell.org> #11091: Fix MonadFail warnings -------------------------------------+------------------------------------- Reporter: quchen | Owner: Type: task | Status: new Priority: low | Milestone: 8.2.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 Rev(s): | Wiki Page: -------------------------------------+------------------------------------- #10751 implements the MonadFail warning mechanism. Using `-fwarn-missing-monadfail-instance`, GHC's internal warnings created by the patch can be shown and fixed. A second pass with `-XMonadFailDesugaring` then provides a hard check on whether any issues remain, by switching on the new desugaring mechanism properly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 14 19:55:57 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Nov 2015 19:55:57 -0000 Subject: [GHC] #11076: Demand information of foreign calls is wrong In-Reply-To: <044.34bd2569f92bdaaaa2887dd523555186@haskell.org> References: <044.34bd2569f92bdaaaa2887dd523555186@haskell.org> Message-ID: <059.48c6308b83778c91e83c22ecb974b7f2@haskell.org> #11076: Demand information of foreign calls is wrong -------------------------------------+------------------------------------- Reporter: luite | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.3 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 Rev(s): Phab:D1464 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 14 19:56:26 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Nov 2015 19:56:26 -0000 Subject: [GHC] #11064: Call Arity has the trivial application case wrong In-Reply-To: <046.eb4c820640d5d418fe2e5ee76141b9f5@haskell.org> References: <046.eb4c820640d5d418fe2e5ee76141b9f5@haskell.org> Message-ID: <061.8011865afe351ca88668d626bc1fe907@haskell.org> #11064: Call Arity has the trivial application case wrong -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: closed Priority: normal | Milestone: 7.10.3 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 14 19:58:08 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Nov 2015 19:58: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.3ba5628e10bbbe69209f429ccd8db938@haskell.org> #10830: maximumBy has a space leak -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 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 Rev(s): Phab:D1205 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 7.10.3 => 8.0.1 Comment: Oops! Sorry, I overlooked that. I'm going to re-milestone to 8.0 since there is currently no fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 14 19:59:08 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Nov 2015 19:59:08 -0000 Subject: [GHC] #10667: '-g' option generates invalid assembly when '*/*' operator is used In-Reply-To: <045.7de7e3e8915f886ced608adea09f7f67@haskell.org> References: <045.7de7e3e8915f886ced608adea09f7f67@haskell.org> Message-ID: <060.fe285a796b2498a2d5e280237f140ae4@haskell.org> #10667: '-g' option generates invalid assembly when '*/*' operator 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: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1386 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 14 20:00:49 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Nov 2015 20:00:49 -0000 Subject: [GHC] #10997: Pattern synonym causes Iface error. In-Reply-To: <049.dc8e40260dd5587e1caf4aff1723e027@haskell.org> References: <049.dc8e40260dd5587e1caf4aff1723e027@haskell.org> Message-ID: <064.4fffd0b63401dac6b5ad3dda3f45f573@haskell.org> #10997: Pattern synonym causes Iface error. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | patsyn/should_compile/T10997, | T10997_1 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 14 20:48:38 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Nov 2015 20:48:38 -0000 Subject: [GHC] #11085: Relying on the existence of CallStack in 7.10 breaks bootstrappability with 7.10.1 In-Reply-To: <045.d96082fb405c80a5f3677e98b1672baa@haskell.org> References: <045.d96082fb405c80a5f3677e98b1672baa@haskell.org> Message-ID: <060.12d5987d475726dac74accdc3f7f71d9@haskell.org> #11085: Relying on the existence of CallStack in 7.10 breaks bootstrappability with 7.10.1 -------------------------------------+------------------------------------- Reporter: quchen | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1472 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"54884220cd8f68bcb4291cc3689d69258b835f6f/ghc" 54884220/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="54884220cd8f68bcb4291cc3689d69258b835f6f" Fix bootstrapping with GHC 7.10.1 Relying on CallStack being in GLASGOW_HASKELL >= 710 breaks bootstrappability with 7.10.1 7.10.2 added the CallStack mechanism, and GHC already relies on this while being built. Unfortunately, it is enabled with "GLASGOW_HASKELL >= 710", which also applies to GHC 7.10.1, which does not have CallStack, and fails building the stage-1 compiler because the symbol is not found. This patch makes the CPP directive more strict, requiring **more than** 7.10 instead of **at least**. Reviewers: jstolarek, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1472 GHC Trac Issues: #11085 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 14 21:37:13 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Nov 2015 21:37:13 -0000 Subject: [GHC] #8347: Add a Strict LANGUAGE pragma In-Reply-To: <044.d01bb368b2606104539d1aa05530b018@haskell.org> References: <044.d01bb368b2606104539d1aa05530b018@haskell.org> Message-ID: <059.d0f1308ac4c634862deee1430e68bb91@haskell.org> #8347: Add a Strict LANGUAGE pragma -------------------------------------+------------------------------------- Reporter: tibbe | Owner: adamse Type: feature request | 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: DsStrictData Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1033, | Phab:D1142 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"46a03fbec6a02761db079d1746532565f34c340f/ghc" 46a03fb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="46a03fbec6a02761db079d1746532565f34c340f" Implement the Strict language extension Add a new language extension `-XStrict` which turns all bindings strict as if the programmer had written a `!` before it. This also upgrades ordinary Haskell to allow recursive and polymorphic strict bindings. See the wiki[1] and the Note [Desugar Strict binds] in DsBinds for specification and implementation details. [1] https://ghc.haskell.org/trac/ghc/wiki/StrictPragma Reviewers: austin, tibbe, simonpj, bgamari Reviewed By: tibbe, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1142 GHC Trac Issues: #8347 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 14 21:45:37 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Nov 2015 21:45:37 -0000 Subject: [GHC] #11085: Relying on the existence of CallStack in 7.10 breaks bootstrappability with 7.10.1 In-Reply-To: <045.d96082fb405c80a5f3677e98b1672baa@haskell.org> References: <045.d96082fb405c80a5f3677e98b1672baa@haskell.org> Message-ID: <060.526b739fa6dde98f25adb9b8cbef23b3@haskell.org> #11085: Relying on the existence of CallStack in 7.10 breaks bootstrappability with 7.10.1 -------------------------------------+------------------------------------- Reporter: quchen | 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: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1472 Wiki Page: | -------------------------------------+------------------------------------- Changes (by quchen): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 15 03:26:01 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Nov 2015 03:26:01 -0000 Subject: [GHC] #11078: Access to module renaming with reifyModule, in TemplateHaskell In-Reply-To: <049.31454990f3b91e72bda5a21e4cbbf2c4@haskell.org> References: <049.31454990f3b91e72bda5a21e4cbbf2c4@haskell.org> Message-ID: <064.ce3033e6bf76b1c67bc159a1fdcd2e7a@haskell.org> #11078: Access to module renaming with reifyModule, in TemplateHaskell -------------------------------------+------------------------------------- Reporter: cipher1024 | Owner: Type: feature request | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I tried to implement this but as also noted by @goldfire I don't think we have necessary information in `TcM` for this change. One way to pass necessary information to type checker might be to pass `HsRnModule` in `tcRnModule` to `initTc`, and `initTc` would then record it in `TcGblEnv` or `TcLclEnv` (I don't know the difference yet). @goldfire, do you have any ideas about this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 15 08:34:09 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Nov 2015 08:34:09 -0000 Subject: [GHC] #11092: ApiAnnotations : make annotation for shebang Message-ID: <044.0bd4290eed8d430160dff757f59d13b8@haskell.org> #11092: ApiAnnotations : make annotation for shebang -------------------------------------+------------------------------------- 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): | Wiki Page: -------------------------------------+------------------------------------- Currently a valid haskell file can have a first line of the form {{{#!lhs #!/usr/bin/env runhaskell }}} This does not end up as anything that can have an API Annotation, and so gets lost on round tripping. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 15 09:21:44 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Nov 2015 09:21:44 -0000 Subject: [GHC] #11019: ApiAnnotations: Make all RdrName occurences Located In-Reply-To: <044.6f9b0661f882f5c32756a32bbf81653d@haskell.org> References: <044.6f9b0661f882f5c32756a32bbf81653d@haskell.org> Message-ID: <059.70d4ca6ae4336159565b721357bb34bc@haskell.org> #11019: ApiAnnotations: Make all RdrName occurences Located -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alanz): It is technically redundant in that with some manipulation the location can be retrieved. But it causes the mapping process to be much more complex than it needs to be when manipulating the AST for source level changes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 15 09:41:21 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Nov 2015 09:41:21 -0000 Subject: [GHC] #11075: Confusing parallel spark behaviour with safe FFI calls In-Reply-To: <045.aa23e7aefeffbe70dc2426bdbd5d297f@haskell.org> References: <045.aa23e7aefeffbe70dc2426bdbd5d297f@haskell.org> Message-ID: <060.ced9fe0c551387f31b69f3bf8d0cffcf@haskell.org> #11075: Confusing parallel spark behaviour with safe FFI calls -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: patch Priority: normal | Milestone: 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 Rev(s): Phab:D1466 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D1466 Comment: Simon has put up a preliminary patch implementing a `nonblocking` FFI import variant as Phab:D1466. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 15 10:44:32 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Nov 2015 10:44:32 -0000 Subject: [GHC] #11052: Standalone derived Typeable instance for promoted lists is not found In-Reply-To: <045.1e0a781324c7d2e967c0560b8a754ab7@haskell.org> References: <045.1e0a781324c7d2e967c0560b8a754ab7@haskell.org> Message-ID: <060.83d4cc048eea14b0fa91cc0242ab62fa@haskell.org> #11052: Standalone derived Typeable instance for promoted lists is not found -------------------------------------+------------------------------------- Reporter: liamoc | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.1 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: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: It appears that the error message has been improved. With `master` as of today the test above produces the following error, {{{ $ inplace/bin/ghc-stage2 hi.hs [1 of 1] Compiling Test ( hi.hs, hi.o ) hi.hs:9:27: error: No instance for (Typeable '[]) arising from a use of ?typeRep? GHC can't yet do polykinded Typeable ('[] :: [k1]) In the first argument of ?typeRepTyCon?, namely ?(typeRep (Proxy :: Proxy '[]))? In the expression: typeRepTyCon (typeRep (Proxy :: Proxy '[])) In an equation for ?nilTyCon?: nilTyCon = typeRepTyCon (typeRep (Proxy :: Proxy '[])) hi.hs:10:27: error: No instance for (Typeable (':)) arising from a use of ?typeRep? GHC can't yet do polykinded Typeable ((':) :: k0 -> [k0] -> [k0]) In the first argument of ?typeRepTyCon?, namely ?(typeRep (Proxy :: Proxy (:)))? In the expression: typeRepTyCon (typeRep (Proxy :: Proxy (:))) In an equation for ?consTyCon?: consTyCon = typeRepTyCon (typeRep (Proxy :: Proxy (:))) }}} Given that representation of polykinded types is an open research question it seems that the bug covered by this issue (the error message) has been resolved. Closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 15 11:01:05 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Nov 2015 11:01:05 -0000 Subject: [GHC] #9555: internal error: ARR_WORDS object entered! In-Reply-To: <044.8225d0d1b99d0213ffab974e3a0c55d9@haskell.org> References: <044.8225d0d1b99d0213ffab974e3a0c55d9@haskell.org> Message-ID: <059.11e8473dac3c6b86a4cafbebc9becdbe@haskell.org> #9555: internal error: ARR_WORDS object entered! -------------------------------------+------------------------------------- Reporter: walck | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Old description: > In ghci, > > :m Data.Complex.Cyclotomic > goldenRatio > > produces the error. > > : internal error: ARR_WORDS object entered! > (GHC version 7.8.3 for x86_64_unknown_linux) > Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug > Aborted (core dumped) New description: In ghci, {{{ :m Data.Complex.Cyclotomic goldenRatio }}} produces the error. {{{ : internal error: ARR_WORDS object entered! (GHC version 7.8.3 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) }}} -- Comment: I am unable to reproduce this with 7.10.2. Closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 15 11:02:15 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Nov 2015 11:02:15 -0000 Subject: [GHC] #9414: GHC 7.8.3 compilation fails on Raspberry PI In-Reply-To: <047.40b5d8ee9b85e5848646d14a99373ff4@haskell.org> References: <047.40b5d8ee9b85e5848646d14a99373ff4@haskell.org> Message-ID: <062.330ca1783b2d8a1a957417b5d4ce660d@haskell.org> #9414: GHC 7.8.3 compilation fails on Raspberry PI ---------------------------------+---------------------------------- Reporter: ipuustin | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------- Changes (by bgamari): * status: new => infoneeded Comment: Marking as needinfo. Will close in a few weeks if there has been no response. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 15 11:18:54 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Nov 2015 11:18:54 -0000 Subject: [GHC] #11093: T9579 fails on OS X Message-ID: <046.f2b64e0980cbc13cb12e4a1a3513a03a@haskell.org> #11093: T9579 fails on OS X -------------------------------------+------------------------------------- Reporter: bgamari | 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 Rev(s): | Wiki Page: -------------------------------------+------------------------------------- As pointed out in ticket:9579#comment:19 the testcase T9579 fails on OS X, {{{ Actual stdout output differs from expected: --- ./T9579_outofheap_rtsall.stdout.normalised 2015-06-16 14:06:15.000000000 -0400 +++ ./T9579_outofheap_rtsall.run.stdout.normalised 2015-06-16 14:06:15.000000000 -0400 @@ -1,4 +1,4 @@ T9579_outofheap_rtsall: Heap exhausted; -T9579_outofheap_rtsall: Current maximum heap size is NUM bytes (1 MB). +T9579_outofheap_rtsall: Current maximum heap size is 1048576 bytes (1 MB). T9579_outofheap_rtsall: Use `+RTS -M' to increase it. 251 \ No newline at end of file *** unexpected failure for T9579_outofheap_rtsall(normal) }}} The issue appears to be a difference in `sed`'s behavior on OS X. The number in the error message is supposed to be replaced by `NUM` with `sed -e 's/[0-9]* bytes/NUM bytes/g'`. Perhaps someone with access to an OS X box could shed some light on this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 15 11:19:12 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Nov 2015 11:19:12 -0000 Subject: [GHC] #9579: Runtime suggests using +RTS when that's not possible In-Reply-To: <045.b27628d41e7cac02ba3f0a6438a4f9eb@haskell.org> References: <045.b27628d41e7cac02ba3f0a6438a4f9eb@haskell.org> Message-ID: <060.5c5d2deb93b583d48749d297f932cc18@haskell.org> #9579: Runtime suggests using +RTS when that's not possible -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: closed Priority: low | Milestone: 8.0.1 Component: Runtime System | Version: 7.9 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D767 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: goldfire, the issue that you are observing actually appears to be a difference in `sed`'s behavior on OS X. The number in the error message is supposed to be replaced by `NUM` with `sed -e 's/[0-9]* bytes/NUM bytes/g'`. Perhaps someone with access to an OS X box could shed some light on this. I'm going close this in favor of #11093. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 15 11:23:01 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Nov 2015 11:23:01 -0000 Subject: [GHC] #8746: Crosscompiling In-Reply-To: <049.1228fc07cede4b1619c6ff70ac264add@haskell.org> References: <049.1228fc07cede4b1619c6ff70ac264add@haskell.org> Message-ID: <064.f796e0c738dddd9f5e56d6645a6d9bf3@haskell.org> #8746: Crosscompiling -------------------------------------+------------------------------------- Reporter: Visionstar | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 7.8.1-rc1 Resolution: invalid | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => invalid Comment: I'm afraid that cross-compiling isn't very well supported at the moment. I'm going to close this ticket as it has been inactive for some time. Visionstar, feel free to come speak to us in `#ghc` if you want further assistance. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 15 12:59:24 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Nov 2015 12:59:24 -0000 Subject: [GHC] #11094: Cost-center heap profiler should be able to emit samples to eventlog Message-ID: <046.5020b7d3a1ba23f2949a42c6789e9133@haskell.org> #11094: Cost-center heap profiler should be able to emit samples to eventlog -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Often when looking at heap profiles I find myself wishing that I had better tools for aligning the heap behavior to various events in the lifetime of my program. The eventlog provides a nice facility for marking these events, why not record heap profile samples in the eventlog as well? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 15 13:35:06 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Nov 2015 13:35:06 -0000 Subject: [GHC] #11095: -O0 -g slows GHC down on list literals (compared to -O0 without -g) Message-ID: <045.f2278fefc782dbe6a8ba94b4e136cda3@haskell.org> #11095: -O0 -g slows GHC down on list literals (compared to -O0 without -g) -------------------------------------+------------------------------------- Reporter: slyfox | 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 Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Tried to buld syb-0.6 testsuite with '-O0 -g' flags today and noticed compiler hung for a couple of hours. Distilled example from syb-0.6 testsuite (exact example attached): {{{#!hs {-# LANGUAGE NoImplicitPrelude #-} {-# OPTIONS_GHC -O0 #-} module Bug (bug) where {-# NOINLINE f #-} f :: a -> a f v = v bug :: [()] bug = f v v :: [()] v = [(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),() ,(),(),(),(),() ... --- a lot of these ] }}} {{{ $ time ghc -c -fforce-recomp -O0 Bug.hs real 0m0.333s user 0m0.288s sys 0m0.042s $ time ghc -c -fforce-recomp -O0 -g Bug.hs real 0m40.241s user 0m40.021s sys 0m0.070s }}} For some reason '''-g''' manages slow things down at a large factor. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 15 13:35:39 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Nov 2015 13:35:39 -0000 Subject: [GHC] #11095: -O0 -g slows GHC down on list literals (compared to -O0 without -g) In-Reply-To: <045.f2278fefc782dbe6a8ba94b4e136cda3@haskell.org> References: <045.f2278fefc782dbe6a8ba94b4e136cda3@haskell.org> Message-ID: <060.3e5abd5b9a51a6a0781d1b4f28b322ed@haskell.org> #11095: -O0 -g slows GHC down on list literals (compared to -O0 without -g) -------------------------------------+------------------------------------- Reporter: slyfox | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by slyfox): * Attachment "Bug.hs" added. Actual file, -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 15 15:13:30 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Nov 2015 15:13:30 -0000 Subject: [GHC] #11096: Builtin encoder/decoder should be used for Latin-1 Message-ID: <046.190f1bb041a581e8ef2d2a11405c3f20@haskell.org> #11096: Builtin encoder/decoder should be used for Latin-1 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: hvr 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): | Wiki Page: -------------------------------------+------------------------------------- Filed on behalf of hvr. Currently `mkTextEncoding'` delegates decoding/encoding from/to latin-1 to `iconv`. This shouldn't be necessary as we have latin-1 an encoder in `base`. Let's use it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 15 15:14:29 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Nov 2015 15:14:29 -0000 Subject: [GHC] #11096: Builtin encoder/decoder should be used for Latin-1 In-Reply-To: <046.190f1bb041a581e8ef2d2a11405c3f20@haskell.org> References: <046.190f1bb041a581e8ef2d2a11405c3f20@haskell.org> Message-ID: <061.3545bfb623bdc6e05a71606b002fbf7b@haskell.org> #11096: Builtin encoder/decoder should be used for Latin-1 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: hvr 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): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > Filed on behalf of hvr. > > Currently `mkTextEncoding'` delegates decoding/encoding from/to latin-1 > to `iconv`. This shouldn't be necessary as we have latin-1 an encoder in > `base`. Let's use it. New description: Filed on behalf of hvr. Currently `mkTextEncoding'` delegates decoding/encoding from/to latin-1 to `iconv`. This shouldn't be necessary as we have latin-1 an encoder in `base`. Let's use it like we do the built-in ASCII codec. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 15 16:39:41 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Nov 2015 16:39:41 -0000 Subject: [GHC] #11095: -O0 -g slows GHC down on list literals (compared to -O0 without -g) In-Reply-To: <045.f2278fefc782dbe6a8ba94b4e136cda3@haskell.org> References: <045.f2278fefc782dbe6a8ba94b4e136cda3@haskell.org> Message-ID: <060.874700e32269882697070749042bac24@haskell.org> #11095: -O0 -g slows GHC down on list literals (compared to -O0 without -g) -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by slyfox): * failure: None/Unknown => Compile-time performance bug Comment: Result on "prof" flavour of ghc-HEAD build with '''-auto-all''' enabled: {{{ Sun Nov 15 16:31 2015 Time and Allocation Profiling Report (Final) ghc-stage2 +RTS -p -RTS -B/home/slyfox/dev/git/ghc- prof/inplace/lib -hide-all-packages -c -g Bug.hs total time = 304.82 secs (304823 ticks @ 1000 us, 1 processor) total alloc = 286,040,926,256 bytes (excludes profiling overheads) COST CENTRE MODULE %time %alloc containsSpan SrcLoc 32.1 55.2 bindIO.\ GHC.Base 10.6 0.0 == FastString 7.7 13.8 tickishContains CoreSyn 6.5 0.0 mkTick.mkTick' CoreUtils 6.4 6.9 eqString GHC.Base 5.9 0.0 <= GHC.Classes 4.4 0.0 srcSpanStartLine SrcLoc 4.4 9.2 uniq FastString 3.8 9.2 compareInt GHC.Classes 3.6 0.0 srcSpanFile SrcLoc 3.0 0.0 srcSpanEndLine SrcLoc 2.3 4.6 >= GHC.Classes 1.5 0.0 && GHC.Classes 1.4 0.0 == GHC.Classes 1.2 0.0 /= CoreSyn 1.1 0.0 ... mapOL OrdList 154083 917328 0.0 0.0 88.9 99.6 wrapTicks.wrap CorePrep 154085 915975 0.0 0.0 88.9 99.6 wrapTicks.wrapBind CorePrep 154086 915975 0.0 0.1 88.9 99.6 mkTick CoreUtils 154087 915975 1.0 0.0 88.8 99.5 mkTick.canSplit CoreUtils 154113 915975 0.0 0.0 0.0 0.0 && GHC.Classes 154115 915975 0.0 0.0 0.0 0.0 tickishCanSplit CoreSyn 154114 915975 0.0 0.0 0.0 0.0 mkTick.mkTick' CoreUtils 154088 411894225 6.4 6.9 87.8 99.5 tickishContains CoreSyn 154120 821043225 6.5 0.0 78.6 92.5 containsSpan SrcLoc 154125 821037825 32.0 55.1 64.3 92.5 ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 15 19:02:04 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Nov 2015 19:02:04 -0000 Subject: [GHC] #11083: Documentation clarification for Data.List.isSubsequenceOf In-Reply-To: <043.e69eb5fdb16ef2a225fec4c141703786@haskell.org> References: <043.e69eb5fdb16ef2a225fec4c141703786@haskell.org> Message-ID: <058.cd9f7838df5e91a975ea262c757bfb03@haskell.org> #11083: Documentation clarification for Data.List.isSubsequenceOf -------------------------------------+------------------------------------- Reporter: jura | Owner: jura Type: bug | Status: new Priority: lowest | Milestone: Component: Documentation | Version: 7.10.2 Resolution: | Keywords: Data.List, | isSubsequenceOf Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jura): * owner: => jura -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 15 19:15:40 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Nov 2015 19:15:40 -0000 Subject: [GHC] #11083: Documentation clarification for Data.List.isSubsequenceOf In-Reply-To: <043.e69eb5fdb16ef2a225fec4c141703786@haskell.org> References: <043.e69eb5fdb16ef2a225fec4c141703786@haskell.org> Message-ID: <058.279bee14132cf32109f952b59201cf55@haskell.org> #11083: Documentation clarification for Data.List.isSubsequenceOf -------------------------------------+------------------------------------- Reporter: jura | Owner: jura Type: bug | Status: new Priority: lowest | Milestone: Component: Documentation | Version: 7.10.2 Resolution: | Keywords: Data.List, | isSubsequenceOf Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1477 Wiki Page: | -------------------------------------+------------------------------------- Changes (by jura): * differential: => Phab:D1477 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 15 20:26:26 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Nov 2015 20:26:26 -0000 Subject: [GHC] #11071: "Not in scope" errors should be more informative for qualified names. In-Reply-To: <047.e970b72d66ebf0753d36739a65af99a0@haskell.org> References: <047.e970b72d66ebf0753d36739a65af99a0@haskell.org> Message-ID: <062.a0aa4618694ee78cb00a2646f84b0ea0@haskell.org> #11071: "Not in scope" errors should be more informative for qualified names. -------------------------------------+------------------------------------- Reporter: mojojojo | Owner: nomeata Type: feature request | 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 Rev(s): Phab:D1462 Wiki Page: | Phab:D1478 -------------------------------------+------------------------------------- Changes (by nomeata): * differential: Phab:D1462 => Phab:D1462 Phab:D1478 Comment: Thomie, how do you like Phab:D1478? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 15 21:12:25 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Nov 2015 21:12:25 -0000 Subject: [GHC] #11096: Builtin encoder/decoder should be used for Latin-1 In-Reply-To: <046.190f1bb041a581e8ef2d2a11405c3f20@haskell.org> References: <046.190f1bb041a581e8ef2d2a11405c3f20@haskell.org> Message-ID: <061.a164b9748a23383a8ecee302dbafc90b@haskell.org> #11096: Builtin encoder/decoder should be used for Latin-1 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: hvr 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): Here's a strawman-patch I'm using locally for the AIX port I'm working on: {{{#!diff --- a/libraries/base/GHC/IO/Encoding.hs +++ b/libraries/base/GHC/IO/Encoding.hs @@ -237,6 +237,8 @@ mkTextEncoding e = case mb_coding_failure_mode of mkTextEncoding' :: CodingFailureMode -> String -> IO TextEncoding mkTextEncoding' cfm enc = case [toUpper c | c <- enc, c /= '-'] of + -- ISO8859-1 we can handle ourself + "ISO88591" -> return $ Latin1.mkLatin1 cfm -- UTF-8 and friends we can handle ourselves "UTF8" -> return $ UTF8.mkUTF8 cfm "UTF16" -> return $ UTF16.mkUTF16 cfm }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 15 22:05:31 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Nov 2015 22:05:31 -0000 Subject: [GHC] #11095: -O0 -g slows GHC down on list literals (compared to -O0 without -g) In-Reply-To: <045.f2278fefc782dbe6a8ba94b4e136cda3@haskell.org> References: <045.f2278fefc782dbe6a8ba94b4e136cda3@haskell.org> Message-ID: <060.5d7ae80ffe28a69ca4693e3d16fcdd57@haskell.org> #11095: -O0 -g slows GHC down on list literals (compared to -O0 without -g) -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): What c compiler is being invoked. There's known issues with using clang and profiling build way when there's large numbers of literals in a source file. What does gcc --version and ghc --info tell you? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 15 22:21:51 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Nov 2015 22:21:51 -0000 Subject: [GHC] #11078: Access to module renaming with reifyModule, in TemplateHaskell In-Reply-To: <049.31454990f3b91e72bda5a21e4cbbf2c4@haskell.org> References: <049.31454990f3b91e72bda5a21e4cbbf2c4@haskell.org> Message-ID: <064.12b13117b70dc19ac3f760076672dfa6@haskell.org> #11078: Access to module renaming with reifyModule, in TemplateHaskell -------------------------------------+------------------------------------- Reporter: cipher1024 | Owner: Type: feature request | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I'm afraid I don't have any ideas until my "type=kind" branch is merged, which is of highest priority. What's the specific piece of info that's missing? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 16 08:02:31 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Nov 2015 08:02:31 -0000 Subject: [GHC] #11058: selected processor does not support ARM mode In-Reply-To: <046.179fa65419f6552c89ce7f996b230033@haskell.org> References: <046.179fa65419f6552c89ce7f996b230033@haskell.org> Message-ID: <061.1540f71dbae7f8ba2c2229828cfacfb1@haskell.org> #11058: selected processor does not support ARM mode ----------------------------------------+------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------ Comment (by nomeata): > Going to try build the debian ghc-7.10.2 package just to make sure I know what I'm doing. Did that reveal anything interesting? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 16 08:59:34 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Nov 2015 08:59:34 -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.e466588c4f92d1cc1918ac04aa5dcd65@haskell.org> #10726: Upgrade MingW-w64 distributions for windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.3 Component: Build System | Version: 7.11 Resolution: | 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 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by lukexi): * status: closed => new * cc: bgamari, thomie (added) * resolution: fixed => Comment: I seem to be hitting a regression with 7.10.3 RC1: I get this when trying to link my bindings to Bullet Physics https://github.com/lukexi/bullet-mini {{{ Preprocessing test suite 'cubes' for bullet-mini-0.1.0.0... [2 of 3] Compiling Types ( test\shared\Types.hs, .stack- work\dist\d96ab9d9\build\cubes\cubes-tmp\Types.o ) ghc.exe: unable to load package `bullet-mini-0.1.0.0' ghc.exe: C:\msys64\home\lukex_000\Projects\bullet-mini\.stack- work\dist\d96ab9d9\build\HSbullet-mini-0.1.0.0-2FOziegOC2l7eL6oW7Ffnm.o: unknown symbol `__mingw_vsscanf' }}} The Types module is the first one that uses Template Haskell. I'd previously triumphantly gotten this package building with a modified version of 7.10.2 with the following patches applied: https://github.com/lukexi/ghc/commits/ghc-7.10.2-release-plus-rework- windows-pe-linker So something broke between here and there. So far I've tried updating my entire pacman database but that didn't seem to help. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 16 09:26:46 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Nov 2015 09:26:46 -0000 Subject: [GHC] #11078: Access to module renaming with reifyModule, in TemplateHaskell In-Reply-To: <049.31454990f3b91e72bda5a21e4cbbf2c4@haskell.org> References: <049.31454990f3b91e72bda5a21e4cbbf2c4@haskell.org> Message-ID: <064.bfc34308cfd3077916a96c54fea0b21d@haskell.org> #11078: Access to module renaming with reifyModule, in TemplateHaskell -------------------------------------+------------------------------------- Reporter: cipher1024 | Owner: Type: feature request | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jstolarek): ?mer, do you have your work somewhere on a brach? Perhaps I can allocate some cycles to this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 16 09:31:10 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Nov 2015 09:31:10 -0000 Subject: [GHC] #10276: ApiAnnotations : ITopenExpQuote needs SourceText In-Reply-To: <044.2a289d9c9e324d361db842bc55632f22@haskell.org> References: <044.2a289d9c9e324d361db842bc55632f22@haskell.org> Message-ID: <059.37162adfe155441787a6b95d7b8cc2c8@haskell.org> #10276: ApiAnnotations : ITopenExpQuote needs SourceText -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 (Parser) | 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:D1479 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * differential: => Phab:D1479 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 16 09:35:05 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Nov 2015 09:35:05 -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.f14f6bf763e9b013dd133a06a58d99f5@haskell.org> #10726: Upgrade MingW-w64 distributions for windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.3 Component: Build System | Version: 7.11 Resolution: | 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 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by lukexi): I've pushed a commit to https://github.com/lukexi/bullet-mini that should make this easy to repro: {{{stack test :linking --stack-yaml stack-minimal.yaml}}} or {{{cabal test linking}}} should do the trick. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 16 09:45:48 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Nov 2015 09:45:48 -0000 Subject: [GHC] #11095: -O0 -g slows GHC down on list literals (compared to -O0 without -g) In-Reply-To: <045.f2278fefc782dbe6a8ba94b4e136cda3@haskell.org> References: <045.f2278fefc782dbe6a8ba94b4e136cda3@haskell.org> Message-ID: <060.7c58b87a472b7441af419bd4b80837c3@haskell.org> #11095: -O0 -g slows GHC down on list literals (compared to -O0 without -g) -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by slyfox): Replying to [comment:2 carter]: > What c compiler is being invoked. There's known issues with using clang and profiling build way when there's large numbers of literals in a source file. What does gcc --version and ghc --info tell you? The build of a Bug.hs is not a -prof build. GHC was built as a "prof" flavour to pinpoint what it does. All GHC's I tried are affected: - ghc-HEAD (7.11.20151115, 7.11.20151114) - ghc-7.10.2 (7.10.2.20151030) ghc -v shows the slowdown is not in a C part, but in CorePrep: {{{ $ ghc -v -O0 -g Bug.hs ... [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) *** Parser: *** Renamer/typechecker: *** Desugar: Result size of Desugar (after optimization) = {terms: 2,707, types: 1,360, coercions: 0} *** Simplifier: Result size of Simplifier = {terms: 2,707, types: 1,360, coercions: 0} *** Tidy Core: Result size of Tidy Core = {terms: 2,707, types: 1,360, coercions: 0} writeBinIface: 1 Names writeBinIface: 3 dict entries *** CorePrep: Result size of CorePrep ... }}} {{{ $ LANG=C gcc --version gcc (Gentoo 5.2.0 p1.0, pie-0.6.3) 5.2.0 Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 16 10:35:24 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Nov 2015 10:35:24 -0000 Subject: [GHC] #10276: ApiAnnotations : ITopenExpQuote needs SourceText In-Reply-To: <044.2a289d9c9e324d361db842bc55632f22@haskell.org> References: <044.2a289d9c9e324d361db842bc55632f22@haskell.org> Message-ID: <059.8fbfc35859d9707e14df6a7902fe97f2@haskell.org> #10276: ApiAnnotations : ITopenExpQuote needs SourceText -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 (Parser) | 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:D1479 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 16 12:13:05 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Nov 2015 12:13:05 -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.92d725974ad357a25c0f891d49bbcbb1@haskell.org> #10726: Upgrade MingW-w64 distributions for windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.3 Component: Build System | Version: 7.11 Resolution: | 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 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by awson): `__mingw_vsscanf` resides in `libmingwex.a` which is never mentioned in project's cabal file. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 16 12:18:07 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Nov 2015 12:18:07 -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.201a657c3f65088b6715b5d9462d6ecc@haskell.org> #10726: Upgrade MingW-w64 distributions for windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.3 Component: Build System | Version: 7.11 Resolution: | 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 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by lukexi): Thanks awson ??I noticed that too and tried to add libmingwex but ran into https://ghc.haskell.org/trac/ghc/ticket/3242 (odd that it worked fine in 7.10.2 + patches, though...) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 16 12:28:23 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Nov 2015 12:28:23 -0000 Subject: [GHC] #3242: GHCi linker does not correctly locate static libraries under Windows In-Reply-To: <045.426dc6319f98492c5b511466045bc0b5@haskell.org> References: <045.426dc6319f98492c5b511466045bc0b5@haskell.org> Message-ID: <060.6076267e2d85a18e5d0e17ac659661ba@haskell.org> #3242: GHCi linker does not correctly locate static libraries under Windows ---------------------------------+---------------------------------------- Reporter: jeffz1 | Owner: Phyx- Type: bug | Status: patch Priority: high | Milestone: 7.10.3 Component: GHCi | Version: 7.4.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: T3242 Blocked By: 3658 | Blocking: Related Tickets: #7097 | Differential Rev(s): Phab:D1455 Wiki Page: | ---------------------------------+---------------------------------------- Changes (by lukexi): * milestone: 8.0.1 => 7.10.3 Comment: We should get this into 7.10.3 if possible, as it's another showstopper for linking certain C/C++ libraries on Windows in the presence of Template Haskell (see #10726). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 16 12:54:43 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Nov 2015 12:54:43 -0000 Subject: [GHC] #11072: Runtime linker doesn't search for DLLs referenced in import libraries on Windows In-Reply-To: <050.675e99e0c3128be1426b83f1c6310ea3@haskell.org> References: <050.675e99e0c3128be1426b83f1c6310ea3@haskell.org> Message-ID: <065.5b27bee29239d1ce3350088fd30b9126@haskell.org> #11072: Runtime linker doesn't search for DLLs referenced in import libraries on Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2-rc2 (Linking) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Matt): @Phyx- I have never before submitted a patch for GHC so i have no idea if i would be able to take over this ticket and what would be proper procedure for going with it. However i have been working on this for few days here is what i got so far. After examining many import libraries i found out that in all import libraries i got my hands on, DLL name was always stored in first object file in import library archive in raw data associated with {{{idata$7}}} section. Based on that i think this is reliable way to implement this. I put together small patch for GHC, however its for GHC-7.10.2 as i have some trouble building and running GHC-head on my PC. In spite of that it should be trivial to port this to head as it changes only few lines of existing code. I would love to hear some input on this and whether this seems viable. In the meantime if I manage to build and test this with GHC-head I will post more update. At the moment with this patch when you invoke GHCi, for example as {{{ghci -lfoo}}}, it will look for {{{libfoo.dll.a}}} and {{{libfoo.a}}} before trying to load libfoo.a as static library. If either of those 2 are found it will try to extract DLL name from them in that order. If this succeds and assuming DLL name fetched was {{{libfoo-1.dll}}}, it will then try to load {{{libfoo-1.dll}}} instead trying to load {{{libfoo.a}}} as static archive. GHCi will also print some trace info when invoked with {{{-v}}} so that in case of trouble it can be traced back from where did DLL name came from. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 16 12:55:52 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Nov 2015 12:55:52 -0000 Subject: [GHC] #11072: Runtime linker doesn't search for DLLs referenced in import libraries on Windows In-Reply-To: <050.675e99e0c3128be1426b83f1c6310ea3@haskell.org> References: <050.675e99e0c3128be1426b83f1c6310ea3@haskell.org> Message-ID: <065.fa2b670f246d5329483b71eed6ec4c4e@haskell.org> #11072: Runtime linker doesn't search for DLLs referenced in import libraries on Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2-rc2 (Linking) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Matt): * Attachment "implib-ghc.7.10.2.patch" added. Proposed implementation -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 16 13:55:25 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Nov 2015 13:55:25 -0000 Subject: [GHC] #11097: `unlit` executable installed in wrong folder Message-ID: <042.e54dd93bfb8a88229d3581e0230ebbc0@haskell.org> #11097: `unlit` executable installed in wrong folder -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Build System | 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): | Wiki Page: -------------------------------------+------------------------------------- For some reason I don't know, `unlit` is installed into `$topdir` (c.f. `-B$topdir`) rather than `$exedir` (== `$topdir/bin`) IMO, it belongs into `$topdir/bin` instead, where all other internal executables are installed into -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 16 15:06:44 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Nov 2015 15:06: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.bc499a5e78216bdb88e827e2e23288b9@haskell.org> #10726: Upgrade MingW-w64 distributions for windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.3 Component: Build System | Version: 7.11 Resolution: | 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 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by awson): I think the problem is in that `libmingwex.a` is unavailable during project's prelinked object file (`HSbullet- mini-0.1.0.0-2FOziegOC2l7eL6oW7Ffnm.o` in your case) creation. Thus instead of adding `mingwex` to `extra-libraries` try to all something like `-lmingwex` to `ghc-options`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 16 15:12:01 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Nov 2015 15:12:01 -0000 Subject: [GHC] #11080: Open data kinds In-Reply-To: <047.64e06093644ddd3cb76b94e28bef420a@haskell.org> References: <047.64e06093644ddd3cb76b94e28bef420a@haskell.org> Message-ID: <062.63ece22ee147d83e7c814cc9ab4687ad@haskell.org> #11080: Open data kinds -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: Type: feature request | Status: new Priority: low | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): The next step should be making a formal proposal on the wiki and gathering comments about concrete syntax and such. No one has yet formally volunteered to implement, though I was thinking about it. Happy to cede, though. Thanks! As a response to @dmcclean: The original `data constructor` syntax works well with GADT constructors, because the full type of the constructors is included after the `::`. I still favor my original syntax, but it already looks like I'm in the minority. :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 16 17:43:23 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Nov 2015 17:43:23 -0000 Subject: [GHC] #11018: ApiAnnotations: Add SourceText for unicode tokens In-Reply-To: <044.b2f994e490e36bcbf86a1f576ead0ae0@haskell.org> References: <044.b2f994e490e36bcbf86a1f576ead0ae0@haskell.org> Message-ID: <059.910c3168638d1145d37386e9b5802599@haskell.org> #11018: ApiAnnotations: Add SourceText for unicode tokens -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1473 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Alan Zimmerman ): In [changeset:"fe95463bdf42651d53d1edc7723491664257cc5a/ghc" fe95463/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="fe95463bdf42651d53d1edc7723491664257cc5a" ApiAnnotations: Add SourceText for unicode tokens Summary: At the moment there is no way to tell if a given token used its unicode variant or its normal one, except to look at the length of the token. This fails for the unicode '*'. Expose the original source text for unicode variants so that API Annotations can capture them specifically. Test Plan: ./validate Reviewers: mpickering, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1473 GHC Trac Issues: #11018 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 16 17:53:45 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Nov 2015 17:53:45 -0000 Subject: [GHC] #9015: A documented way to differentiate between statements, declarations, imports, etc. In-Reply-To: <054.7f6a461675f798415503e3e2ad38cdb0@haskell.org> References: <054.7f6a461675f798415503e3e2ad38cdb0@haskell.org> Message-ID: <069.2301dbf972043137437ebb9d4ddec5a3@haskell.org> #9015: A documented way to differentiate between statements, declarations, imports, etc. -------------------------------------+------------------------------------- Reporter: splinterofchaos | Owner: roshats Type: feature request | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by roshats): * owner: => roshats -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 16 18:35:57 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Nov 2015 18:35:57 -0000 Subject: [GHC] #8859: import conditionalization in System.Posix.Files.Common is wrong In-Reply-To: <047.ea86c023b4962335e095d1f92b0177e9@haskell.org> References: <047.ea86c023b4962335e095d1f92b0177e9@haskell.org> Message-ID: <062.89a758d4fc4719f3057c11f2fd464bba@haskell.org> #8859: import conditionalization in System.Posix.Files.Common is wrong -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Other | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * owner: => hvr * cc: ekmett (added) * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 16 18:47:47 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Nov 2015 18:47:47 -0000 Subject: [GHC] #11078: Access to module renaming with reifyModule, in TemplateHaskell In-Reply-To: <049.31454990f3b91e72bda5a21e4cbbf2c4@haskell.org> References: <049.31454990f3b91e72bda5a21e4cbbf2c4@haskell.org> Message-ID: <064.78af66881ca01fb9a4dd7d351e41a5e4@haskell.org> #11078: Access to module renaming with reifyModule, in TemplateHaskell -------------------------------------+------------------------------------- Reporter: cipher1024 | Owner: Type: feature request | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Jan, I worked on this until I got stuck because of the missing information in `TcM`. I don't really have any code in any branch, it was only a couple of lines until I realized something's missing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 16 19:02:07 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Nov 2015 19:02:07 -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.d262a12e023b5fe0d16a5c24e3d2b937@haskell.org> #10726: Upgrade MingW-w64 distributions for windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.3 Component: Build System | Version: 7.11 Resolution: | 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 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by lukexi): Progress, sort of? {{{ $ stack test :linking bullet-mini-0.1.0.0: configure (lib + test) Configuring bullet-mini-0.1.0.0... Warning: Instead of 'ghc-options: -lmingwex' use 'extra-libraries: mingwex' Warning: Instead of 'ghc-options: -LC:\msys64\usr\local\ghc\mingw\x86_64-w64-mingw32\lib' use 'extra-lib- dirs: C:\msys64\usr\local\ghc\mingw\x86_64-w64-mingw32\lib' bullet-mini-0.1.0.0: build (lib + test) Preprocessing library bullet-mini-0.1.0.0... [1 of 1] Compiling Physics.Bullet ( src\Physics\Bullet.hs, .stack- work\dist\d96ab9d9\build\Physics\Bullet.o ) GHC runtime linker: fatal error: I found a duplicate definition for symbol coshf whilst processing object file C:\msys64\usr\local\ghc\mingw\x86_64-w64-mingw32\lib\libmingwex.a This could be caused by: * Loading two different object files which export the same symbol * Specifying the same object file twice on the GHCi command line * An incorrect `package.conf' entry, causing some object to be loaded twice. ghc.exe: panic! (the 'impossible' happened) (GHC version 7.10.2.20151030 for x86_64-unknown-mingw32): loadArchive "C:\\msys64\\usr\\local\\ghc\\mingw\\x86_64-w64-mingw32\\lib\\libmingwex.a": failed Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I used {{{ ghc-options: -LC:\msys64\usr\local\ghc\mingw\x86_64-w64-mingw32\lib -lmingwex }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 16 19:04:47 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Nov 2015 19:04:47 -0000 Subject: [GHC] #5063: unix package has untracked dependency on libbsd In-Reply-To: <045.cf55a0b13cf66f80e2fa9d353d2762fd@haskell.org> References: <045.cf55a0b13cf66f80e2fa9d353d2762fd@haskell.org> Message-ID: <060.1d107238d12638bf5ef2c94b7a1e5923@haskell.org> #5063: unix package has untracked dependency on libbsd -------------------------------------+------------------------------------- Reporter: duncan | Owner: trommler Type: bug | Status: upstream Priority: low | Milestone: 8.0.1 Component: Core Libraries | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * cc: ekmett (added) * status: new => upstream -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 16 19:10:27 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Nov 2015 19:10:27 -0000 Subject: [GHC] #10276: ApiAnnotations : ITopenExpQuote needs SourceText In-Reply-To: <044.2a289d9c9e324d361db842bc55632f22@haskell.org> References: <044.2a289d9c9e324d361db842bc55632f22@haskell.org> Message-ID: <059.fce07404a7d59f35b337014db574060b@haskell.org> #10276: ApiAnnotations : ITopenExpQuote needs SourceText -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 (Parser) | 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:D1479 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Alan Zimmerman ): In [changeset:"ee9148284dd5a66ed4970aff5218d973997cb9cf/ghc" ee91482/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ee9148284dd5a66ed4970aff5218d973997cb9cf" ApiAnnotations : ITopenExpQuote needs SourceText Summary: In the lexer, ITopenExpQuote can be recognised for '[e|' or '[|'. The token definition needs to capture the original SourceText, and pass it through to ExpBr, which also needs a SrcText field. It is easier to simply add a flag to the token identifying the variant and to generate a different AnnKeywordId based on this. Test Plan: ./validate Reviewers: mpickering, bgamari, austin Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1479 GHC Trac Issues: #10276 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 16 19:23:59 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Nov 2015 19:23:59 -0000 Subject: [GHC] #11098: TH mishandles type variables that begin with an underscore Message-ID: <047.b5765eda4c6ccd25def49af6cea2bd07@haskell.org> #11098: TH mishandles type variables that begin with an underscore -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.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 Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following GHCi exchange was reported [https://github.com/goldfirere /th-desugar/pull/36 here] (you need not follow the link to understand this ticket, though). {{{ Prelude Language.Haskell.TH> runQ [d|foo :: forall _a . _a -> _a;foo x = x|] [SigD foo_6 (ForallT [PlainTV _a_5] [] (AppT (AppT ArrowT (WildCardT (Just _a_5))) (WildCardT (Just _a_5)))),FunD foo_6 [Clause [VarP x_7] (NormalB (VarE x_7)) []]] }}} The problem is that the quoted expression uses no wildcards, yet the TH output does. That quoted expression just uses a type variable that begins with an underscore. Such an expression was allowed in Haskell long before wildcards. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 16 19:51:35 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Nov 2015 19:51:35 -0000 Subject: [GHC] #11018: ApiAnnotations: Add SourceText for unicode tokens In-Reply-To: <044.b2f994e490e36bcbf86a1f576ead0ae0@haskell.org> References: <044.b2f994e490e36bcbf86a1f576ead0ae0@haskell.org> Message-ID: <059.944e51381e90588934c1f50c451c3d3e@haskell.org> #11018: ApiAnnotations: Add SourceText for unicode tokens -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1473 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 16 19:52:18 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Nov 2015 19:52:18 -0000 Subject: [GHC] #10276: ApiAnnotations : ITopenExpQuote needs SourceText In-Reply-To: <044.2a289d9c9e324d361db842bc55632f22@haskell.org> References: <044.2a289d9c9e324d361db842bc55632f22@haskell.org> Message-ID: <059.88a17082804f4e7f19639b3bb486473c@haskell.org> #10276: ApiAnnotations : ITopenExpQuote needs SourceText -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 (Parser) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1479 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 16 21:04:04 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Nov 2015 21:04:04 -0000 Subject: [GHC] #4243: Make a proper options parser for the RTS In-Reply-To: <044.6ea5654174cc0120653bc110fe1a703c@haskell.org> References: <044.6ea5654174cc0120653bc110fe1a703c@haskell.org> Message-ID: <059.cf1f5b22ccaf279b464f5e7b49929837@haskell.org> #4243: Make a proper options parser for the RTS -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Runtime System | Version: 6.13 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 7535 Related Tickets: #9839 | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"69822f0c5b67161b4d7558081bc94f6f3a7c5dbb/ghc" 69822f0c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="69822f0c5b67161b4d7558081bc94f6f3a7c5dbb" RtsFlags: Refactor some of the deeper switches This was previously nearly impossible to read; now it's merely difficult. Ideally we would do a more thorough refactoring of the RTS command line parser (#4243) but this is more effort than I have time for at the moment. Test Plan: Try using affected RTS flags Reviewers: simonmar, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1476 GHC Trac Issues: #4243 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 16 21:04:04 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Nov 2015 21:04:04 -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.1f87620cbb741200719437ef75c0271b@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 Rev(s): Phab:D1324 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"741cf18a5e4ee5d0aa8afcab813441e7bcd4050c/ghc" 741cf18/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="741cf18a5e4ee5d0aa8afcab813441e7bcd4050c" Weaken monadic list operations to Applicative Generalize `filterM`, `mapAndUnzipM`, `zipWithM`, `zipWithM_`, `replicateM`, and `replicateM_`. Reviewers: ekmett, #core_libraries_committee, austin, hvr, bgamari Reviewed By: ekmett, #core_libraries_committee, bgamari Subscribers: ekmett, glguy, thomie Projects: #ghc Differential Revision: https://phabricator.haskell.org/D1324 GHC Trac Issues: #10168 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 16 21:04:04 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Nov 2015 21:04:04 -0000 Subject: [GHC] #11083: Documentation clarification for Data.List.isSubsequenceOf In-Reply-To: <043.e69eb5fdb16ef2a225fec4c141703786@haskell.org> References: <043.e69eb5fdb16ef2a225fec4c141703786@haskell.org> Message-ID: <058.cc1bf991c05764206c78a68f710b6eae@haskell.org> #11083: Documentation clarification for Data.List.isSubsequenceOf -------------------------------------+------------------------------------- Reporter: jura | Owner: jura Type: bug | Status: new Priority: lowest | Milestone: Component: Documentation | Version: 7.10.2 Resolution: | Keywords: Data.List, | isSubsequenceOf Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1477 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"e2d9821bf611da389df7ab8826b957d37351c29d/ghc" e2d9821b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e2d9821bf611da389df7ab8826b957d37351c29d" Data.List.isSubsequenceOf documentation clarification Fixes #11083. Reviewers: austin, hvr, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1477 GHC Trac Issues: #11083 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 16 21:04:04 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Nov 2015 21:04:04 -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.019e509d15966b36db07a9b936ad4c14@haskell.org> #9637: Type level programming needs an error function -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 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 Rev(s): Phab:D1236 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"2d1a563bf25a4e402088feb1cdcac3d7bc50c6d3/ghc" 2d1a563/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2d1a563bf25a4e402088feb1cdcac3d7bc50c6d3" Implement support for user-defined type errors. Implements Lennart's idea from the Haskell Symposium. Users may use the special type function `TypeError`, which is similar to `error` at the value level. See Trac ticket https://ghc.haskell.org/trac/ghc/ticket/9637, and wiki page https://ghc.haskell.org/trac/ghc/wiki/CustomTypeErros Test Plan: Included testcases Reviewers: simonpj, austin, hvr, goldfire, bgamari Reviewed By: goldfire, bgamari Subscribers: adamgundry, thomie Differential Revision: https://phabricator.haskell.org/D1236 GHC Trac Issues: #9637 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 16 21:28:19 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Nov 2015 21:28:19 -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.ebb5045aa86dbf2ba369415265ee2872@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 Rev(s): Phab:D1324 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): @strake888: The notion I think dfeuer was trying to get at there was that `replicateM` can do 'peasant multiplication' like `(^)` does to get away with O(log n) distinct calls to `(<*>)`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 16 21:38:40 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Nov 2015 21:38:40 -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.aade27a7f83a7685c9f2831d455b51ba@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 Rev(s): Phab:D1324 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:14 ekmett]: > @strake888: > > The notion I think dfeuer was trying to get at there was that `replicateM` can do 'peasant multiplication' like `(^)` does to get away with O(log n) distinct calls to `(<*>)`. Don't give me so much credit; I was just thinking about eliminating the need for list fusion rules to fire to prevent GHC from building an intermediate list. The peasant multiplication idea is quite an interesting one. It would sometimes be good, and I don't think it could ever be terrible, but it certainly could be ''worse'' in some cases. I'd probably prefer separate combinators for fast exponentiation of `Monoid`s and `Applicative`s. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 16 23:00:05 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Nov 2015 23:00:05 -0000 Subject: [GHC] #10444: Text.Read.Lex.lex broken In-Reply-To: <048.7d303af6bd6af366785c1d3e315fce90@haskell.org> References: <048.7d303af6bd6af366785c1d3e315fce90@haskell.org> Message-ID: <063.d159d92aa2486aede460ba3538c8f7b9@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 Rev(s): Phab:D1122, Wiki Page: | Phab:D1480. -------------------------------------+------------------------------------- Changes (by mfdyck.google): * cc: ekmett (added) * differential: Phab:D1122. => Phab:D1122, Phab:D1480. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 17 01:41:28 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Nov 2015 01:41:28 -0000 Subject: [GHC] #11099: Incorrect warning about redundant constraints Message-ID: <047.537aacca9c06ec47d57c61fce1d68f6c@haskell.org> #11099: Incorrect warning about redundant constraints -------------------------------------+------------------------------------- Reporter: diatchki | 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 Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following program results in an incorrect warning about a redundant constraint: {{{ {-# LANGUAGE TypeFamilies #-} type family SomeFun a f :: (SomeFun i ~ [a], Read a) => proxy i -> a f _ = read "HELLO" }}} This is the warning: {{{ Redundant constraint: SomeFun i ~ [a] In the type signature for: f :: (SomeFun i ~ [a], Read a) => proxy i -> a }}} I tried it on GHC version 7.11.20151029 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 17 02:01:12 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Nov 2015 02:01:12 -0000 Subject: [GHC] #11099: Incorrect warning about redundant constraints In-Reply-To: <047.537aacca9c06ec47d57c61fce1d68f6c@haskell.org> References: <047.537aacca9c06ec47d57c61fce1d68f6c@haskell.org> Message-ID: <062.cd88010825bb4f408477b1b166e31683@haskell.org> #11099: Incorrect warning about redundant constraints -------------------------------------+------------------------------------- Reporter: diatchki | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I think redundant here means basically: the definition of `f` would be accepted without the constraint. It doesn't mean that the type of `f` would be the same if you removed the constraint. The idea is to catch constraints that aren't actually used in the function, so that you could make the type of the function more general. In that case the constraint really is redundant, right? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 17 03:06:47 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Nov 2015 03:06: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.4a44a7531d94dbb6a2de54f9a8954341@haskell.org> #10726: Upgrade MingW-w64 distributions for windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.3 Component: Build System | Version: 7.11 Resolution: | 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 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): I don't really know how `stack` works, and I am sort of confused why `--interactive` is involved here. Never the less, I don't think anything broke here, interactive was just never fixed. Previously when it built `cabal run` was used as a test. This wouldn't use the runtime linker and should still be working. I think the duplicate symbols error is coming from the fact that the Rts re-exports some symbols from `mingw` but not all. it includes `SymI_HasProto(coshf)` under the comment: {{{ /* These are statically linked from the mingw libraries into the ghc executable, so we have to employ this hack. */ }}} Does `run` still produce a working binary? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 17 03:46:57 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Nov 2015 03:46:57 -0000 Subject: [GHC] #11072: Runtime linker doesn't search for DLLs referenced in import libraries on Windows In-Reply-To: <050.675e99e0c3128be1426b83f1c6310ea3@haskell.org> References: <050.675e99e0c3128be1426b83f1c6310ea3@haskell.org> Message-ID: <065.5e98bc3c7471c7dd6ef045d0c6f4e911@haskell.org> #11072: Runtime linker doesn't search for DLLs referenced in import libraries on Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2-rc2 (Linking) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Hi Matt, Thanks for the patch!, I will look at it more closely in the weekend. But a few things: 1) This does not look for `.lib` files which are just import libs as well 2) I'm a bit weary of having to look for a specific section group. In particular the `.lib` from from `icuuc.lib` does not have an `.idata$7`. {{{ Dump of file icuuc.lib File Type: LIBRARY Summary C3 .debug$S 14 .idata$2 14 .idata$3 8 .idata$4 8 .idata$5 C .idata$6 }}} I think it should just be running through the `.idata` sections to find it. 3) We already have code to read in COFF files in `Linker.c`, we probably don't want to maintain this at two points. So I would have expected most of the logic here to be done on the C side. --- I have also been wondering, these import libs also contain large symbol tables. Presumably because import libraries contain stubs for calling into the dll. GHCi supports dynamic loading of archives, would it not be possible to just simply satisfy the linker by just satisfying the symbol resolution with these stubs? Sure we have an extra layer of indirection, but it would be robust and it wouldn't really matter much for the repl. What I am asking is, have you considered just correctly locating these import libs and then not returning a `DLL` but an `Archive`? In theory this should still work, but you wouldn't have to read the COFF files. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 17 04:49:12 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Nov 2015 04:49: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.7129afd845ea41a97d45796ede5d0fff@haskell.org> #10726: Upgrade MingW-w64 distributions for windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.3 Component: Build System | Version: 7.11 Resolution: | 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 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by lukexi): It's the use of Template Haskell that's triggering the runtime linker, but perhaps I'm confused in assuming it's the same as `--interactive`? (I assume you're asking about `run` because you thought I was using `--interactive` ??the error happens during compilation so I never get a working binary) OK! I'm able to compile again if I add `SymI_HasProto(__mingw_vsscanf)` to `Linker.c` ??is that the right way to go? (The issue you fixed in #10672 happened with both `cabal` and `stack` ? since `stack` uses Cabal-as-a-library internally I'm pretty certain `cabal` will do the same thing but I can give it a try! And to restate: the `ghc-7.10.2` tag with #10672's patches applied doesn't manifest the unknown symbol issue mentioned in comment 31 ? only 7.10.3 does which is why I'm looking for what broke) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 17 05:00:32 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Nov 2015 05:00: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.caab1b70398cf3914ad6379a23dc8166@haskell.org> #10726: Upgrade MingW-w64 distributions for windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.3 Component: Build System | Version: 7.11 Resolution: | 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 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Yes, sorry, I was confused as to why the runtime linker was involved during a normal compilation. But `TH` makes sense. I guess a temporary solution to get `7.10.3` out the door is to just re- export everything from `mingwex` since you can't actually specify `-lmingwex` current. But I have wondered and still do why the RTS is re-exporting symbols like this instead of us just linking against `-lmingwex`. Do you have an idea why @awson? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 17 08:36:01 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Nov 2015 08:36:01 -0000 Subject: [GHC] #11100: Remote GHCi Message-ID: <047.346d10a0114be8596e5485c83dbed9dd@haskell.org> #11100: Remote GHCi -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: new 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 Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This task is to implement Remote GHCi, i.e. running interpreted code in a separate process. For more details see [wiki:RemoteGHCi]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 17 08:36:33 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Nov 2015 08:36:33 -0000 Subject: [GHC] #11100: Remote GHCi In-Reply-To: <047.346d10a0114be8596e5485c83dbed9dd@haskell.org> References: <047.346d10a0114be8596e5485c83dbed9dd@haskell.org> Message-ID: <062.f96a2de964a60dcf9fed6846dc7fd48e@haskell.org> #11100: Remote GHCi -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: new 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: #11047 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * related: => #11047 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 17 08:38:29 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Nov 2015 08:38:29 -0000 Subject: [GHC] #11047: Provide call stacks in GHCi In-Reply-To: <047.3eb9c7a7d6579e45d15f3dffd3ade555@haskell.org> References: <047.3eb9c7a7d6579e45d15f3dffd3ade555@haskell.org> Message-ID: <062.b93a367d610b48fa42ff31a2fb222d20@haskell.org> #11047: Provide call stacks in GHCi -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #545, #4837, | Differential Rev(s): Phab:D1407 #11100 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * related: #545, #4837 => #545, #4837, #11100 Comment: Design page for implementing GHCi in a separate process: [wiki:RemoteGHCi], ticket: #11100 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 17 08:57:00 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Nov 2015 08:57:00 -0000 Subject: [GHC] #11098: TH mishandles type variables that begin with an underscore In-Reply-To: <047.b5765eda4c6ccd25def49af6cea2bd07@haskell.org> References: <047.b5765eda4c6ccd25def49af6cea2bd07@haskell.org> Message-ID: <062.a7947d23499f1596b112d9b0c04f31e4@haskell.org> #11098: TH mishandles type variables that begin with an underscore -------------------------------------+------------------------------------- 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jstolarek): * cc: jstolarek (added) Comment: I just tried with GHC 7.8.4, 7.10.1 and today's HEAD and I can't reproduce this behaviour: {{{ [killy at GLaDOS : /dane/projekty/ghc/ghc-tests] /dane/sandboxes/ghc/7.10.1/bin/ghci GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help Prelude> :m + Language.Haskell.TH Prelude Language.Haskell.TH> :set -XTemplateHaskell Prelude Language.Haskell.TH> :set -XRankNTypes Prelude Language.Haskell.TH> runQ [d|foo :: forall _a . _a -> _a ; foo x = x|] [SigD foo_1 (ForallT [PlainTV _a_0] [] (AppT (AppT ArrowT (VarT _a_0)) (VarT _a_0))),FunD foo_1 [Clause [VarP x_2] (NormalB (VarE x_2)) []]] }}} Can you post your whole GHCi session and `~/.ghci`? Or perhaps this bug is specific to 7.10.2, but that would be surprising. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 17 09:06:11 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Nov 2015 09:06:11 -0000 Subject: [GHC] #11098: TH mishandles type variables that begin with an underscore In-Reply-To: <047.b5765eda4c6ccd25def49af6cea2bd07@haskell.org> References: <047.b5765eda4c6ccd25def49af6cea2bd07@haskell.org> Message-ID: <062.cfa94f66bef06c09d2d6a31f8bcfc16f@haskell.org> #11098: TH mishandles type variables that begin with an underscore -------------------------------------+------------------------------------- Reporter: goldfire | Owner: jstolarek 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jstolarek): * owner: => jstolarek Comment: I just looked at the original report on th-desugar issue tracker. I see the problem now. Will look into it, though I think the problem is not in the TH implementation (might be wrong though). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 17 10:16:48 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Nov 2015 10:16:48 -0000 Subject: [GHC] #11098: TH mishandles type variables that begin with an underscore In-Reply-To: <047.b5765eda4c6ccd25def49af6cea2bd07@haskell.org> References: <047.b5765eda4c6ccd25def49af6cea2bd07@haskell.org> Message-ID: <062.ca2fdf6cb5f5b14b4c58178c9e1f4ead@haskell.org> #11098: TH mishandles type variables that begin with an underscore -------------------------------------+------------------------------------- Reporter: goldfire | Owner: jstolarek 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jstolarek): The problem arises in the parser, where we assume that when named wild cards are enabled then any type variables that starts with an underscore is a wild card: {{{ | tyvar {% do { nwc <- namedWildCardsEnabled -- (See Note [Unit tuples]) ; let tv@(Unqual name) = unLoc $1 ; return $ if (startsWithUnderscore name && nwc) then (sL1 $1 (mkNamedWildCardTy tv)) else (sL1 $1 (HsTyVar tv)) } } }}} My idea for the solution is to unconditionally create an `HsTyVar` in the parser and then be smart during renaming: {{{#!hs rnHsTyKi isType doc (HsTyVar rdr_name) = do { dflags <- getDynFlags ; let is_wild_card_name = startsWithUnderscore (rdrNameOcc rdr_name) wild_cards_enabled = xopt Opt_NamedWildCards dflags ; is_in_scope <- isJust `fmap` lookupOccRn_maybe rdr_name ; if is_wild_card_name && not is_in_scope && wild_cards_enabled then rnHsTyKi isType doc (HsWildCardTy (NamedWildCard rdr_name)) else do { name <- rnTyVar isType rdr_name ; return (HsTyVar name, unitFV name) } } }}} That however does not work - the names of variables seem to be in scope even when they were not explicitly declared using a `forall`. So the question is: how do I detect if a variable was introduced using a `forall`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 17 10:31:19 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Nov 2015 10:31:19 -0000 Subject: [GHC] #11098: TH mishandles type variables that begin with an underscore In-Reply-To: <047.b5765eda4c6ccd25def49af6cea2bd07@haskell.org> References: <047.b5765eda4c6ccd25def49af6cea2bd07@haskell.org> Message-ID: <062.8c8033f723d652df4d3a81d4b17b6c94@haskell.org> #11098: TH mishandles type variables that begin with an underscore -------------------------------------+------------------------------------- Reporter: goldfire | Owner: jstolarek 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by darchon): Indeed, I was just about to comment that it is not just TH. When I compile {{{ {-# LANGUAGE PartialTypeSignatures, NamedWildCards, ExplicitForAll #-} module Bar where foo :: _a -> _a foo x = x bar :: forall _a . _a -> _a bar x = x }}} I get: {{{ $ ghc -fforce-recomp Bar.hs [1 of 1] Compiling Bar ( Bar.hs, Bar.o ) Bar.hs:4:8: warning: Found type wildcard '_a' standing for 't' Where: 't' is a rigid type variable bound by the inferred type of foo :: t -> t at Bar.hs:5:1 In the type signature for: foo :: _a -> _a Bar.hs:7:20: warning: Found type wildcard '_a' standing for 't0' Where: 't0' is an ambiguous type variable In the type signature for: bar :: forall _a. _a -> _a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 17 10:44:13 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Nov 2015 10:44:13 -0000 Subject: [GHC] #11101: Expand Template Haskell type splices before quantification Message-ID: <046.9b58a537bb82074178d7bf760f70446b@haskell.org> #11101: Expand Template Haskell type splices before quantification -------------------------------------+------------------------------------- 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 Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider {{{ f :: Int -> $(foo) f = ... }}} This is a Template Haskell type splice. What if `$(foo)` expands to `a -> a`. Then it should all behave as if you'd written {{{ f :: Int -> a -> a f = ... }}} But it doesn't, because we collect the variables over which we will implicitly quantify ''before expanding splices''. This is made yet more tricky when we add type wildcards to the mix. And really there is no good reason for this trouble. We should simply expand the splice, and ''then'' decide what to quantify over. A little bit of refactoring in `RnTypes`. This ticket is just to record that I intend to do this shortly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 17 11:04:51 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Nov 2015 11:04:51 -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.fa88921a3fe9af1d809444a8354adbd1@haskell.org> #8405: experiment with using function-sections for linking (for smaller libs and executables) -------------------------------------+------------------------------------- Reporter: carter | Owner: olsner Type: task | Status: closed Priority: normal | 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 Rev(s): Phab:D1242 Wiki Page: | -------------------------------------+------------------------------------- Comment (by olsner): Replying to [comment:19 carter]: > Would this make it practical to disable stripping on libraries and executables (so that dwarf metadata could be available by default?) I didn't know that was a problem, so if this feature fixes anything it's purely a bonus :) I suspect the debug info could get pretty large regardless of this patch, so many users might still not want it. (Though it might be improved compared to `-split-objs`?) Replying to [comment:10 refold]: > 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). Since I had my system in Windows today, I decided to test this out - but ran into some problems. First problem is that linking executables with `SplitSections=YES` gets you a "too many sections" error. But when making an executable, those sections should be getting merged into just a handful of sections... I think this is `ld`'s fault, so I submitted https://sourceware.org/bugzilla/show_bug.cgi?id=19254 for it. It also seems the `--gc-sections` patch was committed after binutils 2.25 branched off, so we need to upgrade binutils to use this. (Probably to a yet-unreleased version that also has a fix for the sections issue...) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 17 11:11:50 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Nov 2015 11:11:50 -0000 Subject: [GHC] #11101: Expand Template Haskell type splices before quantification In-Reply-To: <046.9b58a537bb82074178d7bf760f70446b@haskell.org> References: <046.9b58a537bb82074178d7bf760f70446b@haskell.org> Message-ID: <061.41d6f260cb849c43045622f289dab0b9@haskell.org> #11101: Expand Template Haskell type splices before quantification -------------------------------------+------------------------------------- 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > Consider > {{{ > f :: Int -> $(foo) > f = ... > }}} > This is a Template Haskell type splice. What if `$(foo)` expands to `a -> > a`. Then it should all behave as if you'd written > {{{ > f :: Int -> a -> a > f = ... > }}} > But it doesn't, because we collect the variables over which we will > implicitly quantify ''before expanding splices''. > > This is made yet more tricky when we add type wildcards to the mix. > > And really there is no good reason for this trouble. We should simply > expand the splice, and ''then'' decide what to quantify over. A little > bit of refactoring in `RnTypes`. > > This ticket is just to record that I intend to do this shortly. New description: Consider {{{ f :: Int -> $(foo) f = ... }}} This is a Template Haskell type splice. What if `$(foo)` expands to `a -> a`. Then it should all behave as if you'd written {{{ f :: Int -> a -> a f = ... }}} But it doesn't, because we collect the variables over which we will implicitly quantify ''before expanding splices''. This is made yet more tricky when we add type wildcards to the mix. And really there is no good reason for this trouble. We should simply expand the splice, and ''then'' decide what to quantify over. A little bit of refactoring in `RnTypes`. This ticket is just to record that I intend to do this shortly. It's possible that #11098 is related; I'm not sure. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 17 12:50:23 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Nov 2015 12:50:23 -0000 Subject: [GHC] #11078: Access to module renaming with reifyModule, in TemplateHaskell In-Reply-To: <049.31454990f3b91e72bda5a21e4cbbf2c4@haskell.org> References: <049.31454990f3b91e72bda5a21e4cbbf2c4@haskell.org> Message-ID: <064.86089e69aafb5d94301163d6937deec2@haskell.org> #11078: Access to module renaming with reifyModule, in TemplateHaskell -------------------------------------+------------------------------------- Reporter: cipher1024 | Owner: Type: feature request | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jstolarek): I just had a quick look at the code. Let's assume we are using definition proposed by Richard (slightly modified by me): {{{#!hs data ImportType = Qualified | Unqualified deriving( Show, Eq, Ord, Data, Typeable, Generic ) data ModuleImport = ModuleImport Module -- ^ Imported module ImportType -- ^ qualified? (Maybe String) -- ^ synonym [Name] -- ^ imported names deriving( Show, Eq, Ord, Data, Typeable, Generic ) }}} I understand that the place where we need to fill in these fields is `TcSplice.reifyModule`. At least that is the place where the build fails for me after I make changes to TH syntax. In `TcM` we have access to `getImports`, which gives us a list of `Module`s, each with an assigned `ImportedModsVal`: {{{#!hs type ImportedMods = ModuleEnv [ImportedModsVal] data ImportedModsVal = ImportedModsVal { imv_name :: ModuleName, -- ^ The name the module is imported with imv_span :: SrcSpan, -- ^ the source span of the whole import imv_is_safe :: IsSafeImport, -- ^ whether this is a safe import imv_is_hiding :: Bool, -- ^ whether this is an "hiding" import imv_all_exports :: GlobalRdrEnv -- ^ all the things the module could provide } }}} Now, in `reifyModule` we need the following: 1. `Module`: this is readily available and created by the existing implementation (see `TcSplice.modToTHMod`. 2. `ImportType`: I can't figure out how we could acces that one 3. `Maybe String`, aka the module synonym. I would look at `imv_name` to see what exactlt it holds. Also, I would adjust TH representation to work nicely with information stored in that field. 4. `[Name]` - it seems that this can be extracted from `imv_all_exports`. Does that allow to make progress? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 17 13:00:59 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Nov 2015 13:00:59 -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.869b41c369a02b413ff5989dbf0d8240@haskell.org> #10168: generalize filterM, mapAndUnzipM, zipWithM, zipWithM_, replicateM, replicateM_ -------------------------------------+------------------------------------- Reporter: strake888 | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.10.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1324 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 17 13:16:33 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Nov 2015 13:16:33 -0000 Subject: [GHC] #11102: `ghc --supported-extension` shall not list `TemplateHaskell` when unsupported Message-ID: <042.75105e05b4b7229d1c36f2c44b9a694f@haskell.org> #11102: `ghc --supported-extension` shall not list `TemplateHaskell` when unsupported -------------------------------------+------------------------------------- Reporter: hvr | Owner: bgamari 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 Rev(s): phab:D1484 | Wiki Page: -------------------------------------+------------------------------------- Currently GHC advertises `TemplateHaskell` even though it's statically known to fail: {{{ $ ghc --supported-extensions | grep Template TemplateHaskell NoTemplateHaskell # `NoTemplateHaskell` works: $ ghc -XNoTemplateHaskell -c hello.hs # `TemplateHaskell` however fails even though advertised: $ ghc -XTemplateHaskell -c hello.hs ghc: on the commandline: Template Haskell requires GHC with interpreter support Perhaps you are using a stage-1 compiler? Usage: For basic information, try the `--help' option. }}} Having properly advertised extensions is particularly useful in combination with [[https://github.com/haskell/cabal/issues/2644|Cabal#2644]] allowing the solver to toggle flags depending on the availability of `-XTemplateHaskell`. For instance, cross-compilers and/or unregisterised GHC builds often don't have TemplateHaskell support. Having support for toggling flags based on availability of `-XTemplateHaskell` allows `cabal` to support such environments with less manual intervention. (See also https://github.com/haskell/cabal/pull/2930 for pre-GHC8 emulation of this feature) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 17 14:14:57 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Nov 2015 14:14:57 -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.9e66b54a2d57801ecb1a2a1a2a219241@haskell.org> #9637: Type level programming needs an error function -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | 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: #9180, #9636 | Differential Rev(s): Phab:D1236 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 17 14:19:34 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Nov 2015 14:19:34 -0000 Subject: [GHC] #11098: PartialTypeSignatures mishandles type variables that begin with an underscore (was: TH mishandles type variables that begin with an underscore) In-Reply-To: <047.b5765eda4c6ccd25def49af6cea2bd07@haskell.org> References: <047.b5765eda4c6ccd25def49af6cea2bd07@haskell.org> Message-ID: <062.1de4c48965deaca54b1fcc74d46aab5b@haskell.org> #11098: PartialTypeSignatures mishandles type variables that begin with an underscore -------------------------------------+------------------------------------- Reporter: goldfire | Owner: jstolarek 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * cc: thomasw (added) Comment: Good observations. Perhaps we should ask the partial type signatures folks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 17 14:25:31 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Nov 2015 14:25:31 -0000 Subject: [GHC] #11078: Access to module renaming with reifyModule, in TemplateHaskell In-Reply-To: <049.31454990f3b91e72bda5a21e4cbbf2c4@haskell.org> References: <049.31454990f3b91e72bda5a21e4cbbf2c4@haskell.org> Message-ID: <064.a82b10828da8b8e1f711294e3f73d557@haskell.org> #11078: Access to module renaming with reifyModule, in TemplateHaskell -------------------------------------+------------------------------------- Reporter: cipher1024 | Owner: Type: feature request | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I'm concerned about `all the things the module could provide`. That sounds like it contains all the exports of the module in question, which is larger than the list of all definitions that are imported here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 17 14:57:04 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Nov 2015 14:57:04 -0000 Subject: [GHC] #11078: Access to module renaming with reifyModule, in TemplateHaskell In-Reply-To: <049.31454990f3b91e72bda5a21e4cbbf2c4@haskell.org> References: <049.31454990f3b91e72bda5a21e4cbbf2c4@haskell.org> Message-ID: <064.85ba980a779efa3675661a4c676b3adc@haskell.org> #11078: Access to module renaming with reifyModule, in TemplateHaskell -------------------------------------+------------------------------------- Reporter: cipher1024 | Owner: Type: feature request | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I believe that would allow to make progress. You may want to have a look at `HsModule` and `HsParsedModule` types. We can easily pass them(or some information taken from them) to the type checker and they have everything we need. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 17 14:57:36 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Nov 2015 14:57:36 -0000 Subject: [GHC] #11102: `ghc --supported-extension` shall not list `TemplateHaskell` when unsupported In-Reply-To: <042.75105e05b4b7229d1c36f2c44b9a694f@haskell.org> References: <042.75105e05b4b7229d1c36f2c44b9a694f@haskell.org> Message-ID: <057.c69e6be8a7dd24b94652d1ca3463cd43@haskell.org> #11102: `ghc --supported-extension` shall not list `TemplateHaskell` when unsupported -------------------------------------+------------------------------------- Reporter: hvr | Owner: bgamari 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 Rev(s): phab:D1484 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"7c9cbfd9074055d6db93d4b44c8aea8d32402aa6/ghc" 7c9cbfd/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7c9cbfd9074055d6db93d4b44c8aea8d32402aa6" template-haskell: drop `TemplateHaskell` requirement `other-extensions: TemplateHaskell` is inaccurate: It's not required to compile `template-haskell` (otherwise we wouldn't be able to build that package via `ghc-stage1`...) This has been discovered while working on #11102 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 17 15:20:00 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Nov 2015 15:20:00 -0000 Subject: [GHC] #3242: GHCi linker does not correctly locate static libraries under Windows In-Reply-To: <045.426dc6319f98492c5b511466045bc0b5@haskell.org> References: <045.426dc6319f98492c5b511466045bc0b5@haskell.org> Message-ID: <060.885b4ab13898154ca7d89ee4b2e9157b@haskell.org> #3242: GHCi linker does not correctly locate static libraries under Windows ---------------------------------+---------------------------------------- Reporter: jeffz1 | Owner: Phyx- Type: bug | Status: patch Priority: high | Milestone: 7.10.3 Component: GHCi | Version: 7.4.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: T3242 Blocked By: 3658 | Blocking: Related Tickets: #7097 | Differential Rev(s): Phab:D1455 Wiki Page: | ---------------------------------+---------------------------------------- Comment (by Ben Gamari ): In [changeset:"acce37f38bc3867f86cf717694915746bb2f278e/ghc" acce37f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="acce37f38bc3867f86cf717694915746bb2f278e" Fix archive loading on Windows by the runtime loader The runtime loader is unable to find archive files `.a` shipping with the inplace `GCC`. It seems the issue is caused by `findArchive` being unable to find any archives that are shipped using the in-place `GCC`. - It works on Linux because `findArchive` would search the standard Linux include path. - It works during compilation because `GCC` can find it's own libraries (we explicitly tell it where to look for libraries using the `gcc` wrapper around `realgcc`) So fixing the issue means using `searchForLibUsingGcc` in `findArchive` as well, which will then find the correct file. The reason for the error as it is, is because if we can't locate the library using any of the methods we have, we assume it is a system dll, or something on the system search path. e.g. if trying to load `kernel32.dll`. There is a slight issue in that the `GHCi` code (incorrectly) favors `static archives` over `dynamic` ones ``` findDll `orElse` findArchive `orElse` tryGcc `orElse` tryGccPrefixed `orElse` assumeDll ``` This has the unwanted effect of when `kernel32` is specified as a lib, it will try to load `kernel32.a` instead of `kernel32.dll`. To solve this I have added another search function that is able to search the Windows search paths using `SearchPath` in order to find if it is a dll on the system search path. The new search order is: ``` findDll `orElse` findSysDll `orElse` tryGcc `orElse` findArchive `orElse` assumeDll ``` (`tryGccPrefixed` was rolled into `tryGcc` so it is no longer needed at top level) Test Plan: ./validate added new windows tests T3242 Reviewers: thomie, erikd, hvr, austin, bgamari Reviewed By: thomie, erikd, bgamari Differential Revision: https://phabricator.haskell.org/D1455 GHC Trac Issues: #3242 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 17 15:25:31 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Nov 2015 15:25:31 -0000 Subject: [GHC] #3242: GHCi linker does not correctly locate static libraries under Windows In-Reply-To: <045.426dc6319f98492c5b511466045bc0b5@haskell.org> References: <045.426dc6319f98492c5b511466045bc0b5@haskell.org> Message-ID: <060.c251a7c7038de7ed9d33e3638222c8c3@haskell.org> #3242: GHCi linker does not correctly locate static libraries under Windows ---------------------------------+---------------------------------------- Reporter: jeffz1 | Owner: Phyx- Type: bug | Status: closed Priority: high | Milestone: 7.10.3 Component: GHCi | Version: 7.4.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: T3242 Blocked By: 3658 | Blocking: Related Tickets: #7097 | Differential Rev(s): Phab:D1455 Wiki Page: | ---------------------------------+---------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 17 16:34:23 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Nov 2015 16:34:23 -0000 Subject: [GHC] #11051: GHCi with +t option set shows type representations In-Reply-To: <046.80bf6e2eddeb6b8db1c64cf901c24623@haskell.org> References: <046.80bf6e2eddeb6b8db1c64cf901c24623@haskell.org> Message-ID: <061.618222eafffcc734ddf4c1a3cb31052f@haskell.org> #11051: GHCi with +t option set shows type representations -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 17 16:45:33 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Nov 2015 16:45:33 -0000 Subject: [GHC] #11103: DuplicateRecordFields + TemplateHaskell Message-ID: <049.e67eee85f02bce8bad5417dcc1d4c2a8@haskell.org> #11103: DuplicateRecordFields + TemplateHaskell -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: bug | 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 Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The [wiki:Records/OverloadedRecordFields/DuplicateRecordFields DuplicateRecordFields] extension works by mangling the Names of field selector functions, and treating fields specially in the renamer. Thus if you define {{{ data T = MkT { foo :: Int } }}} then GHC will actually generate a selector called `$sel:foo:MkT`, but will resolve `foo` to refer to this selector. In general we want this name-mangling to be internal only, but at the moment it is visible when using Template Haskell, because the TH AST doesn't have a way to represent the distinction between the selector name and the field label. For example, if you reify `''T` above and then pretty-print it you will currently get {{{ data T = MkT { $sel:foo:MkT :: Int } }}} which is obviously bad. I'm not sure how best to address this. We could represent the name as `mkNameG_v pkg mod "foo"`, which will look okay when inspected, but if it is subsequently reified it might be ambiguous. Should we add a new `NameFlavour`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 17 17:30:07 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Nov 2015 17:30:07 -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.2d203656b6de791f8da527522d5454fb@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 Rev(s): Phab:D1248 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"233d1312bf15940fca5feca6884f965e7944b555/ghc" 233d131/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="233d1312bf15940fca5feca6884f965e7944b555" MonadFail proposal, phase 1 This implements phase 1 of the MonadFail proposal (MFP, #10751). - MonadFail warnings are all issued as desired, tunable with two new flags - GHC was *not* made warning-free with `-fwarn-missing-monadfail-warnings` (but it's disabled by default right now) Credits/thanks to - Franz Thoma, whose help was crucial to implementing this - My employer TNG Technology Consulting GmbH for partially funding us for this work Reviewers: goldfire, austin, #core_libraries_committee, hvr, bgamari, fmthoma Reviewed By: hvr, bgamari, fmthoma Subscribers: thomie Projects: #ghc Differential Revision: https://phabricator.haskell.org/D1248 GHC Trac Issues: #10751 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 17 19:23:21 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Nov 2015 19:23:21 -0000 Subject: [GHC] #11078: Access to module renaming with reifyModule, in TemplateHaskell In-Reply-To: <049.31454990f3b91e72bda5a21e4cbbf2c4@haskell.org> References: <049.31454990f3b91e72bda5a21e4cbbf2c4@haskell.org> Message-ID: <064.5d8969dd5ef9d5b0e91887f874e06980@haskell.org> #11078: Access to module renaming with reifyModule, in TemplateHaskell -------------------------------------+------------------------------------- Reporter: cipher1024 | Owner: Type: feature request | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jstolarek): Replying to [comment:13 goldfire]: > I'm concerned about `all the things the module could provide`. That sounds like it contains all the exports of the module in question. Yes, that is exactly the case. After some more hacking I believe that `Maybe String` for representing a synonym is not a good idea. We should have a `[String]` instead to store all names used to import a module. For example, if I say: {{{ import Foo import Foo as Bar }}} then the list would contain `[Foo, Bar]`. Replying to [comment:14 osa1]: > You may want to have a look at `HsModule` and `HsParsedModule` types. We can easily pass them(or some information taken from them) to the type checker and they have everything we need. Two questions: 1. Which field of these data types stores the list of *imported* functions? 2. How can we pass data from these to the type checker? Won't this be a gross hack? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 17 20:14:20 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Nov 2015 20:14:20 -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.99a3e2f569ba80afcab9e06bd170f951@haskell.org> #10751: Implement Phase 1 of MonadFail Proposal (MFP) -------------------------------------+------------------------------------- Reporter: hvr | Owner: quchen Type: task | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | 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:D1248 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 17 20:27:06 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Nov 2015 20:27:06 -0000 Subject: [GHC] #11104: Typo in Debug.Trace documentation Message-ID: <046.6ce0f73d57a6d969dc3e9150c837b49c@haskell.org> #11104: Typo in Debug.Trace documentation -------------------------------------+------------------------------------- Reporter: asthasr | Owner: asthasr Type: bug | Status: new Priority: lowest | Milestone: Component: Documentation | 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): | Wiki Page: -------------------------------------+------------------------------------- The documentation for `traceShowM` refers to it as `traceMShow`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 17 20:41:40 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Nov 2015 20:41:40 -0000 Subject: [GHC] #11104: Typo in Debug.Trace documentation In-Reply-To: <046.6ce0f73d57a6d969dc3e9150c837b49c@haskell.org> References: <046.6ce0f73d57a6d969dc3e9150c837b49c@haskell.org> Message-ID: <061.cb401a96a37c21f548f54f746f7d561e@haskell.org> #11104: Typo in Debug.Trace documentation -------------------------------------+------------------------------------- Reporter: asthasr | Owner: asthasr Type: bug | Status: new Priority: lowest | Milestone: Component: Documentation | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by asthasr): Already fixed in `HEAD`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 17 20:41:56 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Nov 2015 20:41:56 -0000 Subject: [GHC] #11104: Typo in Debug.Trace documentation In-Reply-To: <046.6ce0f73d57a6d969dc3e9150c837b49c@haskell.org> References: <046.6ce0f73d57a6d969dc3e9150c837b49c@haskell.org> Message-ID: <061.bf0f58ad40c3b4cae37b64bc0e70a404@haskell.org> #11104: Typo in Debug.Trace documentation -------------------------------------+------------------------------------- Reporter: asthasr | Owner: asthasr Type: bug | Status: closed Priority: lowest | Milestone: Component: Documentation | Version: 7.10.2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by asthasr): * status: new => closed * resolution: => duplicate -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 17 21:08:41 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Nov 2015 21:08:41 -0000 Subject: [GHC] #11105: Put the generic-default type in the Class Message-ID: <046.c36ed1c92d97e0f8dc99e08834c73406@haskell.org> #11105: Put the generic-default type in the Class -------------------------------------+------------------------------------- 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 Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is an internal GHC refactoring ticket. Consider {{{ {-# LANGUAGE DefaultSignatures #-} class C a where op :: a -> a -> Bool default op :: Ord a => a -> a -> Bool op x y = x < y }}} The `Class` object for `C` has a `ClassOpItem` that specifies * the name `op` * the type of the method `a -> a -> Bool` * that `op` has a generic-default signature BUT it does not contain the actual signature `Ord a => a -> a -> Bool`. That's really wrong; it is certainly part of the definition of the class, and we should print it out when we say `:info C` in ghci. Instead this type is kept solely in the top-level generic-default Id binding. But that means that default-method Ids and generic-default method Ids are treated differently; see `gen_dm_ids` in `tcTyClDecl1` in `TcTyClsDecls`, and `mkDefaultMethodIds` in `TcTyDecls`. We should treat them uniformly. I know how but have too much in flight to do it immediately. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 17 23:33:11 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Nov 2015 23:33:11 -0000 Subject: [GHC] #11106: Optimizer changes behavior in 7.10.3 Message-ID: <042.faebe957f0d96a5ae5e616602276a1cf@haskell.org> #11106: Optimizer changes behavior in 7.10.3 -------------------------------------+------------------------------------- Reporter: dsf | 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 Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The repository at https://github.com/ddssff/ghcbug contains a four module package that works when compiled with -O2, but fails when compiled with -O2. The cabal file builds working and failing executable. One of the modules has OPTIONS_GHC -O0 in the header, so the bug is related to mixing modules with different optimization levels. Other than that, I have little idea what is going on. The bug was present in 7.10,2, and is definitely still present in 7.10.3-rc1. I doubt it has been fixed since then. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 17 23:33:41 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Nov 2015 23:33:41 -0000 Subject: [GHC] #11106: Turning on optimizer changes behavior in 7.10.3 (was: Optimizer changes behavior in 7.10.3) In-Reply-To: <042.faebe957f0d96a5ae5e616602276a1cf@haskell.org> References: <042.faebe957f0d96a5ae5e616602276a1cf@haskell.org> Message-ID: <057.5e73f2da69171a42191e2513a2f9b7f6@haskell.org> #11106: Turning on optimizer changes behavior in 7.10.3 -------------------------------------+------------------------------------- Reporter: dsf | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 17 23:39:52 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Nov 2015 23:39:52 -0000 Subject: [GHC] #11106: Turning on optimizer changes behavior in 7.10.3 In-Reply-To: <042.faebe957f0d96a5ae5e616602276a1cf@haskell.org> References: <042.faebe957f0d96a5ae5e616602276a1cf@haskell.org> Message-ID: <057.9d5e6e4000b37360ba7a856ded5af958@haskell.org> #11106: Turning on optimizer changes behavior in 7.10.3 -------------------------------------+------------------------------------- Reporter: dsf | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I guess you "works with -O0"? What does "fails when compiled with -O2" mean? Fails in what way? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 17 23:44:01 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Nov 2015 23:44:01 -0000 Subject: [GHC] #11106: Turning on optimizer changes behavior in 7.10.3 In-Reply-To: <042.faebe957f0d96a5ae5e616602276a1cf@haskell.org> References: <042.faebe957f0d96a5ae5e616602276a1cf@haskell.org> Message-ID: <057.57d4ec37df1d11cb5603c07b2bd7870f@haskell.org> #11106: Turning on optimizer changes behavior in 7.10.3 -------------------------------------+------------------------------------- Reporter: dsf | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dsf): Without the optimizer it outputs a haskell expression generated by Show. With, it says "bug: <>" and exits with a failure code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 17 23:46:13 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Nov 2015 23:46:13 -0000 Subject: [GHC] #11106: Turning on optimizer changes behavior in 7.10.3 In-Reply-To: <042.faebe957f0d96a5ae5e616602276a1cf@haskell.org> References: <042.faebe957f0d96a5ae5e616602276a1cf@haskell.org> Message-ID: <057.bcaf291299aaed0a80b8b107cd916007@haskell.org> #11106: Turning on optimizer changes behavior in 7.10.3 -------------------------------------+------------------------------------- Reporter: dsf | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by dsf: Old description: > The repository at https://github.com/ddssff/ghcbug contains a four module > package that works when compiled with -O2, but fails when compiled with > -O2. The cabal file builds working and failing executable. > > One of the modules has OPTIONS_GHC -O0 in the header, so the bug is > related to mixing modules with different optimization levels. Other than > that, I have little idea what is going on. > > The bug was present in 7.10,2, and is definitely still present in > 7.10.3-rc1. I doubt it has been fixed since then. New description: The repository at https://github.com/ddssff/ghcbug contains a four module package that works when compiled with -O0, but fails when compiled with -O2. The cabal file builds working and failing executable. One of the modules has OPTIONS_GHC -O0 in the header, so the bug is related to mixing modules with different optimization levels. Other than that, I have little idea what is going on. The bug was present in 7.10,2, and is definitely still present in 7.10.3-rc1. I doubt it has been fixed since then. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 18 00:28:24 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Nov 2015 00:28:24 -0000 Subject: [GHC] #11106: Turning on optimizer changes behavior in 7.10.3 In-Reply-To: <042.faebe957f0d96a5ae5e616602276a1cf@haskell.org> References: <042.faebe957f0d96a5ae5e616602276a1cf@haskell.org> Message-ID: <057.e10af451c8f367190a81b8067b14eda2@haskell.org> #11106: Turning on optimizer changes behavior in 7.10.3 -------------------------------------+------------------------------------- Reporter: dsf | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): This project's dependencies took 45 minutes to build. Can you provide a stripped-down reproducer? It helps greatly when testing with different versions of GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 18 00:36:49 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Nov 2015 00:36:49 -0000 Subject: [GHC] #11106: Turning on optimizer changes behavior in 7.10.3 In-Reply-To: <042.faebe957f0d96a5ae5e616602276a1cf@haskell.org> References: <042.faebe957f0d96a5ae5e616602276a1cf@haskell.org> Message-ID: <057.8c0f524972129905091cfcf2fef4ebb2@haskell.org> #11106: Turning on optimizer changes behavior in 7.10.3 -------------------------------------+------------------------------------- Reporter: dsf | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dsf): I just pushed a patch that eliminates the safecopy and uuid dependencies. I'm afraid the main culprit is probably lens, which will be a little harder to remove. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 18 00:46:43 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Nov 2015 00:46:43 -0000 Subject: [GHC] #11106: Turning on optimizer changes behavior in 7.10.3 In-Reply-To: <042.faebe957f0d96a5ae5e616602276a1cf@haskell.org> References: <042.faebe957f0d96a5ae5e616602276a1cf@haskell.org> Message-ID: <057.3532761335c4bf898c69868a26c2693b@haskell.org> #11106: Turning on optimizer changes behavior in 7.10.3 -------------------------------------+------------------------------------- Reporter: dsf | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): How about haskell-src-exts, pandoc, etc.? It looks like you import virtually none of these. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 18 01:04:41 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Nov 2015 01:04:41 -0000 Subject: [GHC] #11106: Turning on optimizer changes behavior in 7.10.3 In-Reply-To: <042.faebe957f0d96a5ae5e616602276a1cf@haskell.org> References: <042.faebe957f0d96a5ae5e616602276a1cf@haskell.org> Message-ID: <057.f09a0449b9b2f8cfd2a8307f1a7f34e1@haskell.org> #11106: Turning on optimizer changes behavior in 7.10.3 -------------------------------------+------------------------------------- Reporter: dsf | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dsf): I those are definitely gone - do you have the latest commits? Its just base, lens, syb, text, ListLike, containers -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 18 01:20:41 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Nov 2015 01:20:41 -0000 Subject: [GHC] #11106: Turning on optimizer changes behavior in 7.10.3 In-Reply-To: <042.faebe957f0d96a5ae5e616602276a1cf@haskell.org> References: <042.faebe957f0d96a5ae5e616602276a1cf@haskell.org> Message-ID: <057.d5f40f2bef2774e4001325528e540f87@haskell.org> #11106: Turning on optimizer changes behavior in 7.10.3 -------------------------------------+------------------------------------- Reporter: dsf | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dsf): Dependency list is now just base, microlens, containers. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 18 02:35:08 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Nov 2015 02:35:08 -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.5debc72746309c6690aff7815e0efbe3@haskell.org> #10168: generalize filterM, mapAndUnzipM, zipWithM, zipWithM_, replicateM, replicateM_ -------------------------------------+------------------------------------- Reporter: strake888 | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.10.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1324 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): The difference is it can only be worse by a O(log n) factor worth of stack usage. On the other hand it can be better by an O(n / log n) factor in terms of both time and space. The upside dwarfs the downside. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 18 02:36:46 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Nov 2015 02:36:46 -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.713b16de7f2283b34f2753e9b34a85fb@haskell.org> #10168: generalize filterM, mapAndUnzipM, zipWithM, zipWithM_, replicateM, replicateM_ -------------------------------------+------------------------------------- Reporter: strake888 | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.10.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1324 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): e.g. We carefully use the doubling scheme mentioned above to handle things `replicateM` and the like in `Data.Sequence` and it makes a night and day difference in the performance of many combinators for generating those structures. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 18 02:45:25 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Nov 2015 02:45:25 -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.5ec1a3b40736e24e198d0b2b464a485a@haskell.org> #10168: generalize filterM, mapAndUnzipM, zipWithM, zipWithM_, replicateM, replicateM_ -------------------------------------+------------------------------------- Reporter: strake888 | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.10.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1324 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): My concern is that it will add that tiny factor to tight loops in `IO` and `ST` where every tiny little bit counts. Admittedly, the fact that I can't use an `STRef s Int` counter and get GHC to put it in a register rules out the use of `replicateM_` for a significant class of such loops, but I suspect my point is still valid. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 18 02:51:30 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Nov 2015 02:51:30 -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.bc04435c298d6f9738fff8abd35d4bab@haskell.org> #10168: generalize filterM, mapAndUnzipM, zipWithM, zipWithM_, replicateM, replicateM_ -------------------------------------+------------------------------------- Reporter: strake888 | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.10.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1324 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): `Data.Sequence` is a bit weird. I doubt too many things offer a Wasserman special like that `replicateA`. Do you know how the doubling approach plays with branch prediction? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 18 03:43:21 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Nov 2015 03:43:21 -0000 Subject: [GHC] #11107: Can't use type wildcard infix Message-ID: <047.12dade849b8507aa88a8aa0ea7d9def2@haskell.org> #11107: Can't use type wildcard infix -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This fails: {{{ foo :: Int `_a` Bool foo = Right True }}} But moving `_a` to be prefix works. I observe the same behavior with an unnamed type wildcard. This was discovered while poking around in the renamer, not in real code! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 18 07:02:14 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Nov 2015 07:02:14 -0000 Subject: [GHC] #11102: `ghc --supported-extension` shall not list `TemplateHaskell` when unsupported In-Reply-To: <042.75105e05b4b7229d1c36f2c44b9a694f@haskell.org> References: <042.75105e05b4b7229d1c36f2c44b9a694f@haskell.org> Message-ID: <057.e0caea8ad41eb2ed80cdb53dcee09d0b@haskell.org> #11102: `ghc --supported-extension` shall not list `TemplateHaskell` when unsupported -------------------------------------+------------------------------------- Reporter: hvr | Owner: bgamari 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 Rev(s): phab:D1484 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"98a4fa5fb740ce43a1787eb5730e35b463a2de79/ghc" 98a4fa5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="98a4fa5fb740ce43a1787eb5730e35b463a2de79" DynFlags: Don't list TemplateHaskell as supported if it's not `-XTemplateHaskell` requires GHCi; don't show it in `--supported-extensions` if it's not supported. Together with https://github.com/haskell/cabal/issues/2644 this allows to finally fix a long-standing annoyance in cabal of not being able to detect availability of TH in build-plans. Fixes #11102 See also https://github.com/haskell/cabal/pull/2930 which provides emulation of this feature for older GHCs. Reviewed By: bgamari Differential Revision: https://phabricator.haskell.org/D1484 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 18 08:10:12 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Nov 2015 08:10: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.1689e57284c670808de3d980100f3cf9@haskell.org> #10726: Upgrade MingW-w64 distributions for windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.3 Component: Build System | Version: 7.11 Resolution: | 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 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by lukexi): Looks like `bindings-GLFW` is also affected, with `__ms_vsnprintf` being the missing symbol this time. (No idea why we're re-exporting symbols but that sounds like a fine solution for getting a release out!) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 18 10:01:58 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Nov 2015 10:01:58 -0000 Subject: [GHC] #11106: Turning on optimizer changes behavior in 7.10.3 In-Reply-To: <042.faebe957f0d96a5ae5e616602276a1cf@haskell.org> References: <042.faebe957f0d96a5ae5e616602276a1cf@haskell.org> Message-ID: <057.d7729ff0675d60c6311b8f66ef607d6a@haskell.org> #11106: Turning on optimizer changes behavior in 7.10.3 -------------------------------------+------------------------------------- Reporter: dsf | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): You can simply copy the microlens files into `src/`, and it becomes reproducible with GHC HEAD without any further packages or downloads (containers comes with GHC). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 18 10:12:06 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Nov 2015 10:12:06 -0000 Subject: [GHC] #11106: Turning on optimizer changes behavior in 7.10.3 In-Reply-To: <042.faebe957f0d96a5ae5e616602276a1cf@haskell.org> References: <042.faebe957f0d96a5ae5e616602276a1cf@haskell.org> Message-ID: <057.fd606707af6802385488b65948b5d643@haskell.org> #11106: Turning on optimizer changes behavior in 7.10.3 -------------------------------------+------------------------------------- Reporter: dsf | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): > Without the optimizer it outputs a haskell expression generated by Show. With, it says "bug: <>" and exits with a failure code. It is not related to `Show`; simply `seq`?ing the first `ReportMap` sufficies. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 18 10:50:00 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Nov 2015 10:50:00 -0000 Subject: [GHC] #11072: Runtime linker doesn't search for DLLs referenced in import libraries on Windows In-Reply-To: <050.675e99e0c3128be1426b83f1c6310ea3@haskell.org> References: <050.675e99e0c3128be1426b83f1c6310ea3@haskell.org> Message-ID: <065.64f3bc26e25677702d6a698819052af1@haskell.org> #11072: Runtime linker doesn't search for DLLs referenced in import libraries on Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2-rc2 (Linking) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Matt): Replying to [comment:4 Phyx-]: > Hi Matt, > > Thanks for the patch!, I will look at it more closely in the weekend. But a few things: > > 1) This does not look for `.lib` files which are just import libs as well If you check existing archive loading mechanics in GHCi it doesn't look for `.lib` files either. Those files are usually produces by MSVC compiler which its not officially supported by GHC as far as i know. I think preferable way of getting libraries on Windows should be MSYS2 anyway as it uses the same compiler as GHC and already comes with really big collection of packages. > 2) I'm a bit weary of having to look for a specific section group. > In particular the `.lib` from from `icuuc.lib` does not have an `.idata$7`. Sadly the exact naming conventions, structure and binary format of this files seems to be very much compiler dependent. I've made no attempt so far to try to target anything except MinGW GCC. > I think it should just be running through the `.idata` sections to find it. I did that in my initial implementation, but then i decided to narrow it down to that specific section in first object file after i saw that its there consistently in all import libraries that ship with MinGW and in all libraries i have installed in my local MSYS2 folder. > 3) We already have code to read in COFF files in `Linker.c`, we probably don't want to maintain this at two points. So I would have expected most of the logic here to be done on the C side. That code is specific to loading of static archives, but i guess it could be duplicated and adapted for this. Still i prefer to work in Haskell land as much as i can. :) > I have also been wondering, these import libs also contain large symbol tables. Presumably because import libraries contain stubs for calling into the dll. > > GHCi supports dynamic loading of archives, would it not be possible to just simply satisfy the linker by just satisfying the symbol resolution with these stubs? Sure we have an extra layer of indirection, but it would be robust and it wouldn't really matter much for the repl. That would certainly be the best solution, but it would requires some more modifications to the linker (see comment bellow). However since I'm not very familiar with specifics of dynamic object code loading I can't help much with that. > What I am asking is, have you considered just correctly locating these import libs and then not returning a `DLL` but an `Archive`? In theory this should still work, but you wouldn't have to read the COFF files. I did try that but it seems to fail for me. For example trying to load import library for `zlib1.dll` named `libz.dll.a`: {{{ C:\Dev\ghc-7.10.2\bin>ghci -Lc:\msys32\mingw32\lib -lz.dll GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help ghc.exe: internal error: checkProddableBlock: invalid fixup in runtime linker: 090a00dc (GHC version 7.10.2 for i386_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 18 11:07:51 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Nov 2015 11:07:51 -0000 Subject: [GHC] #11108: Weak references related crash Message-ID: <046.1b25661a2ebf5aa23d3a93aae541239e@haskell.org> #11108: Weak references related crash ----------------------------------------+---------------------------------- Reporter: Saulzar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.2 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+---------------------------------- I've been getting a Segmentation fault relating to Weak reference use as part of a FRP library (reflex). Attached is a more minimal example which crashes. With debugging on the original problem gave me these problems (on different runs): Most frequently just Segmentation fault (with no stack trace) Occasionally this: {{{ bench: internal error: ASSERTION FAILED: file rts/sm/GCAux.c, line 44 (GHC version 7.10.2 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) }}} and more rarely this: {{{ bench: internal error: WEAK object entered! (GHC version 7.10.2 for x86_64_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 Wed Nov 18 11:08:47 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Nov 2015 11:08:47 -0000 Subject: [GHC] #11108: Weak references related crash In-Reply-To: <046.1b25661a2ebf5aa23d3a93aae541239e@haskell.org> References: <046.1b25661a2ebf5aa23d3a93aae541239e@haskell.org> Message-ID: <061.052eb501312248370372db28bbeb721f@haskell.org> #11108: Weak references related crash -------------------------------------+------------------------------------- Reporter: Saulzar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Saulzar): * Attachment "Test.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 18 11:15:44 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Nov 2015 11:15:44 -0000 Subject: [GHC] #11109: build broken in libffi/ when `install-sh` is used Message-ID: <042.c5cf0db9a7836b481c2ae3c05299838d@haskell.org> #11109: build broken in libffi/ when `install-sh` is used -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Build System | 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): | Wiki Page: -------------------------------------+------------------------------------- If the `/usr/bin/install` tool is missing or not deemed usable by Autoconf, `install-sh` is used. However, GHC's build then fails with {{{ ... ===--- building final phase make --no-print-directory -f ghc.mk phase=final all rts/ghc.mk:543: rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l- debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm: No such file or directory compiler/ghc.mk:661: compiler/stage2/build/.depend-v-dyn.haskell: No such file or directory make -C libffi/build MAKEFLAGS= install MAKE x86_64-unknown-linux-gnu : 0 * install make[3]: Entering directory '/home/hvr/Haskell/GHC/ghc/libffi/build/x86_64 -unknown-linux-gnu' Making install in include make[4]: Entering directory '/home/hvr/Haskell/GHC/ghc/libffi/build/x86_64 -unknown-linux-gnu/include' make[5]: Entering directory '/home/hvr/Haskell/GHC/ghc/libffi/build/x86_64 -unknown-linux-gnu/include' make[5]: Nothing to be done for 'install-exec-am'. /bin/mkdir -p '/home/hvr/Haskell/GHC/ghc/libffi/build/inst/lib/libffi-3.1/include' ../install-sh -c -m 644 ffi.h ffitarget.h '/home/hvr/Haskell/GHC/ghc/libffi/build/inst/lib/libffi-3.1/include' /bin/bash: line 11: ../install-sh: No such file or directory Makefile:361: recipe for target 'install-nodist_includesHEADERS' failed make[5]: *** [install-nodist_includesHEADERS] Error 127 make[5]: Leaving directory '/home/hvr/Haskell/GHC/ghc/libffi/build/x86_64 -unknown-linux-gnu/include' Makefile:477: recipe for target 'install-am' failed make[4]: *** [install-am] Error 2 make[4]: Leaving directory '/home/hvr/Haskell/GHC/ghc/libffi/build/x86_64 -unknown-linux-gnu/include' Makefile:1577: recipe for target 'install-recursive' failed make[3]: *** [install-recursive] Error 1 make[3]: Leaving directory '/home/hvr/Haskell/GHC/ghc/libffi/build/x86_64 -unknown-linux-gnu' Makefile:3095: recipe for target 'install' failed make[2]: *** [install] Error 2 libffi/ghc.mk:116: recipe for target 'libffi/stamp.ffi.static- shared.install' failed make[1]: *** [libffi/stamp.ffi.static-shared.install] Error 2 Makefile:121: recipe for target 'all' failed make: *** [all] Error 2 }}} This can be easily simulated on Linux by temporarily renaming `/usr/bin/install` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 18 11:38:14 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Nov 2015 11:38:14 -0000 Subject: [GHC] #11108: Weak references related crash In-Reply-To: <046.1b25661a2ebf5aa23d3a93aae541239e@haskell.org> References: <046.1b25661a2ebf5aa23d3a93aae541239e@haskell.org> Message-ID: <061.37c4956062e62a277602428287973da0@haskell.org> #11108: Weak references related crash -------------------------------------+------------------------------------- Reporter: Saulzar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Saulzar): This seems to be the culprit - putting a Weak reference inside the original object by way of lazy evalution and do rec. {{{#!hs makePull :: (Weak Pull -> IO Int) -> IO Pull makePull f = do rec foo <- Pull weak f <$> newIORef [] <*> newIORef Nothing weak <- mkWeakPtr foo (Just $ print "died") return foo }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 18 11:49:44 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Nov 2015 11:49:44 -0000 Subject: [GHC] #11109: build broken in libffi/ when `install-sh` is used In-Reply-To: <042.c5cf0db9a7836b481c2ae3c05299838d@haskell.org> References: <042.c5cf0db9a7836b481c2ae3c05299838d@haskell.org> Message-ID: <057.37c4aa020555b6ac9691560e3d8abf43@haskell.org> #11109: build broken in libffi/ when `install-sh` is used -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: patch 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 Rev(s): Phab:D1494 Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * status: new => patch * differential: => Phab:D1494 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 18 11:53:39 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Nov 2015 11:53:39 -0000 Subject: [GHC] #11071: "Not in scope" errors should be more informative for qualified names. In-Reply-To: <047.e970b72d66ebf0753d36739a65af99a0@haskell.org> References: <047.e970b72d66ebf0753d36739a65af99a0@haskell.org> Message-ID: <062.8121aeda264ebd51c33ce88ccab24bcd@haskell.org> #11071: "Not in scope" errors should be more informative for qualified names. -------------------------------------+------------------------------------- Reporter: mojojojo | Owner: nomeata Type: feature request | 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 Rev(s): Phab:D1462 Wiki Page: | Phab:D1478 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"11e336e4a4f7a0c0319d9bfb1a6931a5861299cf/ghc" 11e336e4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="11e336e4a4f7a0c0319d9bfb1a6931a5861299cf" More import related hints Now for unqualified imports. Improves upon #11071. Unfortunately, it seems that since 7.10, ghc will not print all out-of-scope errors. Test Plan: test suite updated Reviewers: austin, thomie, bgamari Reviewed By: bgamari Differential Revision: https://phabricator.haskell.org/D1478 GHC Trac Issues: #11071 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 18 11:57:56 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Nov 2015 11:57:56 -0000 Subject: [GHC] #11106: Turning on optimizer changes behavior in 7.10.3 In-Reply-To: <042.faebe957f0d96a5ae5e616602276a1cf@haskell.org> References: <042.faebe957f0d96a5ae5e616602276a1cf@haskell.org> Message-ID: <057.bcb2ca99d9e21c91c5de1045e32dbaa9@haskell.org> #11106: Turning on optimizer changes behavior in 7.10.3 -------------------------------------+------------------------------------- Reporter: dsf | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Further simplification, removal of derived instances and spreading things out over multiple modules shows that `-O0` has to apply to these four lines only for the bug to occur: {{{ instance Eq ReportElemID where (==) a b = (==) (unReportElemID a) (unReportElemID b) instance Ord ReportElemID where compare a b = compare (unReportElemID a) (unReportElemID b) instance Enum ReportElemID where toEnum = (ReportElemID . toEnum) fromEnum = (fromEnum . unReportElemID) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 18 12:04:58 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Nov 2015 12:04:58 -0000 Subject: [GHC] #11106: Turning on optimizer changes behavior in 7.10.3 In-Reply-To: <042.faebe957f0d96a5ae5e616602276a1cf@haskell.org> References: <042.faebe957f0d96a5ae5e616602276a1cf@haskell.org> Message-ID: <057.9bca9a1f13deb45e0a052cac3316b340@haskell.org> #11106: Turning on optimizer changes behavior in 7.10.3 -------------------------------------+------------------------------------- Reporter: dsf | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Changing {{{ -class Ord k => OrderKey k where +class OrderKey k where }}} in `Order.hs` and adding `Ord k` instances to methods and functions as required also makes the problem go away. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 18 12:19:54 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Nov 2015 12:19:54 -0000 Subject: [GHC] #11071: "Not in scope" errors should be more informative for qualified names. In-Reply-To: <047.e970b72d66ebf0753d36739a65af99a0@haskell.org> References: <047.e970b72d66ebf0753d36739a65af99a0@haskell.org> Message-ID: <062.e95c41bee0256fd2638690b7ddcee87a@haskell.org> #11071: "Not in scope" errors should be more informative for qualified names. -------------------------------------+------------------------------------- Reporter: mojojojo | Owner: nomeata Type: feature request | 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: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1462 Wiki Page: | Phab:D1478 -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: The errors arising from these situations should be greatly improved with nomeata's work. Let us know if you think they could be further improved. Closing this for now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 18 12:29:33 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Nov 2015 12:29:33 -0000 Subject: [GHC] #11080: Open data kinds In-Reply-To: <047.64e06093644ddd3cb76b94e28bef420a@haskell.org> References: <047.64e06093644ddd3cb76b94e28bef420a@haskell.org> Message-ID: <062.5bb910a3db69ec03ec90e6bf5487a26f@haskell.org> #11080: Open data kinds -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: jstolarek Type: feature request | Status: new Priority: low | 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: #6024 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jstolarek): * owner: => jstolarek * related: => #6024 Comment: Note that we also have #6024 (and its wiki page [[wiki:GhcKinds/KindsWithoutData]]), which is about implementing close data kinds without the need for declaring a data type. Can we implement this and #6024 at the same time? It seems to me that the answer is yes. Here is my proposal for the syntax: {{{#!hs -- (1) closed kinds, normal syntax kind Universe = Sum Universe Universe | Prod Universe Universe | K * -- (2) closed kinds, GADT syntax. kind Universe where Sum :: Universe -> Universe -> Universe Prod :: Universe -> Universe -> Universe K :: * -> Universe -- (3) open kinds kind Universe kind instance Sum :: Universe -> Universe -> Universe kind instance Prod :: Universe -> Universe -> Universe kind instance K :: * -> Universe }}} This syntax would steal `kind` as a keyword. Do we feel bad about it? Importantly, do we put this new feature into its own language extension or do we make it part of `DataKinds`? If the former then I don't feel bad about stealing `kind`, as we won't break any of the existing code. But if we put this into `DataKinds` then I might reconsider my preference for syntax. Then again I still would rather break backwards compatibility and have nice syntax then construct verbose syntax for the sake of backwards compatibility. Also, I don't like `data constructor` syntax. I find it misleading as data constructor is a totally different thing than what we are declaring (in fact, in #6024 we specifically wish to avoid creating data constructors). If we made this into a separate language extension, I wonder if that extension would have to be enabled only in modules that declare kinds or also in the ones that use them? How does this feature interact with `* :: *`? In #6024 dreixel says: "[in the future] types and kinds might be collapsed into a single level. That would also destroy the possibility of doing what is asked in this ticket, though." I believe that dreixel's line of reasoning was this: > When we declare `kind K = T`, then `K` is a kind a `T` is a type. But since types and kinds are now the same then we must be able to treat `K` as a type, which makes `T` a value and thus we arrived at declaring a data type. If this was what dreixel meant then I disagree with it. It's like saying that since `Int :: *`, then `*` can be treated as a type and thus `Int` can be treated as a value (whatever that would mean). Another question related to `* :: *` is about namespace collision. If I say: {{{#!hs -- assume DataKinds are enabled, so that C becomes a type data T = C kind K = T | C }}} do we have collisions beetwen definitions of `T`s and `C`s? They are all in namespace of types. On the other hand they could be disambiguated by kind, but I'm not sure if this is acceptable. Aside: if we can index kinds does this mean we have sort polymorphism? I will work on extending [[wiki:GhcKinds/KindsWithoutData]] wiki page, as I think this discussion belongs there (even if closed and open kinds should be implemented separately). Yell if you think otherwise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 18 13:17:00 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Nov 2015 13:17:00 -0000 Subject: [GHC] #11106: Turning on optimizer changes behavior in 7.10.3 In-Reply-To: <042.faebe957f0d96a5ae5e616602276a1cf@haskell.org> References: <042.faebe957f0d96a5ae5e616602276a1cf@haskell.org> Message-ID: <057.083a610289673984b02a600324ec9137@haskell.org> #11106: Turning on optimizer changes behavior in 7.10.3 -------------------------------------+------------------------------------- Reporter: dsf | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): I?m doing further simplification in my fork at https://github.com/nomeata /ghc-bug-11106. No microlens needed any more. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 18 13:28:59 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Nov 2015 13:28:59 -0000 Subject: [GHC] #11072: Runtime linker doesn't search for DLLs referenced in import libraries on Windows In-Reply-To: <050.675e99e0c3128be1426b83f1c6310ea3@haskell.org> References: <050.675e99e0c3128be1426b83f1c6310ea3@haskell.org> Message-ID: <065.0d58c17c9aa3629c93f7c40c1a17230f@haskell.org> #11072: Runtime linker doesn't search for DLLs referenced in import libraries on Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2-rc2 (Linking) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by YitzGale): Replying to [comment:5 Matt]: > If you check existing archive loading mechanics in GHCi it doesn't look for `.lib` files either. Those files are usually produces by MSVC compiler which its not officially supported by GHC as far as i know. I'm not sure what you mean by "not officially supported". Specifying .lib files + DLL files has always been the standard way to use FFI for third party libraries on Windows. > I think preferable way of getting libraries on Windows should be MSYS2 anyway as it uses the same compiler as GHC and already comes with really big collection of packages. MSYS2 is very nice, but its "really big collection of packages" is insignificant compared to the amount of libraries compiled with MSVC and available as lib + DLL. And that's just open source - for proprietary libraries that commercial users of GHC need to link against, MSVC is basically the only option. Mingw is designed to support those, and it has always worked fine in the past. MSYS2 is a rock-solid option, when it's available. And we were grateful for that for {{{text-icu}}}. But is seems to me that it will always be a fallback. The normal way to link to a third-party library on Windows is with .lib files and DLLs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 18 13:39:12 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Nov 2015 13:39:12 -0000 Subject: [GHC] #11106: Turning on optimizer changes behavior in 7.10.3 In-Reply-To: <042.faebe957f0d96a5ae5e616602276a1cf@haskell.org> References: <042.faebe957f0d96a5ae5e616602276a1cf@haskell.org> Message-ID: <057.f1abdd8d108154e7eab7dc5a2e35b621@haskell.org> #11106: Turning on optimizer changes behavior in 7.10.3 -------------------------------------+------------------------------------- Reporter: dsf | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): The test case is now narrowed down a lot, 60 lines in total. The problem seems to be related to polymorphic, exported definitions: If I start to remove type signatures or to merge some of the module, it disappears. This needs looking into by someone with knowledge about the constraint solver. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 18 13:40:50 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Nov 2015 13:40:50 -0000 Subject: [GHC] #11028: Refactor ConDecl In-Reply-To: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> References: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> Message-ID: <061.eca95dcf1130da9eafac16935daec564@haskell.org> #11028: Refactor ConDecl -------------------------------------+------------------------------------- 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Test `ghc-api/annotations/T10399` is expect-broken on this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 18 13:46:01 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Nov 2015 13:46:01 -0000 Subject: [GHC] #11028: Refactor ConDecl In-Reply-To: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> References: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> Message-ID: <061.bfe3a9364d9ce1ede6f7a1c3cfebf595@haskell.org> #11028: Refactor ConDecl -------------------------------------+------------------------------------- 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * cc: alanz, mpickering (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 18 13:48:07 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Nov 2015 13:48:07 -0000 Subject: [GHC] #11110: GHCi documentation says ":show packages" gives a list of packages currently loaded Message-ID: <048.5bc818b972dcddcf9126565c3c1a9f60@haskell.org> #11110: GHCi documentation says ":show packages" gives a list of packages currently loaded -------------------------------------+------------------------------------- Reporter: massysett | 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 Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC manual section 2.7, "GHCi commands", says that ":show packages" shows a list of packages currently loaded. When I run ":show packages" I never get such a list. All I get are package flags, which will report what packages are actually loaded only if GHCi was invoked with "-hide-all- packages". I do not know if the documentation is inaccurate, if GHCi is not doing something it should, or if I am not understanding what it means to "show a list of packages currently loaded". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 18 13:50:59 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Nov 2015 13:50:59 -0000 Subject: [GHC] #11106: Turning on optimizer changes behavior in 7.10.3 In-Reply-To: <042.faebe957f0d96a5ae5e616602276a1cf@haskell.org> References: <042.faebe957f0d96a5ae5e616602276a1cf@haskell.org> Message-ID: <057.a34a8a7f89fb3f169c12d60354a81385@haskell.org> #11106: Turning on optimizer changes behavior in 7.10.3 -------------------------------------+------------------------------------- Reporter: dsf | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): It should be noted that the program runs fine if all modules are built with `-O0`, as well as when all modules are built with `-O`. Just the combination of `-O` passed to ghc, but `-O0` passed to that one module breaks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 18 13:57:54 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Nov 2015 13:57:54 -0000 Subject: [GHC] #11071: "Not in scope" errors should be more informative for qualified names. In-Reply-To: <047.e970b72d66ebf0753d36739a65af99a0@haskell.org> References: <047.e970b72d66ebf0753d36739a65af99a0@haskell.org> Message-ID: <062.ca9c4562e28c15f7150b3b1976b061e2@haskell.org> #11071: "Not in scope" errors should be more informative for qualified names. -------------------------------------+------------------------------------- Reporter: mojojojo | Owner: nomeata Type: feature request | 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: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1462 Wiki Page: | Phab:D1478 -------------------------------------+------------------------------------- Comment (by thomie): Replying to [comment:14 nomeata]: > Thomie, how do you like Phab:D1478? Perfect. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 18 14:13:57 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Nov 2015 14:13:57 -0000 Subject: [GHC] #11072: Runtime linker doesn't search for DLLs referenced in import libraries on Windows In-Reply-To: <050.675e99e0c3128be1426b83f1c6310ea3@haskell.org> References: <050.675e99e0c3128be1426b83f1c6310ea3@haskell.org> Message-ID: <065.fb2350c32dd6091dd15c67000bef057d@haskell.org> #11072: Runtime linker doesn't search for DLLs referenced in import libraries on Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2-rc2 (Linking) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Matt): > I'm not sure what you mean by "not officially supported". Specifying .lib files + DLL files has always been the standard way to use FFI for third party libraries on Windows. In `compiler/ghci/Linker.hs` in function `locateLib` you can see line {{{arch_file = "lib" ++ lib ++ lib_tag <.> "a"}}}. This is how static archive name which will GHCi attempt to load is constructed. When you for example try to link against foo by `ghc -libfoo ...` that option is passed to GCC as GCC is used for linking everything together into final executable or DLL, and GCC can usually link against `.lib` files, unless you try to link against C++ mangled function names of course. But when you invoke `ghci -lfoo ....` now GHCi-s internal linker is used for linking, and he resolves external libraries a bit differently, as you can see in `locateLib` funtion. First it tries to load `foo.dll` and `libfoo.dll`. If that fails it resorts to loading of static archive followed by some more logic after that. However, important distinction between GHCi linker and GCCs linker on Windows is that GHCi can't resolve DLL name from import library. as explained in description of this ticked.This only becomes apparent when DLL name is different than import library name (which is the case with almost all libraries that come with MSYS2). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 18 14:26:33 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Nov 2015 14:26:33 -0000 Subject: [GHC] #11106: Turning on optimizer changes behavior in 7.10.3 In-Reply-To: <042.faebe957f0d96a5ae5e616602276a1cf@haskell.org> References: <042.faebe957f0d96a5ae5e616602276a1cf@haskell.org> Message-ID: <057.e826ffab307b540b8a2f514349da0312@haskell.org> #11106: Turning on optimizer changes behavior in 7.10.3 -------------------------------------+------------------------------------- Reporter: dsf | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): JFTR, the bug is also in HEAD, but not in 7.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 18 14:35:08 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Nov 2015 14:35:08 -0000 Subject: [GHC] #11111: error message for ":show" in GHCi does not show "paths" Message-ID: <048.d85779489b94a6313e0fda1d4a24b87c@haskell.org> #11111: error message for ":show" in GHCi does not show "paths" -------------------------------------+------------------------------------- Reporter: massysett | Owner: Type: bug | Status: new Priority: normal | Milestone: 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 Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If I enter a bad argument to :show in GHCi, the "paths" command is not mentioned: ghci> :show path syntax: :show [ args | prog | prompt | prompt2 | editor | stop | modules | bindings | breaks | context | packages | language ] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 18 14:59:31 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Nov 2015 14:59:31 -0000 Subject: [GHC] #11060: Failing tests on 32 bit platforms In-Reply-To: <044.8903e45b189743246ba884746b94acaa@haskell.org> References: <044.8903e45b189743246ba884746b94acaa@haskell.org> Message-ID: <059.ed2aea83e07541bc768690d87cf0f3c0@haskell.org> #11060: Failing tests on 32 bit platforms -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Test Suite | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): The relevant part of the expected output of this test prior to being mangled by the testsuite driver is, {{{#!hs T8274.$tcN :: TyCon [GblId[ReflectionId], Caf=NoCafRefs, Str=DmdType m, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 50}] T8274.$tcN = TyCon 7479687563082171902## 17616649989360543185## T8274.$trModule }}} So, it appears that the difference here arises from the fact that something formatting a `Data.Typeable.Internal.TyCon` is including an extra `L` while formatting the `Word64#` fingerprints on 32-bit machines. Given that this isn't valid Haskell on 32- nor 64-bit machines, this should likely be fixed. However, I can't for the life of me figure out where this is happening. It would appear that the `Show TyCon` instance is defined in `libraries,base/GHC/Show.hs`, {{{#!hs instance Show TyCon where showsPrec p (TyCon _ _ _ tc_name) = showsPrec p tc_name }}} which clearly doesn't match the output we are seeing here. I've tried looking for `Outputable` instances but the only one I've been able to find is for `typecheck/TyCon.hs`. Perhaps this is being derived by `TcGenDeriv` but I've not seen any logic in there that might be adding this errant `L`. It's all quite perplexing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 18 15:08:55 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Nov 2015 15:08:55 -0000 Subject: [GHC] #11060: Failing tests on 32 bit platforms In-Reply-To: <044.8903e45b189743246ba884746b94acaa@haskell.org> References: <044.8903e45b189743246ba884746b94acaa@haskell.org> Message-ID: <059.7e5a6eb36e51a0edfd3b375726aabb1e@haskell.org> #11060: Failing tests on 32 bit platforms -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Test Suite | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): One of the changes in 89458eba5721de1b6b3378415f26e110bab8cc0f might be what you are looking for. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 18 15:11:25 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Nov 2015 15:11:25 -0000 Subject: [GHC] #11058: selected processor does not support ARM mode In-Reply-To: <046.179fa65419f6552c89ce7f996b230033@haskell.org> References: <046.179fa65419f6552c89ce7f996b230033@haskell.org> Message-ID: <061.448b2a4757e189fc4d8874450532edbf@haskell.org> #11058: selected processor does not support ARM mode ----------------------------------------+------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------ Changes (by bgamari): * cc: bgamari (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 18 15:59:01 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Nov 2015 15:59:01 -0000 Subject: [GHC] #10437: RunHaskell error in HSExtra on Win64 In-Reply-To: <052.aa77c29a6e025461dfccfc1392459b8c@haskell.org> References: <052.aa77c29a6e025461dfccfc1392459b8c@haskell.org> Message-ID: <067.dd39395cb4af09bfed5041736b1220b2@haskell.org> #10437: RunHaskell error in HSExtra on Win64 -------------------------------------+------------------------------------- Reporter: ScottSedgwick | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: runhaskell Operating System: Windows | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 18 16:02:23 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Nov 2015 16:02:23 -0000 Subject: [GHC] #11078: Access to module renaming with reifyModule, in TemplateHaskell In-Reply-To: <049.31454990f3b91e72bda5a21e4cbbf2c4@haskell.org> References: <049.31454990f3b91e72bda5a21e4cbbf2c4@haskell.org> Message-ID: <064.a2a6ef7458a7b3265b1c2fb55378f3ab@haskell.org> #11078: Access to module renaming with reifyModule, in TemplateHaskell -------------------------------------+------------------------------------- Reporter: cipher1024 | Owner: Type: feature request | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): > Which field of these data types stores the list of *imported* functions? I don't think there's a way to get all the imported functions from those types. But we can learn qualified imports by looking at `HsModule`s `hsmodImports :: [LImportDecl]` field. `LImportDecl` has this field: `iDeclHiding :: Maybe (Bool, LIE)`. As far as I understand from the documentation if the `Bool` is `False` it's an explicit import. Otherwise it's an explicit `hiding (...)`. > How can we pass data from these to the type checker? Won't this be a gross > hack? We should decide how to update the state type in type checker to pass this information. I wouldn't call this a hack, if we want this functionality we need to somehow pass this information. Or we can create some new types instead of just passing `HsModule`. I'm busy until next week and I can try some alternative designs next week, unless someone solves this in the meantime. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 18 16:20:42 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Nov 2015 16:20:42 -0000 Subject: [GHC] #11111: error message for ":show" in GHCi does not show "paths" In-Reply-To: <048.d85779489b94a6313e0fda1d4a24b87c@haskell.org> References: <048.d85779489b94a6313e0fda1d4a24b87c@haskell.org> Message-ID: <063.783a6be29943754c5a4d4af4d6658b40@haskell.org> #11111: error message for ":show" in GHCi does not show "paths" -------------------------------------+------------------------------------- Reporter: massysett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 18 16:20:57 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Nov 2015 16:20:57 -0000 Subject: [GHC] #11111: error message for ":show" in GHCi does not show "paths" In-Reply-To: <048.d85779489b94a6313e0fda1d4a24b87c@haskell.org> References: <048.d85779489b94a6313e0fda1d4a24b87c@haskell.org> Message-ID: <063.86f774fe5752370edc59939f7d164018@haskell.org> #11111: error message for ":show" in GHCi does not show "paths" -------------------------------------+------------------------------------- Reporter: massysett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | 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): Wiki Page: | -------------------------------------+------------------------------------- Description changed by mpickering: Old description: > If I enter a bad argument to :show in GHCi, the "paths" command is not > mentioned: > > ghci> :show path > > syntax: :show [ args | prog | prompt | prompt2 | editor | stop | modules > | bindings | breaks | context | packages | language ] New description: If I enter a bad argument to :show in GHCi, the "paths" command is not mentioned: {{{ ghci> :show path syntax: :show [ args | prog | prompt | prompt2 | editor | stop | modules | bindings | breaks | context | packages | language ] }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 18 16:31:05 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Nov 2015 16:31:05 -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.62fea19c0e9d49c8186c5092a13c73c5@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 Rev(s): Phab:D1441 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"c61759d5917996a10b06a286eb5b776e4069e35c/ghc" c61759d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c61759d5917996a10b06a286eb5b776e4069e35c" Fix inconsistent pretty-printing of type families After the changes, the three functions used to print type families were identical, so they are refactored into one. Original RHSs of data instance declarations are recreated and printed in user error messages. RHSs containing representation TyCons are printed in the Coercion Axioms section in a typechecker dump. Add vbar to the list of SDocs exported by Outputable. Replace all text "|" docs with it. Fixes #10839 Reviewers: goldfire, jstolarek, austin, bgamari Reviewed By: jstolarek Subscribers: jstolarek, thomie Differential Revision: https://phabricator.haskell.org/D1441 GHC Trac Issues: #10839 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 18 16:32:14 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Nov 2015 16:32:14 -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.08a04a7b36b61a23ef70f71946b9bfcf@haskell.org> #10168: generalize filterM, mapAndUnzipM, zipWithM, zipWithM_, replicateM, replicateM_ -------------------------------------+------------------------------------- Reporter: strake888 | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.10.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1324 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): > I doubt too many things offer a Wasserman special like that replicateA. Consumption of the result with a Writer, Const, Reader, update monads, all benefit rather disproportionally. The Const case in particular is relevant as it basically shows how we'd foldMap and it and the writer case bring in every Monoid as something that can be folded over optimally. In general the idea of randomly inducing a bias here ensure that nothing smart _can_ be done by the consumer. You enforce worst-case asymptotic behavior by losing sharing. One option to compromise might be to look at a way that RULES can try out the biased association and then write back if it doesn't fuse away? Or even simpler, add RULES to rewrite the IO / ST cases into the biased form. We provably get no benefit from the tree for that style of effect and can't observe the difference in associativity for these concrete cases. As you note basically any transformer is going to have enough overhead to swamp this concern, so it is really only those sorts of things that are problematic. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 18 16:45:55 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Nov 2015 16:45:55 -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.a08c16ff4121bbcdf772f1444f77e926@haskell.org> #10168: generalize filterM, mapAndUnzipM, zipWithM, zipWithM_, replicateM, replicateM_ -------------------------------------+------------------------------------- Reporter: strake888 | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.10.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1324 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I was too tired when I wrote that remark, so I forgot about transformers. `StateT u (ST s)` actually is a perfectly beautiful target for `replicateM_`. With the current definition, that *can* be unboxed, allowing for some serious vector crunching. I think your version should be in the library; I just think it should have a new name. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 18 16:58:00 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Nov 2015 16:58:00 -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.cfbb7f2e76cbd001c30207f963eec448@haskell.org> #10168: generalize filterM, mapAndUnzipM, zipWithM, zipWithM_, replicateM, replicateM_ -------------------------------------+------------------------------------- Reporter: strake888 | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.10.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1324 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I would be worried about not just IO but also some kind of structure that is intended to be produced and consumed in a streaming fashion, in O(1) space. Seems like that could blow up space usage arbitrarily with a repeated-squaring implementation. Including separate versions that use repeated squaring would make more sense (if we should include them at all; the use cases seem obscure and anyone can (already) just provide them in a package outside base). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 18 17:11:00 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Nov 2015 17:11:00 -0000 Subject: [GHC] #11108: Weak references related crash In-Reply-To: <046.1b25661a2ebf5aa23d3a93aae541239e@haskell.org> References: <046.1b25661a2ebf5aa23d3a93aae541239e@haskell.org> Message-ID: <061.d0a172191a34ffc412075fdda6a2f383@haskell.org> #11108: Weak references related crash -------------------------------------+------------------------------------- Reporter: Saulzar | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by erikd): * priority: normal => high * milestone: => 7.10.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 18 17:15:33 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Nov 2015 17:15:33 -0000 Subject: [GHC] #11099: Incorrect warning about redundant constraints In-Reply-To: <047.537aacca9c06ec47d57c61fce1d68f6c@haskell.org> References: <047.537aacca9c06ec47d57c61fce1d68f6c@haskell.org> Message-ID: <062.3495dafa9ee5654577c283d6eb0fae82@haskell.org> #11099: Incorrect warning about redundant constraints -------------------------------------+------------------------------------- Reporter: diatchki | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by diatchki): I don't see how it is redundant---without that constraint I couldn't write the required type for the function: notice that the constraint is used to compute the type of the output from the type of the input. If I was to remove the constraint, then the connection between the input and output type is lost, and so uses of this function would become ambiguous in some contexts. In other situations (e.g., the function `get` [wiki:Proposal/CustomTypeErrors#ExtendedExample here]) this would be not just ambiguous but also plain wrong. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 18 17:24:59 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Nov 2015 17:24:59 -0000 Subject: [GHC] #11099: Incorrect warning about redundant constraints In-Reply-To: <047.537aacca9c06ec47d57c61fce1d68f6c@haskell.org> References: <047.537aacca9c06ec47d57c61fce1d68f6c@haskell.org> Message-ID: <062.851df9a7241d5c4886587e06b41a79f5@haskell.org> #11099: Incorrect warning about redundant constraints -------------------------------------+------------------------------------- Reporter: diatchki | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I understand why you don't want the warning, I'm just saying that the warning is working as designed. Perhaps it would be possible to divine the programmer's intent in this case and suppress the warning automatically. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 18 17:25:46 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Nov 2015 17:25:46 -0000 Subject: [GHC] #11000: Implement `-Wcompat` In-Reply-To: <042.320fb0d4d15a64c4acbdb24f3f1efcf0@haskell.org> References: <042.320fb0d4d15a64c4acbdb24f3f1efcf0@haskell.org> Message-ID: <057.7268a94479ac069bfd0656f7d316b4ef@haskell.org> #11000: Implement `-Wcompat` -------------------------------------+------------------------------------- Reporter: hvr | Owner: quchen Type: feature request | Status: new Priority: high | 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:D1495 Wiki Page: Design/Warnings | -------------------------------------+------------------------------------- Changes (by hvr): * owner: => quchen * differential: => Phab:D1495 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 18 17:25:52 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Nov 2015 17:25:52 -0000 Subject: [GHC] #11000: Implement `-Wcompat` In-Reply-To: <042.320fb0d4d15a64c4acbdb24f3f1efcf0@haskell.org> References: <042.320fb0d4d15a64c4acbdb24f3f1efcf0@haskell.org> Message-ID: <057.03997de4eca0ec70685cf57a3f00d231@haskell.org> #11000: Implement `-Wcompat` -------------------------------------+------------------------------------- Reporter: hvr | Owner: quchen Type: feature request | Status: patch Priority: high | 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:D1495 Wiki Page: Design/Warnings | -------------------------------------+------------------------------------- Changes (by hvr): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 18 18:12:42 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Nov 2015 18:12:42 -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.fd11f87588d3cc17a4f0c8113a63dd03@haskell.org> #10168: generalize filterM, mapAndUnzipM, zipWithM, zipWithM_, replicateM, replicateM_ -------------------------------------+------------------------------------- Reporter: strake888 | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.10.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1324 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): I'll give up on this for now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 18 19:41:46 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Nov 2015 19:41:46 -0000 Subject: [GHC] #11078: Access to module renaming with reifyModule, in TemplateHaskell In-Reply-To: <049.31454990f3b91e72bda5a21e4cbbf2c4@haskell.org> References: <049.31454990f3b91e72bda5a21e4cbbf2c4@haskell.org> Message-ID: <064.d2ed9edb9670f38a0729206a6c0cfd59@haskell.org> #11078: Access to module renaming with reifyModule, in TemplateHaskell -------------------------------------+------------------------------------- Reporter: cipher1024 | Owner: Type: feature request | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jstolarek): Replying to [comment:16 osa1]: > `LImportDecl` has this field: `iDeclHiding :: Maybe (Bool, LIE)`. As far > as I understand from the documentation if the `Bool` is `False` it's an > explicit import. Otherwise it's an explicit `hiding (...)`. Good point. So it looks like we have all the necessary information at hand. When `fst . ideclHiding` is `False` then the second component of the tuple stores the names of imported things. If `fst . ideclHiding` is `True`, then we must compute imported names based on `imv_all_exports` (all things provided by the module) and the second component of `ideclHiding` (hidden things, that need to be excluded from the list). Probably a bit tedious, but doable. We'd need to figure out how to sensibly extract names from `LIE name`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 18 20:01:02 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Nov 2015 20:01:02 -0000 Subject: [GHC] #11072: Runtime linker doesn't search for DLLs referenced in import libraries on Windows In-Reply-To: <050.675e99e0c3128be1426b83f1c6310ea3@haskell.org> References: <050.675e99e0c3128be1426b83f1c6310ea3@haskell.org> Message-ID: <065.f6f800baa47b8a600f9caf19ae72d7d1@haskell.org> #11072: Runtime linker doesn't search for DLLs referenced in import libraries on Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2-rc2 (Linking) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Replying to [comment:7 Matt]: > > I'm not sure what you mean by "not officially supported". Specifying .lib files + DLL files has always been the standard way to use FFI for third party libraries on Windows. > > In `compiler/ghci/Linker.hs` in function `locateLib` you can see line > {{{arch_file = "lib" ++ lib ++ lib_tag <.> "a"}}}. This is how static archive name which will GHCi attempt to load is constructed. > This is just the way it currently is. The Linker also doesn't look for `.dll.a` which you added in your patch. The whole goal is to add support for import libraries. I agree that in the Windows world, outside of the msys2 sandbox, `.lib` are far far more common. Given that the most popular compilers on the platform produce it. But in any case, I am not aware of the format actually being different. Both `.dll.a` and `.lib` are `ar` archives of `COFF` files as far as I know. > Those files are usually produces by MSVC compiler which its not officially supported by GHC as far as i know. GHC doesn't support compiling with MSVC but it does support linking against objects from it. Certainly against loading libs produced by it. At the end of the day, it's GCC and GHC that are compatible with Windows not the other way around. As in, they produce PE and COFF files according to the PE spec. > That code is specific to loading of static archives, but i guess it could be duplicated and adapted for this. It could be that I am missing something here, but I was under the impression that the basic format was the same. That it's just used different (if at all). > I did try that but it seems to fail for me. For example trying to load import library for zlib1.dll named libz.dll.a: That error is because your patch is based on `7.10.2`. This was fixed for `7.10.3`. A lot of work has been done on the Windows linker lately, so it may also be best to try again on `head`. I know you had problems compiling head, but it should prove much easier there. If you need any help or want to discuss further you can always find me in the IRC channel :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 18 23:35:23 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Nov 2015 23:35:23 -0000 Subject: [GHC] #8516: Add (->) representation and the Invariant class to GHC.Generics In-Reply-To: <046.4bd98a18c7a25f1a7eb2c50c7cbb4858@haskell.org> References: <046.4bd98a18c7a25f1a7eb2c50c7cbb4858@haskell.org> Message-ID: <061.12b65f45e5e632042da913aea22d704f@haskell.org> #8516: Add (->) representation and the Invariant class to GHC.Generics -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.7 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I really like the idea of adding `(:->:)` to `GHC.Generics`. One of my biggest gripes with `deriving Generic1` is that it doesn't work with many data types that have function arguments (e.g., `Endo`). I think adding `(:->:)` would allow GHC generics to at least be as expressive as `DeriveFunctor`/`Foldable`/`Traversable`. I'm a bit hesitant about adding `Invariant` to `base`, however, primarily because I find it unlikely that it would ever be made a superclass of `Functor`, given the sheer amount of breakage that would cause. Moreover, I don't think we need `Invariant` to be able to derive `Generic1` for data types with `(:->:)`. I believe at most a generated `Generic1` instance would need some `Functor` constraints, but that's no different than the current story. (I haven't worked out the additional rules you'd need to add to the algorithms in Figures 1-4 of http://dreixel.net/research/pdf/gdmh.pdf, but the examples I've worked out by hand so far have only needed `Functor` constraints.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 19 11:29:07 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Nov 2015 11:29:07 -0000 Subject: [GHC] #11071: "Not in scope" errors should be more informative for qualified names. In-Reply-To: <047.e970b72d66ebf0753d36739a65af99a0@haskell.org> References: <047.e970b72d66ebf0753d36739a65af99a0@haskell.org> Message-ID: <062.e4bc6bb4cf529e9b73be0457d1413082@haskell.org> #11071: "Not in scope" errors should be more informative for qualified names. -------------------------------------+------------------------------------- Reporter: mojojojo | Owner: nomeata Type: feature request | 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: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1462 Wiki Page: | Phab:D1478 -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"a586622c5386610e8ceffca7ef1efdf33d753587/ghc" a586622c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a586622c5386610e8ceffca7ef1efdf33d753587" Release Notes: Mention out-of-scope error message improvements Summary: as implemented for #11071. Differential Revision: https://phabricator.haskell.org/D1498 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 19 12:24:28 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Nov 2015 12:24:28 -0000 Subject: [GHC] #11109: build broken in libffi/ when `install-sh` is used In-Reply-To: <042.c5cf0db9a7836b481c2ae3c05299838d@haskell.org> References: <042.c5cf0db9a7836b481c2ae3c05299838d@haskell.org> Message-ID: <057.22bfbd1a117ac6e97d3b625147eed63d@haskell.org> #11109: build broken in libffi/ when `install-sh` is used -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: patch 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 Rev(s): Phab:D1494 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"3e2a4eefbed7002437c3f3ee340832a42f0b37f8/ghc" 3e2a4ee/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3e2a4eefbed7002437c3f3ee340832a42f0b37f8" Fix broken build-system when libffi uses install-sh Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1494 GHC Trac Issues: #11109 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 19 12:24:28 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Nov 2015 12:24:28 -0000 Subject: [GHC] #10444: Text.Read.Lex.lex broken In-Reply-To: <048.7d303af6bd6af366785c1d3e315fce90@haskell.org> References: <048.7d303af6bd6af366785c1d3e315fce90@haskell.org> Message-ID: <063.055dfcc518430199f640447e1a421c7e@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 Rev(s): Phab:D1122, Wiki Page: | Phab:D1480. -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"fce04651f2389d59b3355c67d9e189c62969ac76/ghc" fce0465/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="fce04651f2389d59b3355c67d9e189c62969ac76" Unbreak Text.Read.Lex.lex on Unicode symbols Reviewers: thomie, hvr, austin, bgamari Reviewed By: bgamari Subscribers: bgamari, thomie Differential Revision: https://phabricator.haskell.org/D1480 GHC Trac Issues: #10444 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 19 12:41:46 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Nov 2015 12:41:46 -0000 Subject: [GHC] #11109: build broken in libffi/ when `install-sh` is used In-Reply-To: <042.c5cf0db9a7836b481c2ae3c05299838d@haskell.org> References: <042.c5cf0db9a7836b481c2ae3c05299838d@haskell.org> Message-ID: <057.dab75d55b5712ae6f61af3863b02fc26@haskell.org> #11109: build broken in libffi/ when `install-sh` is used -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 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 Rev(s): Phab:D1494 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 19 12:42:07 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Nov 2015 12:42:07 -0000 Subject: [GHC] #10444: Text.Read.Lex.lex broken In-Reply-To: <048.7d303af6bd6af366785c1d3e315fce90@haskell.org> References: <048.7d303af6bd6af366785c1d3e315fce90@haskell.org> Message-ID: <063.c943709f2a2963badc7c9ce47f775424@haskell.org> #10444: Text.Read.Lex.lex broken -------------------------------------+------------------------------------- Reporter: strake888 | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1122, Wiki Page: | Phab:D1480. -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 19 13:44:57 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Nov 2015 13:44:57 -0000 Subject: [GHC] #11112: Error message for accidentally using -> instead of => Message-ID: <048.74997cdddf4fddb6f6be3b86d81e7d7a@haskell.org> #11112: Error message for accidentally using -> instead of => -------------------------------------+------------------------------------- Reporter: JulesBean | 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 Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following typo: {{{#!hs sort :: Ord s -> [s] -> [s] sort xs = Data.List.sort xs }}} GHC's error message in 7.10 is {{{ Expected a type, but ?Ord s? has kind ?GHC.Prim.Constraint? In the type signature for ?Main.sort?: Main.sort :: Ord s -> [s] -> [s] }}} I would suggest that mentioning kinds and GHC.Prim.Constraint is a bit unfriendly in a vanilla session (with ConstraintKinds etc switched off). For comparison, the 6.12 error message was {{{ Class `Ord' used as a type In the type signature for `sort': sort :: Ord a -> [a] -> [a] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 19 13:52:13 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Nov 2015 13:52:13 -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.b6cbd27f1c6a5cb6238480a2de28b13c@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 Rev(s): -------------------------------------+------------------------------------- Comment (by Matthew Pickering ): In [changeset:"b72ca3e3fa54b80a2c376e259cd09df60c7106bf/ghc" b72ca3e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b72ca3e3fa54b80a2c376e259cd09df60c7106bf" Pattern Synonym Documentation Summary: This patch adds documentation for record pattern synonyms (D1258) and bundling pattern synonyms with type constructors in export lists (D1152). There are also other small improvements motivated by #10900. Reviewers: goldfire, bgamari, austin Reviewed By: bgamari Subscribers: goldfire, thomie Differential Revision: https://phabricator.haskell.org/D1325 GHC Trac Issues: #10900 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 19 14:48:06 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Nov 2015 14:48:06 -0000 Subject: [GHC] #11113: Type family If is too strict Message-ID: <050.05f921eae40f029dcaf5247a97d85ae6@haskell.org> #11113: Type family If is too strict -------------------------------------+------------------------------------- Reporter: olshanskydr | 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 Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This code {{{#!hs type family Div (k::Nat) (n::Nat) where Div k n = If (CmpNat k n == LT) 0 (1 + Div (k-n) n) }}} is not working. When I try {{{ ghci> :t (Proxy :: Proxy (Div 100 9)) }}} it hangs on. Probably ghci is trying to calculate both '''If''' branches. If I rewrite it this way {{{#!hs type family Div (k::Nat) (n::Nat) where Div k n = Div' k n (CmpNat k n) type family Div' (k::Nat) (n::Nat) (b::Ordering) where Div' k n LT = 0 Div' k n EQ = 1 Div' k n GT = 1 + Div (k-n) n }}} it works well -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 19 15:03:18 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Nov 2015 15:03:18 -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.efeff86de72e9ef3d29dff7be70991de@haskell.org> #10900: Suggestions for improvement of the PatternSynonyms chapter in the User's Guide -------------------------------------+------------------------------------- Reporter: thomie | Owner: mpickering Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 7.10.2 Resolution: fixed | Keywords: | PatternSynonms Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 19 15:05:00 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Nov 2015 15:05:00 -0000 Subject: [GHC] #11113: Type family If is too strict In-Reply-To: <050.05f921eae40f029dcaf5247a97d85ae6@haskell.org> References: <050.05f921eae40f029dcaf5247a97d85ae6@haskell.org> Message-ID: <065.6e521d9418cf73fac529750d676de7d7@haskell.org> #11113: Type family If is too strict -------------------------------------+------------------------------------- Reporter: olshanskydr | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by olshanskydr: Old description: > This code > {{{#!hs > type family Div (k::Nat) (n::Nat) where > Div k n = If (CmpNat k n == LT) 0 (1 + Div (k-n) n) > }}} > is not working. When I try > {{{ > ghci> :t (Proxy :: Proxy (Div 100 9)) > }}} > it hangs on. Probably ghci is trying to calculate both '''If''' branches. > > If I rewrite it this way > {{{#!hs > type family Div (k::Nat) (n::Nat) where > Div k n = Div' k n (CmpNat k n) > > type family Div' (k::Nat) (n::Nat) (b::Ordering) where > Div' k n LT = 0 > Div' k n EQ = 1 > Div' k n GT = 1 + Div (k-n) n > }}} > it works well New description: This code {{{#!hs type family Div (k::Nat) (n::Nat) where Div k n = If (CmpNat k n == LT) 0 (1 + Div (k-n) n) }}} is not working. When I try {{{ ghci> :t (Proxy :: Proxy (Div 100 9)) }}} it hangs on. Probably ghci is trying to calculate both '''If''' branches. If I rewrite it this way {{{#!hs type family Div (k::Nat) (n::Nat) where Div k n = Div' k n (CmpNat k n) type family Div' (k::Nat) (n::Nat) (b::Ordering) where Div' k n LT = 0 Div' k n EQ = 1 Div' k n GT = 1 + Div (k-n) n }}} it works well. This code also not working {{{#!hs type family Div (k::Nat) (n::Nat) where Div k n = Div'' k n (CmpNat k n == LT) type family Div'' (k::Nat) (n::Nat) (b::Bool) where Div'' k n b = If b 0 (1 + Div (k-n) n) }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 19 17:38:06 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Nov 2015 17:38:06 -0000 Subject: [GHC] #11050: [bug] ModOrigin: hidden module redefined In-Reply-To: <049.f4e3e81343960e7ba9d67c8e78ae8ab2@haskell.org> References: <049.f4e3e81343960e7ba9d67c8e78ae8ab2@haskell.org> Message-ID: <064.ddebba579c33d078c5442c469cf97b49@haskell.org> #11050: [bug] ModOrigin: hidden module redefined -------------------------------------+------------------------------------- Reporter: codeonwort | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: ghc-pkg | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * component: Compiler => ghc-pkg -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 19 18:26:45 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Nov 2015 18:26:45 -0000 Subject: [GHC] #11067: Spurious superclass cycle error with type equalities In-Reply-To: <045.f5d44ba3aad0bf1ca48ae450e6c33b15@haskell.org> References: <045.f5d44ba3aad0bf1ca48ae450e6c33b15@haskell.org> Message-ID: <060.79cce1255b3d701f4ff0fb03e7f9fcb2@haskell.org> #11067: Spurious superclass cycle error with type equalities -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Old description: > Some of us today had an idea how to repair Edward Kmett's regrettably > unsound `Data.Constraint.Forall` module. The method works fine in some > cases, but seems to occasionally trigger a spurious superclass cycle > error. > > In the cases I've seen so far, it seems to happen when a class is defined > with a `Forall` superclass, where that `Forall` itself has as parameter > another class, that itself has a type equality superclass. > > Example file (a bit larger than necessary to show how a similar example > without a type equality ''doesn't'' give an error): > {{{#!haskell > {-# LANGUAGE UndecidableInstances #-} > {-# LANGUAGE FlexibleInstances #-} > {-# LANGUAGE ConstraintKinds #-} > {-# LANGUAGE KindSignatures #-} > {-# LANGUAGE PolyKinds #-} > {-# LANGUAGE MultiParamTypeClasses #-} > {-# LANGUAGE TypeFamilies #-} > > import Data.Monoid > import GHC.Exts (Constraint) > > type family Skolem (p :: k -> Constraint) :: k > type family SkolemF (p :: k2 -> Constraint) (f :: k1 -> k2) :: k1 > > -- | A quantified constraint > type Forall (p :: k -> Constraint) = p (Skolem p) > type ForallF (p :: k2 -> Constraint) (f :: k1 -> k2) = p (f (SkolemF p > f)) > > -- These work > class ForallF Monoid t => Monoid1 t > instance ForallF Monoid t => Monoid1 t > > class ForallF Monoid1 t => Monoid2 t > instance ForallF Monoid1 t => Monoid2 t > > -- Changing f a ~ g a to, (Ord (f a), Ord (g a)), say, removes the error > class (f a ~ g a) => H f g a > instance (f a ~ g a) => H f g a > > -- This one gives a superclass cycle error. > class Forall (H f g) => H1 f g > instance Forall (H f g) => H1 f g > }}} > > And the resulting error: > {{{ > Test.hs:31:1: > Cycle in class declaration (via superclasses): > H1 -> Forall -> H -> H > In the class declaration for ?H1? > > Test.hs:31:1: > Cycle in class declaration (via superclasses): > H1 -> Forall -> H -> H > In the class declaration for ?H1? > }}} New description: Some of us today had an idea how to repair Edward Kmett's regrettably unsound `Data.Constraint.Forall` module. The method works fine in some cases, but seems to occasionally trigger a spurious superclass cycle error. In the cases I've seen so far, it seems to happen when a class is defined with a `Forall` superclass, where that `Forall` itself has as parameter another class, that itself has a type equality superclass. Example file (a bit larger than necessary to show how a similar example without a type equality ''doesn't'' give an error): {{{#!haskell {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE FlexibleContexts #-} import Data.Monoid import GHC.Exts (Constraint) type family Skolem (p :: k -> Constraint) :: k type family SkolemF (p :: k2 -> Constraint) (f :: k1 -> k2) :: k1 -- | A quantified constraint type Forall (p :: k -> Constraint) = p (Skolem p) type ForallF (p :: k2 -> Constraint) (f :: k1 -> k2) = p (f (SkolemF p f)) -- These work class ForallF Monoid t => Monoid1 t instance ForallF Monoid t => Monoid1 t class ForallF Monoid1 t => Monoid2 t instance ForallF Monoid1 t => Monoid2 t -- Changing f a ~ g a to, (Ord (f a), Ord (g a)), say, removes the error class (f a ~ g a) => H f g a instance (f a ~ g a) => H f g a -- This one gives a superclass cycle error. class Forall (H f g) => H1 f g instance Forall (H f g) => H1 f g }}} And the resulting error: {{{ Test.hs:31:1: Cycle in class declaration (via superclasses): H1 -> Forall -> H -> H In the class declaration for ?H1? Test.hs:31:1: Cycle in class declaration (via superclasses): H1 -> Forall -> H -> H In the class declaration for ?H1? }}} -- Comment (by thomie): Your example seemed to be missing a `FlexibleContexts` pragma, so I added it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 19 18:43:00 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Nov 2015 18:43:00 -0000 Subject: [GHC] #11114: Can't compile ghc on fedora 23 Message-ID: <047.58b204bbf4ee1c75f774b5888e6dd9e6@haskell.org> #11114: Can't compile ghc on fedora 23 -------------------------------------+------------------------------------- Reporter: waghanza | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: Building GHC (amd64) | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hi, I' m trying to compile (through a ''Docker'' '''container''') ghc 7.10.2 My commands are: {{{ dnf -y install @development-tools @rpm-development-tools glibc-devel ncurses-devel gmp-devel autoconf automake libtool gcc make perl python ghc happy alex git python-sphinx git clone --recursive git://git.haskell.org/ghc.git /opt/ghc git checkout ghc-7.10.2-release ./boot ./configure --prefix=/usr/local make -j$((`grep -c processor /proc/cpuinfo`+1)) }}} The '''make''' process fails. Here is the stack => https://gist.github.com/anonymous/0800967ca05e5a2c65b8 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 19 19:08:03 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Nov 2015 19:08:03 -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.74f6055c5c3d015bd659dfc35750cad1@haskell.org> #10726: Upgrade MingW-w64 distributions for windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.3 Component: Build System | Version: 7.11 Resolution: | 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 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Elieux): Wouldn't this help? I'm sorry if it's not relevant, but it's one of the changes I did when I was testing GHC with MSYS2 mingw-w64 toolchains. {{{ diff --git a/rts/package.conf.in b/rts/package.conf.in index 5c6d240..db1d281 100644 --- a/rts/package.conf.in +++ b/rts/package.conf.in @@ -57,9 +57,7 @@ unresolved symbols. */ ,"bfd", "iberty" /* for debugging */ #endif #ifdef HAVE_LIBMINGWEX -# ifndef INSTALLING /* Bundled Mingw is behind */ ,"mingwex" -# endif #endif #ifdef USE_LIBDW , "elf" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 19 19:09:34 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Nov 2015 19:09:34 -0000 Subject: [GHC] #11114: Can't compile ghc on fedora 23 In-Reply-To: <047.58b204bbf4ee1c75f774b5888e6dd9e6@haskell.org> References: <047.58b204bbf4ee1c75f774b5888e6dd9e6@haskell.org> Message-ID: <062.860d2ffeb42120b11b109d436f16d058@haskell.org> #11114: Can't compile ghc on fedora 23 -------------------------------------+------------------------------------- Reporter: waghanza | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): Run `git submodule update --init` after switching branches, see https://ghc.haskell.org/trac/ghc/wiki/Building/GettingTheSources#Gettingabranch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 19 19:11:15 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Nov 2015 19:11: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.71d79520d6ad06d1169af051344d6e36@haskell.org> #10726: Upgrade MingW-w64 distributions for windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.3 Component: Build System | Version: 7.11 Resolution: | 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 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by Elieux): * cc: Elieux (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 19 19:23:51 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Nov 2015 19:23:51 -0000 Subject: [GHC] #11073: GHC ASSERT when compiling Data.Sequences in the mono-traversable-0.10.0 In-Reply-To: <046.63424d3c1b78177ce6a10bd87299b1b9@haskell.org> References: <046.63424d3c1b78177ce6a10bd87299b1b9@haskell.org> Message-ID: <061.a243fe4f283a0c5e9d50803b67af2a39@haskell.org> #11073: GHC ASSERT when compiling Data.Sequences in the mono-traversable-0.10.0 ---------------------------------------+------------------------------ Reporter: highfly | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: arm Type of failure: Compile-time crash | Test Case: Blocked By: | Blocking: Related Tickets: #10489 | Differential Rev(s): Wiki Page: | ---------------------------------------+------------------------------ Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #10489 Comment: This is a duplicate of #10489, should be fixed. Try the ghc-7.10.3 release candidate. Or create a normal build instead of a debug build (don't set BuildFlavour=devel2 in mk/build.mk). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 19 19:25:51 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Nov 2015 19:25:51 -0000 Subject: [GHC] #7660: warning: conflicting types when compiling via-C In-Reply-To: <049.e381ff0e988b9be58c4264b55de7ee53@haskell.org> References: <049.e381ff0e988b9be58c4264b55de7ee53@haskell.org> Message-ID: <064.bd88cea9d9eb6170e2c8ebad7d412613@haskell.org> #7660: warning: conflicting types when compiling via-C -------------------------------------+------------------------------------- Reporter: singpolyma | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: warning Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): Here's a minimal C fragment extracted from such a `.hc` file which triggers this warning: {{{#!c typedef void *(*(*StgFunPtr)(void))(void); extern StgFunPtr strlen(); }}} If the main purpose of this is to get a pointer to primitives such as `strlen`, then we can use `-fno-builtin` to fix this warning (works w/ clang & gcc). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 19 19:34:46 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Nov 2015 19:34:46 -0000 Subject: [GHC] #7660: warning: conflicting types when compiling via-C In-Reply-To: <049.e381ff0e988b9be58c4264b55de7ee53@haskell.org> References: <049.e381ff0e988b9be58c4264b55de7ee53@haskell.org> Message-ID: <064.7767ab95c77f0cb2f84aa6db1b8a79a1@haskell.org> #7660: warning: conflicting types when compiling via-C -------------------------------------+------------------------------------- Reporter: singpolyma | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: warning Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * owner: => hvr -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 19 19:48:32 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Nov 2015 19:48:32 -0000 Subject: [GHC] #7660: warning: conflicting types when compiling via-C In-Reply-To: <049.e381ff0e988b9be58c4264b55de7ee53@haskell.org> References: <049.e381ff0e988b9be58c4264b55de7ee53@haskell.org> Message-ID: <064.81c2692502f4728d80bc7109defc6672@haskell.org> #7660: warning: conflicting types when compiling via-C -------------------------------------+------------------------------------- Reporter: singpolyma | Owner: hvr Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: warning Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1506 Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * status: new => patch * differential: => Phab:D1506 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 19 20:03:55 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Nov 2015 20:03:55 -0000 Subject: [GHC] #11114: Can't compile ghc on fedora 23 In-Reply-To: <047.58b204bbf4ee1c75f774b5888e6dd9e6@haskell.org> References: <047.58b204bbf4ee1c75f774b5888e6dd9e6@haskell.org> Message-ID: <062.2bfd314e824a236a55c637e218e5032d@haskell.org> #11114: Can't compile ghc on fedora 23 -------------------------------------+------------------------------------- Reporter: waghanza | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by waghanza): thanks it's help ... i will close this ticket if compilation (running) is successful -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 19 22:00:27 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Nov 2015 22:00:27 -0000 Subject: [GHC] #11074: invalid fixup in runtime linker In-Reply-To: <044.8a0aa9f1d3d6c6f83e1369f687f42004@haskell.org> References: <044.8a0aa9f1d3d6c6f83e1369f687f42004@haskell.org> Message-ID: <059.bcdd3948a962ec871b37d3274cca8696@haskell.org> #11074: invalid fixup in runtime linker -------------------------------------+------------------------------------- Reporter: Qinka | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: duplicate | Keywords: invalid fixup | in runtime linker Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10563 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #10563 Comment: Assuming this is fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 19 22:15:02 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Nov 2015 22:15:02 -0000 Subject: [GHC] #11093: T9579 fails on OS X In-Reply-To: <046.f2b64e0980cbc13cb12e4a1a3513a03a@haskell.org> References: <046.f2b64e0980cbc13cb12e4a1a3513a03a@haskell.org> Message-ID: <061.5c70637916da57ff80faa420f1ba0a82@haskell.org> #11093: T9579 fails on OS X ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by thomie): * os: Unknown/Multiple => MacOS X Comment: Maybe a similar change as in 82cf6724b97ed40d5efedfd28bd3cccf90d1dff2 can be performed, where `\+` was replaced by `\{1,\}`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 19 22:15:32 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Nov 2015 22:15:32 -0000 Subject: [GHC] #11093: T9579 fails on OS X In-Reply-To: <046.f2b64e0980cbc13cb12e4a1a3513a03a@haskell.org> References: <046.f2b64e0980cbc13cb12e4a1a3513a03a@haskell.org> Message-ID: <061.6a9c7755e33494a7ecb04750b421c967@haskell.org> #11093: T9579 fails on OS X ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Test Suite | Version: 7.10.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by thomie): * component: Compiler => Test Suite -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 19 22:18:10 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Nov 2015 22:18:10 -0000 Subject: [GHC] #11097: `unlit` executable installed in wrong folder In-Reply-To: <042.e54dd93bfb8a88229d3581e0230ebbc0@haskell.org> References: <042.e54dd93bfb8a88229d3581e0230ebbc0@haskell.org> Message-ID: <057.cc158339cd6e6706ad3120d0791a2215@haskell.org> #11097: `unlit` executable installed in wrong folder -------------------------------------+------------------------------------- Reporter: hvr | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): There is a comment in `mk/install.mk.in` that says: {{{ # datadir is set to libdir here as GHC needs package.conf and unlit # to be in the same place (and things like ghc-pkg need to agree on # where package.conf is, so we just set it globally). }}} I don't understand it either. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 19 22:46:50 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Nov 2015 22:46:50 -0000 Subject: [GHC] #11110: GHCi documentation says ":show packages" gives a list of packages currently loaded In-Reply-To: <048.5bc818b972dcddcf9126565c3c1a9f60@haskell.org> References: <048.5bc818b972dcddcf9126565c3c1a9f60@haskell.org> Message-ID: <063.aed1b1cd540814d2013ac85593914f0f@haskell.org> #11110: GHCi documentation says ":show packages" gives a list of packages currently loaded -------------------------------------+------------------------------------- Reporter: massysett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * failure: None/Unknown => Documentation bug * component: Compiler => GHCi Comment: This was changed in cfb69428a10e245bc5b64417803b637693977b24: {{{ Author: Ian Lynagh Date: Thu Sep 30 21:01:28 2010 +0000 Don't show the loaded packages in ":show packages"; fixes #4300 It's never worked properly, and the information is in ":show linker". }}} It seems `:show linker` isn't documented either. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 19 22:49:38 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Nov 2015 22:49:38 -0000 Subject: [GHC] #11111: error message for ":show" in GHCi does not show "paths" In-Reply-To: <048.d85779489b94a6313e0fda1d4a24b87c@haskell.org> References: <048.d85779489b94a6313e0fda1d4a24b87c@haskell.org> Message-ID: <063.54f311f491d4db0664507a884dd55465@haskell.org> #11111: error message for ":show" in GHCi does not show "paths" -------------------------------------+------------------------------------- Reporter: massysett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | 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: #11110 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * related: => #11110 Comment: `:show imports` and `:show linker` are missing as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 19 22:52:30 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Nov 2015 22:52:30 -0000 Subject: [GHC] Batch modify: #11086, #11087, #11088, #11089, #11090 Message-ID: <20151119225230.5184B3A2FF@ghc.haskell.org> Batch modification to #11086, #11087, #11088, #11089, #11090 by thomie: Action: resolve Comment: Duplicate of #11091, possibly from form resubmission. -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 20 00:17:02 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Nov 2015 00:17:02 -0000 Subject: [GHC] #11115: Indicate missing associated type instances Message-ID: <049.fb6c7c6a0f30ebb45c702e3be6a03ed9@haskell.org> #11115: Indicate missing associated type instances -------------------------------------+------------------------------------- Reporter: rimmington | Owner: 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: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If there is no matching instance for a typeclass that defines an associated type, GHC cannot further reduce an application of that associated type. For nested type family applications, this produces rather large error messages, eg: {{{ :98:20: Couldn't match type ?units-2.3:Data.Metrology.Factor.Normalize (Data.Metrology.Suspicious.Poly.SurfaceUnitFactorsOf (Data.Singletons.Prelude.Tuple.Snd (Data.Metrology.Suspicious.Poly.SplitPrefix (PrefixExp Deci) Deci Core)) units-2.3:Data.Metrology.Factor. at - '['units-2.3:Data.Metrology.Factor.F Core ('Data.Metrology.Z.S 'Data.Metrology.Z.Zero)])? with ?'[]? In the expression: (25 %> centi Core) `ceilToUnit` deci Core In an equation for ?it?: it = (25 %> centi Core) `ceilToUnit` deci Core }}} The cause of the above error message is that `Deci` is not a member of the typeclass `ExpUnitPrefix` that defines the associated type `PrefixExp`. Unfortunately this is not clear at all from the error message, and adding additional class constraints to the appropriate functions doesn't improve things. It would be nice if GHC pointed out that there is no `ExpUnitPrefix Deci` instance, or at least that `PrefixExp Deci` cannot be further reduced. I imagine this would be useful for open type families as well, but I can't comment personally. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 20 00:48:00 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Nov 2015 00:48:00 -0000 Subject: [GHC] #11116: GC reports memory in use way below the actual Message-ID: <056.b4bf1dab28a79e3bb05bc0cf0836bdb1@haskell.org> #11116: GC reports memory in use way below the actual -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | 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 Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following program encodes and decodes a long list of words. The memory in use reported by the GC seems to be off by multiple gigabytes when compared to the reports of the OS. Results shown below. ghc-7.10.2, binary-0.7.6.1. {{{ #!haskell import Control.Exception (evaluate) import Control.Monad (void) import Data.Binary (encode, decode) import qualified Data.ByteString.Lazy as BSL import Data.List (isPrefixOf, foldl') import Data.Word (Word32) import GHC.Stats import System.Mem (performGC) type T = (Word32,[Word32]) main :: IO () main = do let sz = 1024 * 1024 * 15 xs = [ (i,[i]) :: T | i <- [0 .. sz] ] bs = encode xs void $ evaluate $ sum' $ map (\(x, vs) -> x + sum' vs) xs putStrLn "After building the value to encode:" printMem putStrLn $ "Size of the encoded value: " ++ show (BSL.length bs `div` (1024 * 1024)) ++ " MB" putStrLn "" putStrLn "After encoding the value:" printMem let xs' = decode bs :: [T] void $ evaluate $ sum' $ map (\(x, vs) -> x + sum' vs) xs' putStrLn "After decoding the value:" printMem -- retain the original list so it is not GC'ed void $ evaluate $ last xs -- retain the decoded list so it is not GC'ed void $ evaluate $ last xs' printMem :: IO () printMem = do performGC readFile "/proc/self/status" >>= putStr . unlines . filter (\x -> any (`isPrefixOf` x) ["VmHWM", "VmRSS"]) . lines stats <- getGCStats putStrLn $ "In use according to GC stats: " ++ show (currentBytesUsed stats `div` (1024 * 1024)) ++ " MB" putStrLn $ "HWM according the GC stats: " ++ show (maxBytesUsed stats `div` (1024 * 1024)) ++ " MB" putStrLn "" sum' :: Num a => [a] -> a sum' = foldl' (+) 0 }}} Here are the results: {{{ # ghc --make -O -fno-cse -fforce-recomp -rtsopts test.hs # time ./test +RTS -T After building the value to encode: VmHWM: 2782700 kB VmRSS: 2782700 kB In use according to GC stats: 1320 MB HWM according the GC stats: 1320 MB Size of the encoded value: 240 MB After encoding the value: VmHWM: 3064976 kB VmRSS: 3064976 kB In use according to GC stats: 1560 MB HWM according the GC stats: 1560 MB After decoding the value: VmHWM: 7426784 kB VmRSS: 7426784 kB In use according to GC stats: 2880 MB HWM according the GC stats: 2880 MB real 0m24.348s user 0m22.316s sys 0m1.992s }}} At the end of the program the OS reports 7 GB while the GC reports less than 3G of memory in use. Running the program with {{{+RTS -M3G}}} keeps VmHWM bounded at the expense of doubling the execution time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 20 00:51:50 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Nov 2015 00:51:50 -0000 Subject: [GHC] #11116: GC reports memory in use way below the actual In-Reply-To: <056.b4bf1dab28a79e3bb05bc0cf0836bdb1@haskell.org> References: <056.b4bf1dab28a79e3bb05bc0cf0836bdb1@haskell.org> Message-ID: <071.bb134e5f27df68b860bac5b57aef172d@haskell.org> #11116: GC reports memory in use way below the actual -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by facundo.dominguez): * cc: simonmar (added) * failure: None/Unknown => Runtime performance bug * os: Unknown/Multiple => Linux * component: Compiler => Runtime System * architecture: Unknown/Multiple => x86_64 (amd64) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 20 01:21:26 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Nov 2015 01:21:26 -0000 Subject: [GHC] #11116: GC reports memory in use way below the actual In-Reply-To: <056.b4bf1dab28a79e3bb05bc0cf0836bdb1@haskell.org> References: <056.b4bf1dab28a79e3bb05bc0cf0836bdb1@haskell.org> Message-ID: <071.6888fd8493ba802562a8f9bc381e231d@haskell.org> #11116: GC reports memory in use way below the actual -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 7.10.2 Resolution: invalid | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => invalid Comment: `currentBytesUsed` and `maxBytesUsed` are, as documented, "Current number of live bytes" on the heap and "Maximum number of live bytes seen so far" respectively. They are just calculated as the sum of the sizes of all live objects on the heap. Due to the way GHC's copying garbage collector works, the actual space used by the heap will typically be double this size. Then of course there will be additional space used by the runtime system or other C libraries (though that is not significant in this example). `peakMegabytesAllocated` counts everything allocated through the RTS (including any blocks used for heap) and will be closer to the figure you are looking for. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 20 05:51:39 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Nov 2015 05:51:39 -0000 Subject: [GHC] #11060: Failing tests on 32 bit platforms In-Reply-To: <044.8903e45b189743246ba884746b94acaa@haskell.org> References: <044.8903e45b189743246ba884746b94acaa@haskell.org> Message-ID: <059.9cb82c19d7ba64d852be2e038fc883ac@haskell.org> #11060: Failing tests on 32 bit platforms -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Test Suite | 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): Phab:D1507 Wiki Page: | -------------------------------------+------------------------------------- Changes (by erikd): * differential: => Phab:D1507 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 20 06:21:18 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Nov 2015 06:21:18 -0000 Subject: [GHC] #11019: ApiAnnotations: Make all RdrName occurences Located In-Reply-To: <044.6f9b0661f882f5c32756a32bbf81653d@haskell.org> References: <044.6f9b0661f882f5c32756a32bbf81653d@haskell.org> Message-ID: <059.73613e00e68655c84ba621f4a90c3a4a@haskell.org> #11019: ApiAnnotations: Make all RdrName occurences Located -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alanz): Example code from HaRe to enable changing a name {{{#!hs nameSybTransform :: (Monad m,SYB.Typeable t) => (GHC.Located GHC.RdrName -> m (GHC.Located GHC.RdrName)) -> t -> m t nameSybTransform changer = q where q = SYB.mkM worker `SYB.extM` workerBind `SYB.extM` workerExpr `SYB.extM` workerLIE `SYB.extM` workerHsTyVarBndr `SYB.extM` workerLHsType worker (pnt :: (GHC.Located GHC.RdrName)) = changer pnt workerBind (GHC.L l (GHC.VarPat name)) = do (GHC.L _ n) <- changer (GHC.L l name) return (GHC.L l (GHC.VarPat n)) workerBind x = return x workerExpr ((GHC.L l (GHC.HsVar name))) = do (GHC.L _ n) <- changer (GHC.L l name) return (GHC.L l (GHC.HsVar n)) workerExpr x = return x workerLIE ((GHC.L l (GHC.IEVar (GHC.L ln name))) :: (GHC.LIE GHC.RdrName)) = do (GHC.L _ n) <- changer (GHC.L ln name) return (GHC.L l (GHC.IEVar (GHC.L ln n))) workerLIE x = return x workerHsTyVarBndr (GHC.L l (GHC.UserTyVar name)) = do (GHC.L _ n) <- changer (GHC.L l name) return (GHC.L l (GHC.UserTyVar n)) workerHsTyVarBndr x = return x workerLHsType (GHC.L l (GHC.HsTyVar name)) = do (GHC.L _ n) <- changer (GHC.L l name) return (GHC.L l (GHC.HsTyVar n)) workerLHsType x = return x }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 20 09:11:36 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Nov 2015 09:11:36 -0000 Subject: [GHC] #11115: Indicate missing associated type instances In-Reply-To: <049.fb6c7c6a0f30ebb45c702e3be6a03ed9@haskell.org> References: <049.fb6c7c6a0f30ebb45c702e3be6a03ed9@haskell.org> Message-ID: <064.933d94f7446bafb292681469697c44b8@haskell.org> #11115: Indicate missing associated type instances -------------------------------------+------------------------------------- Reporter: rimmington | Owner: Type: feature request | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): That's a good idea. But perhaps `PrefixExp Deci` isn't the villain! It is part of {{{ Data.Metrology.Suspicious.Poly.SplitPrefix (PrefixExp Deci) Deci Core }}} so perhaps the cause is a missing {{{ type instance SplitPrefix x Deci Core = ...x.... }}} I suppose that a possible heuristic would be this: * When reporting a "cant-match" error with `F t1 .. tn ~ ty`, where `F` is a type function, generate a "stuck-heuristic" message for `F t1 .. tn`. To generate a "stuck-heuristic" message for `F t1 .. tn`, * see if the call is "surely apart" from all the instances of `F`. (See our closed-type family paper for "surely-apart".) * If so, report that there is no instance for `F t1 .. tn`. * If not, find a type-function application in `t1 .. tn` (say `G s1 .. sm`) that, if reduced, could perhaps make `F t1 .. tn` fire, if any such application exists. * And generate a stuck-heruristic message for `G s1 .. sm` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 20 10:05:13 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Nov 2015 10:05:13 -0000 Subject: [GHC] #10989: :ctags and :etags command can receive haskell source files as a parameter In-Reply-To: <045.de3e950ef6c4dee2c0f5411e366ebc4e@haskell.org> References: <045.de3e950ef6c4dee2c0f5411e366ebc4e@haskell.org> Message-ID: <060.28ddeb3a93324d78d95325828d7ac0af@haskell.org> #10989: :ctags and :etags command can receive haskell source files as a parameter -------------------------------------+------------------------------------- Reporter: hugomg | Owner: tvv Type: feature request | Status: upstream Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.10.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1471 Wiki Page: | -------------------------------------+------------------------------------- Changes (by tvv): * status: patch => upstream -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 20 12:08:34 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Nov 2015 12:08:34 -0000 Subject: [GHC] #11114: Can't compile ghc on fedora 23 In-Reply-To: <047.58b204bbf4ee1c75f774b5888e6dd9e6@haskell.org> References: <047.58b204bbf4ee1c75f774b5888e6dd9e6@haskell.org> Message-ID: <062.e652c86b5f62e4fac67a7c1771e7760f@haskell.org> #11114: Can't compile ghc on fedora 23 -------------------------------------+------------------------------------- Reporter: waghanza | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by waghanza): it's seems t work then therefore I've a plenty of warnings ... log => https://gist.github.com/eda73024d95356d05ede error log => https://gist.github.com/e3b69e157e89030f627d hope it'll be helpful -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 20 12:12:05 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Nov 2015 12:12:05 -0000 Subject: [GHC] #11114: Can't compile ghc on fedora 23 In-Reply-To: <047.58b204bbf4ee1c75f774b5888e6dd9e6@haskell.org> References: <047.58b204bbf4ee1c75f774b5888e6dd9e6@haskell.org> Message-ID: <062.6049275bbbdcb755a286a8d1b3616043@haskell.org> #11114: Can't compile ghc on fedora 23 -------------------------------------+------------------------------------- Reporter: waghanza | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => invalid Comment: Great. Those warnings are expected, and get ignored with the flags from mk/warnings.mk. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 20 12:34:13 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Nov 2015 12:34:13 -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.4b411e57713ff2a58ee5fa455c1c3f53@haskell.org> #10900: Suggestions for improvement of the PatternSynonyms chapter in the User's Guide -------------------------------------+------------------------------------- Reporter: thomie | Owner: mpickering Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 7.10.2 Resolution: fixed | Keywords: | PatternSynonms Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): Much better. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 20 13:11:06 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Nov 2015 13:11:06 -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.9fac0d0361ef5b657634f510a2f4ccfe@haskell.org> #10900: Suggestions for improvement of the PatternSynonyms chapter in the User's Guide -------------------------------------+------------------------------------- Reporter: thomie | Owner: mpickering Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 7.10.2 Resolution: fixed | Keywords: | PatternSynonms Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): The user guide (which is definitely much improved) still reads > A more complete specification can be found on the ghc-wiki. I really think we should refrain from linking to the wiki from the users guide. For implemented stuff, the user?s guide should contain all that is necessary for a user to understand a feature. If there is anything of relevance in the wiki, then it needs to be moved to the user?s guide. OTOH, if there is nothing of relevance to the user (e.g. rationale for this particular design, implementation aspects, historical notes), then we should send him there. Or at least write something like ?For information on the history, the design process and the implementation, see the ghc- wiki?. If you are worried about duplicated information, then ''remove'' from the wiki page whatever now has its authoritative place in the user?s guide, and maybe link to that from the wiki page. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 20 13:23:38 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Nov 2015 13:23:38 -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.8e62f11b1407d48b5637b6a8a446dfdd@haskell.org> #10900: Suggestions for improvement of the PatternSynonyms chapter in the User's Guide -------------------------------------+------------------------------------- Reporter: thomie | Owner: mpickering Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 7.10.2 Resolution: fixed | Keywords: | PatternSynonms Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Joachim, are you saying there is relevant information on the wiki page which should be in the user guide? Were you able to understand the feature by reading the relevant section? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 20 13:28:08 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Nov 2015 13:28:08 -0000 Subject: [GHC] #8501: Improve error message when using rec/mdo keyword without RecursiveDo extention. In-Reply-To: <047.d2feb1b8bba3b3b1bbfeebc99fe25059@haskell.org> References: <047.d2feb1b8bba3b3b1bbfeebc99fe25059@haskell.org> Message-ID: <062.22f47fe41922a409a8ce3d25fa48581c@haskell.org> #8501: Improve error message when using rec/mdo keyword without RecursiveDo extention. -------------------------------------+------------------------------------- Reporter: shelarcy | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 (Parser) | Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #3968 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 20 13:28:48 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Nov 2015 13:28:48 -0000 Subject: [GHC] #10989: :ctags and :etags command can receive haskell source files as a parameter In-Reply-To: <045.de3e950ef6c4dee2c0f5411e366ebc4e@haskell.org> References: <045.de3e950ef6c4dee2c0f5411e366ebc4e@haskell.org> Message-ID: <060.0251f06ce67e397e91ce5fb62dba8bfa@haskell.org> #10989: :ctags and :etags command can receive haskell source files as a parameter -------------------------------------+------------------------------------- Reporter: hugomg | Owner: tvv Type: feature request | Status: upstream Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.10.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1471 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"a689c8edb1639669cb8df58092b8b77a0a581717/ghc" a689c8ed/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a689c8edb1639669cb8df58092b8b77a0a581717" ghci: don't let ctags/etags overwrite source files A ource file which was accidently passed as parameter into `:ctags` or `:etags` can be overwritten by tag data. This patch updates documentation to avoid confusion in commands usage and prevents `collateAndWriteTags` from modifying existing source files. Reviewed By: thomie, bgamari, austin Differential Revision: https://phabricator.haskell.org/D1471 GHC Trac Issues: #10989 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 20 13:32:09 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Nov 2015 13:32:09 -0000 Subject: [GHC] #11117: mdo blocks in error messages are shown modified Message-ID: <046.ec212f85b7979e3faf4311226423edaa@haskell.org> #11117: mdo blocks in error messages are shown modified -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE RecursiveDo #-} main = mdo Just x <- return (Right x) return () }}} gives {{{ MdoTypeError.hs:3:3: Couldn't match expected type ?Either a0 b0? with actual type ?Maybe b0? Relevant bindings include x :: b0 (bound at MdoTypeError.hs:3:8) In the pattern: Just x In a stmt of an 'mdo' block: Just x <- return (Right x) In a stmt of an 'mdo' block: rec { Just x <- return (Right x) } }}} Note that the error message mentions `rec` even though that is not what the user entered. In other instances, we are careful to show the code more similar to the original (e.g. `do`-notation instead of `>>=`). This should also be done here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 20 13:34:58 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Nov 2015 13:34:58 -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.c57472c8b68919c91462758115777bdd@haskell.org> #10900: Suggestions for improvement of the PatternSynonyms chapter in the User's Guide -------------------------------------+------------------------------------- Reporter: thomie | Owner: mpickering Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 7.10.2 Resolution: fixed | Keywords: | PatternSynonms Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): > Joachim, are you saying there is relevant information on the wiki page which should be in the user guide? I?m not saying that (I didn?t read it in detail). If you think everything important is in the guide, we can simply remove the reference to the wiki, right? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 20 13:37:23 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Nov 2015 13:37:23 -0000 Subject: [GHC] #11115: Indicate missing associated type instances In-Reply-To: <049.fb6c7c6a0f30ebb45c702e3be6a03ed9@haskell.org> References: <049.fb6c7c6a0f30ebb45c702e3be6a03ed9@haskell.org> Message-ID: <064.373fe9eb5091f97385a2321cba3beedf@haskell.org> #11115: Indicate missing associated type instances -------------------------------------+------------------------------------- Reporter: rimmington | Owner: Type: feature request | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I like that idea -- would be very helpful, I think. It's rather like suggestions of missing class instances, no? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 20 13:58:57 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Nov 2015 13:58:57 -0000 Subject: [GHC] #11114: Can't compile ghc on fedora 23 In-Reply-To: <047.58b204bbf4ee1c75f774b5888e6dd9e6@haskell.org> References: <047.58b204bbf4ee1c75f774b5888e6dd9e6@haskell.org> Message-ID: <062.3b792f437e05a7f3c953640cb7bd294b@haskell.org> #11114: Can't compile ghc on fedora 23 -------------------------------------+------------------------------------- Reporter: waghanza | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by waghanza): yeah, I'm tyng to build some deb/rpm for ''ghc''' it's ''long'' .... since debian's offical one is {{{7.6.3}}} and fedora {{{7.8.4}}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 20 14:12:45 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Nov 2015 14:12:45 -0000 Subject: [GHC] #11117: mdo blocks in error messages are shown modified In-Reply-To: <046.ec212f85b7979e3faf4311226423edaa@haskell.org> References: <046.ec212f85b7979e3faf4311226423edaa@haskell.org> Message-ID: <061.41a9b4585ee6de45a81565766bcee360@haskell.org> #11117: mdo blocks in error messages are shown modified -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.3 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): You are dead right ... this is not what GHC usually does. But it's harder here. The renamer re-organises an `mdo` into strongly- connected components, and therefore adds `rec` statements. This message comes from the type checker, which now doesn't know the original program. Not great. I'm not sure the best way to fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 20 14:18:12 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Nov 2015 14:18:12 -0000 Subject: [GHC] #11099: Incorrect warning about redundant constraints In-Reply-To: <047.537aacca9c06ec47d57c61fce1d68f6c@haskell.org> References: <047.537aacca9c06ec47d57c61fce1d68f6c@haskell.org> Message-ID: <062.4737cf194b967097687a1ab83b8ac278@haskell.org> #11099: Incorrect warning about redundant constraints -------------------------------------+------------------------------------- Reporter: diatchki | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): * You want to give a signature to the function that is less polymorphic than its most general type. * You may have legitimate reasons for wanting to do so. * Insofar as you do so by adding a constraint that isn't used, GHC may complain if you use `-fwarn-redundant-constraints`. Hmm. We'd really like a per-function way of suppressing the warning. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 20 15:31:51 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Nov 2015 15:31:51 -0000 Subject: [GHC] #11116: GC reports memory in use way below the actual In-Reply-To: <056.b4bf1dab28a79e3bb05bc0cf0836bdb1@haskell.org> References: <056.b4bf1dab28a79e3bb05bc0cf0836bdb1@haskell.org> Message-ID: <071.e294719c0c2729a76809ab9f5b5240d3@haskell.org> #11116: GC reports memory in use way below the actual -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 7.10.2 Resolution: invalid | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): Also note that the RTS only tracks memory that is allocated on the Haskell heap, it doesn't track memory allocated by C libraries, `malloc`, or `mmap`. So there are several reasons why the memory figure reported by `peakMegabytesAllocated` might be less than the RSS figure from the OS. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 20 16:16:41 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Nov 2015 16:16:41 -0000 Subject: [GHC] #11114: Can't compile ghc on fedora 23 In-Reply-To: <047.58b204bbf4ee1c75f774b5888e6dd9e6@haskell.org> References: <047.58b204bbf4ee1c75f774b5888e6dd9e6@haskell.org> Message-ID: <062.fd91e5c828510507d6c43fdd7bc709cc@haskell.org> #11114: Can't compile ghc on fedora 23 -------------------------------------+------------------------------------- Reporter: waghanza | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by waghanza): compilation was ok, and take less than '''1''' hour (on a '''8''' core machine) my rpm is here : https://www.dropbox.com/s/iu8epk2qtar6021/ghc-7.10.2-1.x86_64.rpm?dl=0 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 20 16:56:02 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Nov 2015 16:56:02 -0000 Subject: [GHC] #11113: Type family If is too strict In-Reply-To: <050.05f921eae40f029dcaf5247a97d85ae6@haskell.org> References: <050.05f921eae40f029dcaf5247a97d85ae6@haskell.org> Message-ID: <065.c5bbc86bb82341b17e03067c71f24f27@haskell.org> #11113: Type family If is too strict -------------------------------------+------------------------------------- Reporter: olshanskydr | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): At one point, I thought I could come up with a terrible hack that would fix this, but I don't think so anymore. What we really need is a proper (preferably lazy!) semantics for type-level reduction. I'm afraid I can't offer any workaround better than the one you've already come up with. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 20 17:54:27 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Nov 2015 17:54:27 -0000 Subject: [GHC] #11116: GC reports memory in use way below the actual In-Reply-To: <056.b4bf1dab28a79e3bb05bc0cf0836bdb1@haskell.org> References: <056.b4bf1dab28a79e3bb05bc0cf0836bdb1@haskell.org> Message-ID: <071.04a22629c57ba1a1fc8c37758203cf5b@haskell.org> #11116: GC reports memory in use way below the actual -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 7.10.2 Resolution: invalid | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by facundo.dominguez): I was a bit surprised of having the application use only 40% of the space for live data, but then I know very little of how the GC is supposed to work. Thanks for taking a look. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 20 19:48:17 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Nov 2015 19:48:17 -0000 Subject: [GHC] #11118: Very hard to load previously compiled .o files in ghci Message-ID: <045.2593ec44962c9fe4a6c94f4d6ce4514f@haskell.org> #11118: Very hard to load previously compiled .o files in ghci -------------------------------------+------------------------------------- Reporter: duncan | 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 Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It's extremely hard to get ghci to load .o files created previously. The upshot is that cabal repl never loads previous .o files. It did used to be also to with older ghc versions. There is currently nothing sensible cabal can do about this except to build things twice (which isn't sensible). When one compiles modules using -static -dynamic-too, then ghci will not load those .o files, even if one specifies the appropriate -dynosuf -dynhisuf. One way to get ghci to load the .o files is if one does not build the static .o files at all, and only builds with -dynamic. This means the main .o files are the dynamic ones. It's possible to do this and keep the sets of files separate, by using -dynamic -osuf dyn_o -hisuf dyn_hi for --make mode, and then again for --interactive mode. However it's then impossible to use the -dynamic-too mode, which we want since it saves time. In this mode, although ghc does indeed generate dyn_o and dyn_hi files, ghci will not load these, even if one specifies -osuf dyn_o -hisuf dyn_hi. If one tries, ghci says "[flags changed]". So it looks like the problem is that the -static -dynamic-too information gets saved into the generated dyn_hi files. The info that should be saved probably should be as if they were generated with -dynamic only. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 20 19:50:17 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Nov 2015 19:50:17 -0000 Subject: [GHC] #11118: Very hard to load previously compiled .o files in ghci In-Reply-To: <045.2593ec44962c9fe4a6c94f4d6ce4514f@haskell.org> References: <045.2593ec44962c9fe4a6c94f4d6ce4514f@haskell.org> Message-ID: <060.6040eb491434d4369db265f0237ede87@haskell.org> #11118: Very hard to load previously compiled .o files in ghci -------------------------------------+------------------------------------- Reporter: duncan | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by duncan: Old description: > It's extremely hard to get ghci to load .o files created previously. The > upshot is that cabal repl never loads previous .o files. It did used to > be also to with older ghc versions. There is currently nothing sensible > cabal can do about this except to build things twice (which isn't > sensible). > > When one compiles modules using -static -dynamic-too, then ghci will not > load those .o files, even if one specifies the appropriate -dynosuf > -dynhisuf. > > One way to get ghci to load the .o files is if one does not build the > static .o files at all, and only builds with -dynamic. This means the > main .o files are the dynamic ones. > > It's possible to do this and keep the sets of files separate, by using > -dynamic -osuf dyn_o -hisuf dyn_hi for --make mode, and then again for > --interactive mode. > > However it's then impossible to use the -dynamic-too mode, which we want > since it saves time. In this mode, although ghc does indeed generate > dyn_o and dyn_hi files, ghci will not load these, even if one specifies > -osuf dyn_o -hisuf dyn_hi. If one tries, ghci says "[flags changed]". > > So it looks like the problem is that the -static -dynamic-too information > gets saved into the generated dyn_hi files. The info that should be saved > probably should be as if they were generated with -dynamic only. New description: It's extremely hard to get ghci to load .o files created previously. The upshot is that cabal repl never loads previous .o files. It did used to be able to with older ghc versions. There is currently nothing sensible cabal can do about this except to build things twice (which isn't sensible). When one compiles modules using -static -dynamic-too, then ghci will not load those .o files, even if one specifies the appropriate -dynosuf -dynhisuf. One way to get ghci to load the .o files is if one does not build the static .o files at all, and only builds with -dynamic. This means the main .o files are the dynamic ones. It's possible to do this and keep the sets of files separate, by using -dynamic -osuf dyn_o -hisuf dyn_hi for --make mode, and then again for --interactive mode. However it's then impossible to use the -dynamic-too mode, which we want since it saves time. In this mode, although ghc does indeed generate dyn_o and dyn_hi files, ghci will not load these, even if one specifies -osuf dyn_o -hisuf dyn_hi. If one tries, ghci says "[flags changed]". So it looks like the problem is that the -static -dynamic-too information gets saved into the generated dyn_hi files. The info that should be saved probably should be as if they were generated with -dynamic only. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 20 20:21:49 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Nov 2015 20:21:49 -0000 Subject: [GHC] #11118: Very hard to load previously compiled .o files in ghci In-Reply-To: <045.2593ec44962c9fe4a6c94f4d6ce4514f@haskell.org> References: <045.2593ec44962c9fe4a6c94f4d6ce4514f@haskell.org> Message-ID: <060.6022851f23af80d6ecb4987a40e045d7@haskell.org> #11118: Very hard to load previously compiled .o files in ghci -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8736 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #8736 Comment: Correct me if I'm wrong, but I think this is a duplicate of #8736. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 20 22:02:15 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Nov 2015 22:02:15 -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.1906a191ececfbf8c14ab5d39b0a1851@haskell.org> #8736: GHCi doesn't load .dyn_o files appropriately -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: thoughtpolice Type: bug | Status: new Priority: high | Milestone: 8.0.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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by duncan): I should point out (as in my dupe ticket #11118) that this causes `cabal repl` to never be able to load .o files for modules previously compiled, and that there is no sensible workaround that `cabal` can use. The only way to make it work, afaics, is to call ghc to build things twice, once for `-static` and once for `-dynamic` outputs. We don't want to do this since it'll almost double compile times compared to using `-dynamic-too`. So this is perhaps more important than spj realised (in #comment:4). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 21 00:01:45 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Nov 2015 00:01:45 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.04c4502078ae842c4d2c6f13a11d20a2@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: #10424 | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, | Phab:D1268, Phab:D1360, Phab:D1373, | Phab:D1396, Phab:D1457, Phab:D1468, Wiki Page: | Phab:D1487, Phab:D1504, Phab:D1508 -------------------------------------+------------------------------------- Changes (by niteria): * differential: Phab:D910, Phab:D1073, Phab:D1133, Phab:D1192, Phab:D1268 => Phab:D910, Phab:D1073, Phab:D1133, Phab:D1192, Phab:D1268, Phab:D1360, Phab:D1373, Phab:D1396, Phab:D1457, Phab:D1468, Phab:D1487, Phab:D1504, Phab:D1508 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 21 00:51:04 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Nov 2015 00:51:04 -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.0506dd71414b57cd65fd5dc20e977302@haskell.org> #10726: Upgrade MingW-w64 distributions for windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.3 Component: Build System | Version: 7.11 Resolution: | 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 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Thanks Elieux! I didn't know I was there, I'll give it a try, would be an easy fix. @lukexi your bullet-mini example doesn't compile: {{{ Preprocessing library bullet-mini-0.1.0.0... [1 of 1] Compiling Physics.Bullet ( src\Physics\Bullet.hs, dist\build\Physics\Bullet.o ) src\Physics\Bullet.cpp:2:36: fatal error: btBulletDynamicsCommon.h: No such file or directory compilation terminated. }}} Did you miss a file? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 21 02:02:01 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Nov 2015 02:02:01 -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.a009b20a416336b607ecf768a470364f@haskell.org> #10726: Upgrade MingW-w64 distributions for windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.3 Component: Build System | Version: 7.11 Resolution: | 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 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by lukexi): Oh I think you need to do `git submodule init && git submodule update`! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 21 02:20:23 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Nov 2015 02:20: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.eb683c01e4a8252c59f21102653b8615@haskell.org> #10726: Upgrade MingW-w64 distributions for windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.3 Component: Build System | Version: 7.11 Resolution: | 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 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by lukexi): (oops, and I forgot to push a fix to the linking test I made a few days ago, so be sure to pull again now!) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 21 03:15:28 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Nov 2015 03:15:28 -0000 Subject: [GHC] #11119: WERROR in build.mk doesn't work Message-ID: <047.e00d8c0ace59eb944ad6685d6676a367@haskell.org> #11119: WERROR in build.mk doesn't work -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- There is a line in `build.mk.sample` that suggests setting `WERROR=-Werror` will turn warnings into errors. This used to work. But now it doesn't, as confirmed by examining the command using `V=1`. I believe the change happened in the last 2-3 weeks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 21 05:07:34 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Nov 2015 05:07:34 -0000 Subject: [GHC] #11120: Missing type representations Message-ID: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> #11120: Missing type representations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: high | 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 Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When I say {{{ {-# LANGUAGE DataKinds #-} module Bug where import Data.Typeable foo = typeRep (Proxy :: Proxy '[]) }}} I get {{{ GHC error in desugarer lookup in Bug: Can't find interface-file declaration for variable tc'[] Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.11.20151120 for x86_64-apple-darwin): initDs IOEnv failure }}} And I think there may be more trouble. Below are notes I have written to ghc-devs: ------------------------------ I'm a bit confused by the new handling of `Typeable`. 1. You say (in `Note [Grand plan for Typeable]`) that there is trouble making the `TyCon`/`Module` information for the types in `GHC.Types`. But what precisely goes wrong? I agree that it seems a bit fishy, but I don't actually see the spot where trouble lurks. Did you try this? 2. Even more bizarre would be putting `TyCon`/`Module` info for `GHC.Prim` stuff (I'm thinking about the super-magical `TYPE` from my branch) right in `GHC.Prim`. But still I can't quite articulate what goes wrong. There is no Prim.hi file that would be wonky. And, provided that `GHC.Types` itself doesn't try to solve a `Typeable` constraint, no one would ever notice the weird dependency. I recognize that this means we'd have to build the info somewhere manually in GHC, but I don't think that would be too hard -- and I think easier than the current story around name-mangling just so that you can write the typereps by hand in `Data.Typeable.Internal`. There's also not very many lifted tycons in `GHC.Prim`. I count `TYPE` and `RealWorld`, and that's it. For what it's worth, a weird dependency from `GHC.Prim` to `GHC.Types` actually works in practice. I put `Levity` in `GHC.Types` but `TYPE :: Levity -> TYPE 'Lifted` in `GHC.Prim`. No one complained. 3. Let's assume that we really can't clean up this mess. It still seems that several `TyCon`s are missing from `Data.Typeable.Internal`. Like promoted nil and cons, and `Nat`, and `Symbol`. At the least, we should put a loud comment in the export list of `GHC.Types` saying that everything defined there must be accompanied by a definition in `Data.Typeable.Internal`. 4. `Data.Typeable.Internal` uses `mkGhcTypesTyCon`, which refers to `GHC.Types`. But this function is used also for things from `GHC.Prim`, like `(->)`. Solving `Typeable (->)` works fine. But I'm sure there's trouble lurking here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 21 08:25:12 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Nov 2015 08:25:12 -0000 Subject: [GHC] #11121: Introduce `-XTemplateHaskellQuotes` pragma for subset of TH Message-ID: <042.c278176d2dd239200103849cc54d10cc@haskell.org> #11121: Introduce `-XTemplateHaskellQuotes` pragma for subset of TH -------------------------------------+------------------------------------- Reporter: hvr | Owner: 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: #10382, #11102 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- TODO: describe why we need this -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 21 08:26:41 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Nov 2015 08:26:41 -0000 Subject: [GHC] #11121: Introduce `-XTemplateHaskellQuotes` pragma for subset of TH In-Reply-To: <042.c278176d2dd239200103849cc54d10cc@haskell.org> References: <042.c278176d2dd239200103849cc54d10cc@haskell.org> Message-ID: <057.907a0d931bb22a9ef5edfff905c42b0f@haskell.org> #11121: Introduce `-XTemplateHaskellQuotes` pragma for subset of TH -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | 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: #10382, #11102 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * component: Compiler => Template Haskell -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 21 08:27:38 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Nov 2015 08:27:38 -0000 Subject: [GHC] #11060: Failing tests on 32 bit platforms In-Reply-To: <044.8903e45b189743246ba884746b94acaa@haskell.org> References: <044.8903e45b189743246ba884746b94acaa@haskell.org> Message-ID: <059.d5ac81538ba3e4c75ccdbea9727b5d6d@haskell.org> #11060: Failing tests on 32 bit platforms -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Test Suite | 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): Phab:D1510 Wiki Page: | -------------------------------------+------------------------------------- Changes (by erikd): * differential: Phab:D1507 => Phab:D1510 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 21 09:56:18 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Nov 2015 09:56:18 -0000 Subject: [GHC] #11121: Introduce `-XTemplateHaskellQuotes` pragma for subset of TH In-Reply-To: <042.c278176d2dd239200103849cc54d10cc@haskell.org> References: <042.c278176d2dd239200103849cc54d10cc@haskell.org> Message-ID: <057.6a51f879a674967e69cdbeba80e782ad@haskell.org> #11121: Introduce `-XTemplateHaskellQuotes` pragma for subset of TH -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | 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: #10382, #11102 | Differential Rev(s): Phab:D1511 Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * differential: => Phab:D1511 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 21 11:45:54 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Nov 2015 11:45:54 -0000 Subject: [GHC] #11119: WERROR in build.mk doesn't work In-Reply-To: <047.e00d8c0ace59eb944ad6685d6676a367@haskell.org> References: <047.e00d8c0ace59eb944ad6685d6676a367@haskell.org> Message-ID: <062.104104f0e418e87d892eac6bca2f5fd5@haskell.org> #11119: WERROR in build.mk doesn't work -------------------------------------+------------------------------------- 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): I think you are experiencing the change from 31bcf9b62ceaed98bdd3b7605e68d315bcff0c8a: "Apply WERROR only to stage2 HC options". You can add the following to your mk/build.mk file (below everything else) to get the old behaviour back: {{{ GhcStage1HcOpts += -Werror }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 21 12:33:41 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Nov 2015 12:33:41 -0000 Subject: [GHC] #9173: Better type error messages In-Reply-To: <046.f8f24aa2ddaa3d579bc40f0b6f04f6b7@haskell.org> References: <046.f8f24aa2ddaa3d579bc40f0b6f04f6b7@haskell.org> Message-ID: <061.5853ccd83491ae851c45e86da5244545@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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): Again discussed in this thread: https://www.reddit.com/r/haskell/comments/3tm3lv/proposal_expectedactual_requiredfound/ Not much new. `expected/found` instead of `expected/actual` seems a popular choice. I vote for switching the order as well, mentioning the word "context", and perhaps omitting the word `actual`. Something like this: {{{ Couldn't match type ?Char? with type ?Bool? expected from context. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 21 12:43:08 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Nov 2015 12:43:08 -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.4a94f54382d96ddc9a7e86432ca1bfa4@haskell.org> #8405: experiment with using function-sections for linking (for smaller libs and executables) -------------------------------------+------------------------------------- Reporter: carter | Owner: olsner Type: task | Status: closed Priority: normal | 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 Rev(s): Phab:D1242 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Tamar Christina ): In [changeset:"7f77e4e9b301493db0782cf2d129cf62dbcd5af6/ghc" 7f77e4e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7f77e4e9b301493db0782cf2d129cf62dbcd5af6" Fix Windows builds after D1242 Summary: Only use the merge_sections.ld linker script if SplitSections is enabled. I thought I had a way to make the linker script actually work on Windows and produce object files instead of image files (by using the "INSERT AFTER" linker script command to get the default script's output format setting), but that fix caused ghci to crash with an illegal instruction on startup. Gave up and made a simpler fix of just disabling this for normal builds, as it's only really relevant with SplitSections enabled anyway. Reviewers: austin, thomie, bgamari Reviewed By: austin, thomie Subscribers: Phyx, thomie Differential Revision: https://phabricator.haskell.org/D1505 GHC Trac Issues: #8405 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 21 15:19:22 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Nov 2015 15:19:22 -0000 Subject: [GHC] #11078: Access to module renaming with reifyModule, in TemplateHaskell In-Reply-To: <049.31454990f3b91e72bda5a21e4cbbf2c4@haskell.org> References: <049.31454990f3b91e72bda5a21e4cbbf2c4@haskell.org> Message-ID: <064.c984571810d034576dae1a089f2a3e2f@haskell.org> #11078: Access to module renaming with reifyModule, in TemplateHaskell -------------------------------------+------------------------------------- Reporter: cipher1024 | Owner: Type: feature request | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I don't have any progress yet but I just wanted to say that passing `HsModule`(or some fields of it) around may not be very bad, and GHC is already doing similar things. For example, `DataCon` has a `[HsSrcBang]` field which is carried around until Cmm(or maybe even backend code generation) stage I think. `HsSrcBang` is this: {{{#!haskell data HsSrcBang = HsSrcBang (Maybe SourceText) SrcUnpackedness SrcStrictness }}} Some(maybe all) parts of this are coming from the parser. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 21 16:15:34 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Nov 2015 16:15:34 -0000 Subject: [GHC] #7660: warning: conflicting types when compiling via-C In-Reply-To: <049.e381ff0e988b9be58c4264b55de7ee53@haskell.org> References: <049.e381ff0e988b9be58c4264b55de7ee53@haskell.org> Message-ID: <064.9500d2f9a07b047e29c7ccdb937993da@haskell.org> #7660: warning: conflicting types when compiling via-C -------------------------------------+------------------------------------- Reporter: singpolyma | Owner: hvr Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: warning Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1506 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"192dd068890701a7692890677d4cbf9f2abdb64a/ghc" 192dd068/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="192dd068890701a7692890677d4cbf9f2abdb64a" Suppress conflicting types for builtins warnings GCC 4.0 and later warn about type-conflicting prototypes for built-in functions such as `strlen`. This is a problem for the via-c backend as it generates code such as typedef void *(*(*StgFunPtr)(void))(void); extern StgFunPtr strlen(); However, by using the `-fno-builtin` flag, GCC is told not to try to auto-detect such built-in functions and instead treat them as ordinary external functions. This also suppresses this warning. This address #7660 Test Plan: IIAM Reviewers: bgamari, austin Reviewed By: austin Subscribers: thomie, erikd Differential Revision: https://phabricator.haskell.org/D1506 GHC Trac Issues: #7660 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 21 16:15:34 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Nov 2015 16:15:34 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.59a41fca0d61e39b602aa1568a5bcb2a@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: #10424 | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, | Phab:D1268, Phab:D1360, Phab:D1373, | Phab:D1396, Phab:D1457, Phab:D1468, Wiki Page: | Phab:D1487, Phab:D1504, Phab:D1508 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"6664ab8356f00ef0b2186f30a0d29a9c0228c045/ghc" 6664ab83/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6664ab8356f00ef0b2186f30a0d29a9c0228c045" Add DVarSet - a deterministic set of Vars This implements `DVarSet`, a deterministic set of Vars, with an interface very similar to `VarSet` with a couple of functions missing. I will need this in changes that follow, one of them will be about changing the type of the set of Vars that `RuleInfo` holds to make the free variable computation deterministic. Test Plan: ./validate I can add new tests if anyone wants me to. Reviewers: simonpj, simonmar, austin, bgamari Reviewed By: simonmar, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1487 GHC Trac Issues: #4012 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 21 16:15:34 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Nov 2015 16:15:34 -0000 Subject: [GHC] #7253: Top-level bindings in ghci In-Reply-To: <048.88d72a7323b37dac89e81e376b48b907@haskell.org> References: <048.88d72a7323b37dac89e81e376b48b907@haskell.org> Message-ID: <063.69fb8f88efa397ed5bd0fd3725874838@haskell.org> #7253: Top-level bindings in ghci -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: roshats 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 Rev(s): Phab:D1299 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"b98ff3ccb14e36145404f075349c8689762a2913/ghc" b98ff3cc/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b98ff3ccb14e36145404f075349c8689762a2913" Function definition in GHCi This patch allows define and re-define functions in ghci. `let` is not required anymore (but can be used). Idea: If ghci input string can be parsed as statement then run it as statement else run it as declaration. Reviewers: mpickering, bgamari, austin Reviewed By: mpickering, bgamari, austin Subscribers: hvr, mpickering, dterei, thomie Differential Revision: https://phabricator.haskell.org/D1299 GHC Trac Issues: #7253 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 21 16:15:34 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Nov 2015 16:15:34 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.74db19106f36c93b3b67977eefd83be9@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: #10424 | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, | Phab:D1268, Phab:D1360, Phab:D1373, | Phab:D1396, Phab:D1457, Phab:D1468, Wiki Page: | Phab:D1487, Phab:D1504, Phab:D1508 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"2325bd4e0fad0e5872556c5a78d1a6a1873e7201/ghc" 2325bd4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2325bd4e0fad0e5872556c5a78d1a6a1873e7201" Create a deterministic version of tyVarsOfType I've run into situations where I need deterministic `tyVarsOfType` and this implementation achieves that and also brings an algorithmic improvement. Union of two `VarSet`s takes linear time the size of the sets and in the worst case we can have `n` unions of sets of sizes `(n-1, 1), (n-2, 1)...` making it quadratic. One reason why we need deterministic `tyVarsOfType` is in `abstractVars` in `SetLevels`. When we abstract type variables when floating we want them to be abstracted in deterministic order. Test Plan: harbormaster Reviewers: simonpj, goldfire, austin, hvr, simonmar, bgamari Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1468 GHC Trac Issues: #4012 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 21 17:34:33 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Nov 2015 17:34:33 -0000 Subject: [GHC] #11119: WERROR in build.mk doesn't work In-Reply-To: <047.e00d8c0ace59eb944ad6685d6676a367@haskell.org> References: <047.e00d8c0ace59eb944ad6685d6676a367@haskell.org> Message-ID: <062.dd048dbe7723fcf61beb93fa767d70e5@haskell.org> #11119: WERROR in build.mk doesn't work -------------------------------------+------------------------------------- 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Yes -- that sounds right. I'm fine with the new behavior, but it should be documented in build.mk.sample. Thanks for the clarification. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 21 17:44:25 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Nov 2015 17:44:25 -0000 Subject: [GHC] #9173: Better type error messages In-Reply-To: <046.f8f24aa2ddaa3d579bc40f0b6f04f6b7@haskell.org> References: <046.f8f24aa2ddaa3d579bc40f0b6f04f6b7@haskell.org> Message-ID: <061.59d72c956739c57d6ae0d6bb454c0336@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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Once Phab:D808 gets merged (could be today! but more likely in 2-3), printing out the expression that has the bad type will be much easier, as I've restructured how that information sloshes around internally. So that will be a viable improvement very soon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 21 17:47:36 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Nov 2015 17:47:36 -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.3874e7b87f443c444e2920a7526515f2@haskell.org> #10726: Upgrade MingW-w64 distributions for windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.3 Component: Build System | Version: 7.11 Resolution: | 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 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Matt): Replying to [comment:39 Phyx-]: > I guess a temporary solution to get `7.10.3` out the door is to just re- export everything from `mingwex` since you can't actually specify `-lmingwex` current. > > But I have wondered and still do why the RTS is re-exporting symbols like this instead of us just linking against `-lmingwex`. I think the main issue here is that not all symbols from `libmingwex.a` get linked into final ghc executable so some they can't be resolved when running GHC in interactive. Therefore i believe proper solution should be linking `libmingwex.a`as a whole archive when building ghc.exe, instead of just letting GCC to link only used symbols as it does by default. Reexporting those symbols seems like a bad idea, because, if I'm not mistaken, RTS gets linked into ever executable produced by GHC, so this way we are actually forcing possibly unnecessary symbols into every executable? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 21 18:04:59 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Nov 2015 18:04:59 -0000 Subject: [GHC] #11120: Missing type representations In-Reply-To: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> References: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> Message-ID: <062.ac9763ef213178a7ac56f4d09cd4940e@haskell.org> #11120: Missing type representations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: high | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): While I'm learning more about this, I stumbled across the following, in !TcTypeable: {{{#!hs mkTyConRepBinds :: TypeableStuff -> TyCon -> LHsBinds Id mkTyConRepBinds (dflags, mod_expr, pkg_str, mod_str, tr_datacon, trn_datacon) tycon = ... where Fingerprint high low | gopt Opt_SuppressUniques dflags = Fingerprint 0 0 | otherwise = fingerprintString hashThis }}} That looks like the tycon's fingerprint is bogus whenever the module is compiled with `-dsuppress-uniques`. But I always understood `-dsuppress- uniques` to be a flag used only to control output, and that it should affect only the pretty-printer. So I'm very dubious of this code. However, in looking through !TcTypeable, I understand why you're worried about typerep-generation in GHC.Types: this module looks up the datacons, etc., from the type environment. I had blithely assumed that the typerep types were truly wired in, in all their glory, making the lookup unnecessary. Looking them up never even occurred to me. So: Is it better to 1. look them up, forgo wiring in all the details, and have special-casing around GHC.Prim and GHC.Types? or 2. wire them in fully, but then have a much simpler story around GHC.Types and GHC.Prim. But now at least I understand what the tradeoff is (I think). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 21 19:19:16 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Nov 2015 19:19:16 -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.dac34d53a8b2e7a2b33290b8c9a7e517@haskell.org> #10726: Upgrade MingW-w64 distributions for windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.3 Component: Build System | Version: 7.11 Resolution: | 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 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): @lukexi thanks, can reproduce it now :) @Elieux unfortunately it seems it's not that easy. The `rts` seems to be a special case again. The linker seems to ignore the `extra-libraries` from the `package.conf`, which explains why you can put anything you want in there and it'll still compile. {{{ 128 emptyPLS :: DynFlags -> PersistentLinkerState 129 emptyPLS _ = PersistentLinkerState { 130 closure_env = emptyNameEnv, 131 itbl_env = emptyNameEnv, 132 pkgs_loaded = init_pkgs, 133 bcos_loaded = [], 134 objs_loaded = [], 135 temp_sos = [] } 136 137 -- Packages that don't need loading, because the compiler 138 -- shares them with the interpreted program. 139 -- 140 -- The linker's symbol table is populated with RTS symbols using an 141 -- explicit list. See rts/Linker.c for details. 142 where init_pkgs = [rtsUnitId] }}} > Therefore i believe proper solution should be linking `libmingwex.a`as a whole archive when building ghc.exe, instead of just letting GCC to link only used symbols as it does by default. Hence the temporary solution. The package.conf for the `rts` ignores the `extra-libraries` section in the linker. Windows isn't alone here, Mac also re-exports some symbols. And before ripping this out I want to know why. Also I think it's riskier then just adding some extra symbols. **As** it is right now, there is no way to use `libmingwex.a` on Windows. > Reexporting those symbols seems like a bad idea, because, if I'm not mistaken, RTS gets linked into ever executable produced by GHC, so this way we are actually forcing possibly unnecessary symbols into every executable? Yes, I don't know why it was done this way. However we are already re- exporting some of the symbols. Quite a few in fact. Yes the proper solution is to rip the symbols out and just link against `libmingwex.a` which may get in to `8.0`, but for `7.10.3` I doubt it. It's already at `RC3`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 21 20:41:58 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Nov 2015 20:41:58 -0000 Subject: [GHC] #11019: ApiAnnotations: Make all RdrName occurences Located In-Reply-To: <044.6f9b0661f882f5c32756a32bbf81653d@haskell.org> References: <044.6f9b0661f882f5c32756a32bbf81653d@haskell.org> Message-ID: <059.8bb9b8f806a62817739cb9ac2cf0656a@haskell.org> #11019: ApiAnnotations: Make all RdrName occurences Located -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:1512 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * differential: => Phab:1512 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 21 21:26:11 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Nov 2015 21:26:11 -0000 Subject: [GHC] #10524: PolyKinds doesn't interact well with DeriveFunctor In-Reply-To: <050.7408f13045aa603e186c148218ece722@haskell.org> References: <050.7408f13045aa603e186c148218ece722@haskell.org> Message-ID: <065.ff66f87716eefd92f6b1c3c24b339d8a@haskell.org> #10524: PolyKinds doesn't interact well with DeriveFunctor -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10561 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): In my soon-to-be-merged branch, I can now accept the program in comment:7. I have not looked at the other issues at work here, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 21 22:10:55 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Nov 2015 22:10:55 -0000 Subject: [GHC] #5082: Emit warnings when conflicting flags are supplied In-Reply-To: <045.d94b5a730c81b9ffc21042de2f389b20@haskell.org> References: <045.d94b5a730c81b9ffc21042de2f389b20@haskell.org> Message-ID: <060.a96aa4738cd7c347d9212588d42670c7@haskell.org> #5082: Emit warnings when conflicting flags are supplied -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: closed Priority: low | Milestone: ? Component: Compiler | Version: 7.1 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => wontfix -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 21 22:20:11 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Nov 2015 22:20:11 -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.bbcbeb689c66412b670f1f668b5bf642@haskell.org> #7746: Support loading/unloading profiled objects from a profiled executable -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: closed Priority: lowest | Milestone: ? Component: Runtime System | Version: 7.7 (Linker) | Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 4837, 5435, 8039 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => duplicate * blockedby: 5435, 8039 => 4837, 5435, 8039 Comment: Fixed by #4837! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 21 22:21:08 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Nov 2015 22:21:08 -0000 Subject: [GHC] #7790: Add dummy undefined symbols to indicate ways In-Reply-To: <045.d04c5bfcd457784d65a81b621d13f03e@haskell.org> References: <045.d04c5bfcd457784d65a81b621d13f03e@haskell.org> Message-ID: <060.d9d8af6be4ab87ef2014d42d8c885d83@haskell.org> #7790: Add dummy undefined symbols to indicate ways -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: low | Milestone: 8.0.1 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * priority: normal => low -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 21 22:28:07 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Nov 2015 22:28:07 -0000 Subject: [GHC] #8199: Get rid of HEAP_ALLOCED on Windows (and other non-Linux platforms) (was: Get rid of HEAP_ALLOCED) In-Reply-To: <045.61ceff1405fed9aab9c8f0fda5e9d453@haskell.org> References: <045.61ceff1405fed9aab9c8f0fda5e9d453@haskell.org> Message-ID: <060.3cae0051d06df248d2f3f8104d48dae6@haskell.org> #8199: Get rid of HEAP_ALLOCED on Windows (and other non-Linux platforms) -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: low | 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: Blocked By: 5435 | Blocking: Related Tickets: | Differential Rev(s): D207 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * priority: normal => low Old description: > This bug is to track progress of removing HEAP_ALLOCED from GHC, > promising faster GC (especially for large/scattered heaps), as long as we > can keep the cost of indirections down. > > The relevant wiki article: > http://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/HeapAlloced ; > we are implementing method 2. Version 2 of the patchset is probably > correct. > > Blocking problems: > > * Properly handle the Windows DLL case (e.g. SRTs). We will probably have > to reorganize how the indirections are laid out. > > * ~~Make it work for GHCi linking of static objects.~~ Blocked on #2841, > I have it working for ELF, and can make it work for other platforms as > soon as I get relevant machines. > > * Bikeshed hs_main API changes (because closures are not valid prior to > RTS initialization, so you have to pass in an indirection instead) > > * Does not work with unloadObj (see comments below) > > Performance improvements possible: > > * ~~This patch introduces a lot of new symbols; ensure we are not unduly > polluting the symbol tables. (In particular, I think _static_closure > symbols can be made hidden).~~ ~~I've eliminated all of these except for > the init symbols, which cross the stub object and assembly file boundary, > and so would need to be made invisible by the linker.~~ I needed to make > local info tables public. > > * Don't pay for a double indirection when -fPIC is turned on. Probably > the easiest way to do this is to *not* bake in the indirections into > compiled code when it is -fPIC'd, and instead scribble over the GOT. > However, I don't know how to go backwards from a symbol to a GOT entry, > so we might need some heinous assembly hacks to get this working. > > * The old HEAP_ALLOCED is supposed to be pessimal on very large heaps. Do > some performance tests under those workloads. > > * Make sure the extra indirection is not causing any C-- optimizations to > stop firing (it might be, because I put it in as a literal CmmLoad) > > * Once an static thunk is updated, we can tag the indirection to let > other code segments to know about the good news. One way to do this is > have the update frame for a static indirection should have a reference to > the *indirection*, not the closure itself. However, this scheme will not > affect other static closures which have references to the thunk. > > * Closure tables should have their indirections short-circuited by the > initialization code. But maybe it is not worth the cost of telling the > RTS about the closure tables (also, they would need to be made > writeable). > > * We are paying an indirection when a GC occurs when the closure is not > in R1. According to the wiki page, technically this is not needed, but I > don't know how to eliminate references to the closure itself from > stg_gc_fun. > > * ~~Save tags inside the indirection tables, so that we don't spend > instructions retagging after the following the indirection.~~ Done. > > * ~~Improve static indirection and stable pointer registration, avoiding > binary bloat from `__attribute(constructor)__` stubs.~~ After discussing > this with some folks, it seems that there isn't really a portable way to > do this when we are using the system dynamic linker to load libraries at > startup. The problem is that we need to somehow get a list of all the > GHC-compiled libraries which got loaded, and really the easiest way to > get that is to just build it ourselves. > > * ~~Need to implement a new megablock tracking structure so we can > free/check for lost blocks~~. Now that efficient lookup is not necessary, > perhaps we can write-optimize the megablock tracking structures. > > Speculative improvements: > > * Now that static lives in a block, can we GC them like we GC normal > data? This would be beneficial for static thunks, which now can have > their indirections completely removed; reverting CAFs may be somewhat > tricky, however. > > * Now that HEAP_ALLOCED is greatly simplified, can we further simply some > aspects of the GC? At the very least, we ought to be able to make > megablock allocation cheaper, by figuring out how to remove the > spinlocks, etc. > > * Another possibility is to adopt a hybrid approach, where we manually > lay out closures when compiling statically, and indirect when compiling > dynamically. In some sense, this gets the best of both worlds, since we > expect to not pay any extra cost for indirection due to PIC. New description: Update for readers: we fixed this for Linux with #9706. But may systems (including Windows) can't handle reserving this much memory. Some other technique is necessary in these cases. This is one possibility. ---- This bug is to track progress of removing HEAP_ALLOCED from GHC, promising faster GC (especially for large/scattered heaps), as long as we can keep the cost of indirections down. The relevant wiki article: http://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/HeapAlloced ; we are implementing method 2. Version 2 of the patchset is probably correct. Blocking problems: * Properly handle the Windows DLL case (e.g. SRTs). We will probably have to reorganize how the indirections are laid out. * ~~Make it work for GHCi linking of static objects.~~ Blocked on #2841, I have it working for ELF, and can make it work for other platforms as soon as I get relevant machines. * Bikeshed hs_main API changes (because closures are not valid prior to RTS initialization, so you have to pass in an indirection instead) * Does not work with unloadObj (see comments below) Performance improvements possible: * ~~This patch introduces a lot of new symbols; ensure we are not unduly polluting the symbol tables. (In particular, I think _static_closure symbols can be made hidden).~~ ~~I've eliminated all of these except for the init symbols, which cross the stub object and assembly file boundary, and so would need to be made invisible by the linker.~~ I needed to make local info tables public. * Don't pay for a double indirection when -fPIC is turned on. Probably the easiest way to do this is to *not* bake in the indirections into compiled code when it is -fPIC'd, and instead scribble over the GOT. However, I don't know how to go backwards from a symbol to a GOT entry, so we might need some heinous assembly hacks to get this working. * The old HEAP_ALLOCED is supposed to be pessimal on very large heaps. Do some performance tests under those workloads. * Make sure the extra indirection is not causing any C-- optimizations to stop firing (it might be, because I put it in as a literal CmmLoad) * Once an static thunk is updated, we can tag the indirection to let other code segments to know about the good news. One way to do this is have the update frame for a static indirection should have a reference to the *indirection*, not the closure itself. However, this scheme will not affect other static closures which have references to the thunk. * Closure tables should have their indirections short-circuited by the initialization code. But maybe it is not worth the cost of telling the RTS about the closure tables (also, they would need to be made writeable). * We are paying an indirection when a GC occurs when the closure is not in R1. According to the wiki page, technically this is not needed, but I don't know how to eliminate references to the closure itself from stg_gc_fun. * ~~Save tags inside the indirection tables, so that we don't spend instructions retagging after the following the indirection.~~ Done. * ~~Improve static indirection and stable pointer registration, avoiding binary bloat from `__attribute(constructor)__` stubs.~~ After discussing this with some folks, it seems that there isn't really a portable way to do this when we are using the system dynamic linker to load libraries at startup. The problem is that we need to somehow get a list of all the GHC-compiled libraries which got loaded, and really the easiest way to get that is to just build it ourselves. * ~~Need to implement a new megablock tracking structure so we can free/check for lost blocks~~. Now that efficient lookup is not necessary, perhaps we can write-optimize the megablock tracking structures. Speculative improvements: * Now that static lives in a block, can we GC them like we GC normal data? This would be beneficial for static thunks, which now can have their indirections completely removed; reverting CAFs may be somewhat tricky, however. * Now that HEAP_ALLOCED is greatly simplified, can we further simply some aspects of the GC? At the very least, we ought to be able to make megablock allocation cheaper, by figuring out how to remove the spinlocks, etc. * Another possibility is to adopt a hybrid approach, where we manually lay out closures when compiling statically, and indirect when compiling dynamically. In some sense, this gets the best of both worlds, since we expect to not pay any extra cost for indirection due to PIC. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 21 22:31:47 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Nov 2015 22:31:47 -0000 Subject: [GHC] #8079: Redo T7919 and TH_spliceE5_prof with a cabal file In-Reply-To: <045.eacbd9ac8eee99c82a0cfa64dcfca8f0@haskell.org> References: <045.eacbd9ac8eee99c82a0cfa64dcfca8f0@haskell.org> Message-ID: <060.b475aa1f484e94bac7456fcaed0743ac@haskell.org> #8079: Redo T7919 and TH_spliceE5_prof with a cabal file -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: closed Priority: normal | Milestone: Component: Test Suite | Version: 7.7 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => fixed Comment: This looks fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 21 22:39:02 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Nov 2015 22:39:02 -0000 Subject: [GHC] #9052: Support a "stable heap" which doesn't get garbage collected In-Reply-To: <045.cef633f00b20a59333331a11354e10ec@haskell.org> References: <045.cef633f00b20a59333331a11354e10ec@haskell.org> Message-ID: <060.2507e2821c80671f84f2d65cf1563a12@haskell.org> #9052: Support a "stable heap" which doesn't get garbage collected -------------------------------------+------------------------------------- Reporter: ezyang | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | 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:D1264 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * differential: => Phab:D1264 Comment: We wrote a paper about this! http://ezyang.com/compact.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 21 22:44:09 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Nov 2015 22:44:09 -0000 Subject: [GHC] #9651: Increasing verbosity doesn't give useful information for why we couldn't load package In-Reply-To: <045.68c944ad4897c3941e1006351a1a6eae@haskell.org> References: <045.68c944ad4897c3941e1006351a1a6eae@haskell.org> Message-ID: <060.1e71e38810d604641fee755da84db359@haskell.org> #9651: Increasing verbosity doesn't give useful information for why we couldn't load package -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: closed Priority: normal | Milestone: 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => fixed Comment: I think I fixed this in {{{ commit 39b71e81ec1044518f065d0055676d713521e483 Author: Edward Z. Yang Date: Tue Oct 27 14:47:33 2015 -0700 Reimplement shadowing on a per database basis. Summary: This commit reimplements shadowing on package databases by doing the shadowing calculation on a per-database basis: specifically, if a later package database shadows a package from the earlier databases, we first remove that package (and its transitive dependencies) before merging the databases together. This should also fix bootstrapping GHC HEAD with HEAD. Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: ggreif, bgamari, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1385 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 21 22:50:46 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Nov 2015 22:50:46 -0000 Subject: [GHC] #10462: GHCi doesn't work Any and missing RealWorld foreign prim imports In-Reply-To: <045.272515eb6529b0f69e6fb29bb854188b@haskell.org> References: <045.272515eb6529b0f69e6fb29bb854188b@haskell.org> Message-ID: <060.2a64e7c890110dc1cd23454b883b86a9@haskell.org> #10462: GHCi doesn't work Any and missing RealWorld foreign prim imports -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: closed Priority: low | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 (CodeGen) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: prog014 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D1458 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: patch => closed * resolution: => fixed Comment: Marking this as fixed, I guess... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 21 22:51:48 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Nov 2015 22:51:48 -0000 Subject: [GHC] #10666: Distinguish between semantic module / identity module in TcGblEnv, ModIface and ModGuts In-Reply-To: <045.a63a148a701a6aba51ee3e839e6cd62c@haskell.org> References: <045.a63a148a701a6aba51ee3e839e6cd62c@haskell.org> Message-ID: <060.c2732e1995fb9127a352894e8399f4c4@haskell.org> #10666: Distinguish between semantic module / identity module in TcGblEnv, ModIface and ModGuts -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: closed Priority: normal | Milestone: Component: Package system | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => invalid Comment: There's some examples on the wiki page: wiki:Backpack But I've figured out how to do this non-invasively, so this will just be part of the Backpack omnibus patch, when it lands. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 21 22:54:25 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Nov 2015 22:54:25 -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.07c268263c3ab6fb72bb700ecd7d1039@haskell.org> #10824: Strict let-bindings are processed backwards -------------------------------------+------------------------------------- Reporter: ezyang | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 21 22:55:36 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Nov 2015 22:55:36 -0000 Subject: [GHC] #10970: Built in MIN_VERSION macro support In-Reply-To: <045.d023da2e9c148d41ec284eb11be9b9b1@haskell.org> References: <045.d023da2e9c148d41ec284eb11be9b9b1@haskell.org> Message-ID: <060.08081217928111fd2ee4d4dfec932cb3@haskell.org> #10970: Built in MIN_VERSION macro support -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 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 Rev(s): Phab:D1349 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 22 08:14:13 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Nov 2015 08:14:13 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.fcdd406669a17ce3eac704a7a5fa99a2@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: #10424 | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, | Phab:D1268, Phab:D1360, Phab:D1373, | Phab:D1396, Phab:D1457, Phab:D1468, Wiki Page: | Phab:D1487, Phab:D1504, Phab:D1508 -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"a703fbce20969e6f02e74fee76c0a9e22b513426/ghc" a703fbce/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a703fbce20969e6f02e74fee76c0a9e22b513426" Remove accidentally added T10359 blob This sneaked in via 2325bd4e0fad0e5872556c5a78d1a6a1873e7201 / D1468 / #4012 This is frustrating... we've added a useless 2.4MiB binary blob to our Git history which wastes *everyones* bandwidth for eternity (unless we truncate or rewrite history). We should add lint-checks and/or a pre-receive commit hook test to prevent this in future. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 22 08:41:51 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Nov 2015 08:41:51 -0000 Subject: [GHC] #11109: build broken in libffi/ when `install-sh` is used In-Reply-To: <042.c5cf0db9a7836b481c2ae3c05299838d@haskell.org> References: <042.c5cf0db9a7836b481c2ae3c05299838d@haskell.org> Message-ID: <057.1c2af843c42969099ab5fd20be5fbb71@haskell.org> #11109: build broken in libffi/ when `install-sh` is used -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 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 Rev(s): Phab:D1494 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"4976ab2bd333e28a1d4cfe924d4d8ebb49489366/ghc" 4976ab2b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4976ab2bd333e28a1d4cfe924d4d8ebb49489366" Follow-up fix to 3e2a4eefbed7002437c3f (re #11109) Using `:` as sed-`s`-expr separator is not a good idea on windows, as this can result in an expression like 's:@INSTALL@:$(subst ../install-sh,E:/msys64/home/foo/ghc/install- sh, at INSTALL@):g' (note the `E:/` drive component) Using `|` instead of `:` has less risk of collision with the substitution expression }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 22 10:16:38 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Nov 2015 10:16:38 -0000 Subject: [GHC] #11072: Runtime linker doesn't search for DLLs referenced in import libraries on Windows In-Reply-To: <050.675e99e0c3128be1426b83f1c6310ea3@haskell.org> References: <050.675e99e0c3128be1426b83f1c6310ea3@haskell.org> Message-ID: <065.51de1fcd464d24537ad0ce426b32f17a@haskell.org> #11072: Runtime linker doesn't search for DLLs referenced in import libraries on Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2-rc2 (Linking) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Matt): Here is new patch against HEAD. I expanded search on all `.idata` sections in first object file that comes after archive members and this now seems to work also with import libraries produced by MSVC alongside with those produced by GCC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 22 10:17:14 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Nov 2015 10:17:14 -0000 Subject: [GHC] #11072: Runtime linker doesn't search for DLLs referenced in import libraries on Windows In-Reply-To: <050.675e99e0c3128be1426b83f1c6310ea3@haskell.org> References: <050.675e99e0c3128be1426b83f1c6310ea3@haskell.org> Message-ID: <065.bdaeebb62919f8092094273a8151bfff@haskell.org> #11072: Runtime linker doesn't search for DLLs referenced in import libraries on Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2-rc2 (Linking) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Matt): * Attachment "0001-Resolving-DLL-name-from-import-library-in-GHCi.patch" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 22 11:12:31 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Nov 2015 11:12:31 -0000 Subject: [GHC] #11112: Error message for accidentally using -> instead of => In-Reply-To: <048.74997cdddf4fddb6f6be3b86d81e7d7a@haskell.org> References: <048.74997cdddf4fddb6f6be3b86d81e7d7a@haskell.org> Message-ID: <063.7a08dc2fe6d7f40d2bbfe7f6f014baac@haskell.org> #11112: Error message for accidentally using -> instead of => -------------------------------------+------------------------------------- Reporter: JulesBean | 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: | typecheck/should_fail/tcfail057 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * testcase: => typecheck/should_fail/tcfail057 Comment: In HEAD, the `GHC.Prim.` bit is gone: {{{ Expected a type, but ?Ord s? has kind ?Constraint? In the type signature for ?Test.sort?: Test.sort :: Ord s -> [s] -> [s] }}} @JulesBean: what do you think about this error message? The last real change to these error messages was made in commit 8bc6c4a613b5d16118469248cfb8025a5175a174: {{{ Author: Simon Peyton Jones Date: Fri Oct 19 02:20:12 2012 +0100 Improvements to kind error messages, mainly Also some expected/actual messages are now the right way round }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 22 11:38:31 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Nov 2015 11:38:31 -0000 Subject: [GHC] #5344: CSE should look through coercions In-Reply-To: <046.337028ce6bbff67a50874240336d3596@haskell.org> References: <046.337028ce6bbff67a50874240336d3596@haskell.org> Message-ID: <061.41a74ede4de1a3a03765f7fe558088a9@haskell.org> #5344: CSE should look through coercions -------------------------------------+------------------------------------- Reporter: reinerp | Owner: simonpj Type: feature request | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: 7.0.3 Resolution: | Keywords: cse Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by slyfox): * cc: slyfox (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 22 12:20:00 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Nov 2015 12:20:00 -0000 Subject: [GHC] #2940: Do CSE after CorePrep In-Reply-To: <046.ba154de3cf0c400fb0723e1948282304@haskell.org> References: <046.ba154de3cf0c400fb0723e1948282304@haskell.org> Message-ID: <061.47e058cf648c72c58c7948d9a5fcd193@haskell.org> #2940: Do CSE after CorePrep -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: lowest | Milestone: 8.0.1 Component: Compiler | Version: 6.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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by slyfox): * cc: slyfox (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 22 13:55:10 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Nov 2015 13:55:10 -0000 Subject: [GHC] #2940: Do CSE after CorePrep In-Reply-To: <046.ba154de3cf0c400fb0723e1948282304@haskell.org> References: <046.ba154de3cf0c400fb0723e1948282304@haskell.org> Message-ID: <061.9d3bb97d3f7d46c8f69170ebfea52f26@haskell.org> #2940: Do CSE after CorePrep -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: lowest | Milestone: 8.0.1 Component: Compiler | Version: 6.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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * cc: osa1 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 22 17:29:38 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Nov 2015 17:29:38 -0000 Subject: [GHC] #11122: Ambiguous inferred type causes a panic Message-ID: <049.1088c8ba6b56b1d64805be5246c7971a@haskell.org> #11122: Ambiguous inferred type causes a panic -------------------------------------+------------------------------------- Reporter: tuplanolla | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Type checker) | Keywords: | Operating System: Linux Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following program. {{{#!hs {-# LANGUAGE PartialTypeSignatures #-} module Main where import Text.Parsec import Text.Parsec.String parser :: Parser _ parser = read <$> many digit data Wrapper = Wrapper Int wrapperParser = Wrapper <$> parser }}} I am not sure whether it is valid or not, but it breaks the type checker as follows. {{{#!hs Program.hs:9:1: No instance for (Read w_) When checking that ?parser? has the specified type parser :: forall w_. Parser w_ Probable cause: the inferred type is ambiguous Program.hs:13:29: Couldn't match type ?w_? with ?Int? ?w_? is untouchable inside the constraints () bound by the inferred type of wrapperParser :: ParsecT String () Data.Functor.Identity.Identity Wrapper at Program.hs:13:1-34ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-linux): No skolem info: w__avnz[sk] }}} Disabling `PartialTypeSignatures` makes no difference. Switching from `parsec-3.1.9` to `megaparsec-4.1.1` and changing `many digit` to `some digitChar` does not have an effect either. Replacing `_` with `Int` seems to be the only obvious way to make the problem disappear. Alas that defeats the point of using partial type signatures or typed holes in the first place. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 22 19:03:14 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Nov 2015 19:03:14 -0000 Subject: [GHC] #11072: Runtime linker doesn't search for DLLs referenced in import libraries on Windows In-Reply-To: <050.675e99e0c3128be1426b83f1c6310ea3@haskell.org> References: <050.675e99e0c3128be1426b83f1c6310ea3@haskell.org> Message-ID: <065.6a830a7aabbde37b5fe8adb7abced255@haskell.org> #11072: Runtime linker doesn't search for DLLs referenced in import libraries on Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2-rc2 (Linking) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Thanks for the patch. We do code reviews on Phabricator (called a Differential), could you create an account there https://phabricator.haskell.org/ and upload the patch? when you do edit this ticket and set the "Differential Rev." field to "Phab:D" and change the ticket status to patch. Also specify a test plan, you will need to provide some test for the functionality being added. See https://ghc.haskell.org/trac/ghc/wiki/Building/RunningTests/Adding -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 22 21:39:25 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Nov 2015 21:39:25 -0000 Subject: [GHC] #11123: Arm: checkProddableBlock: invalid fixup in runtime linke Message-ID: <044.92e8587d5182968d745cf903b273dfec@haskell.org> #11123: Arm: checkProddableBlock: invalid fixup in runtime linke --------------------------------+---------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: arm | Type of failure: Building GHC failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+---------------------------------------- Just started getting this in the last week or two, but only just now got a chance to investigate more fully. Any use of GHCi or TH will result in an error like: {{{ ghc-stage2: internal error: checkProddableBlock: invalid fixup in runtime linker: 0x41380050 (GHC version 7.11.20151122 for arm_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted }}} As a consequence, there are now over 500 failing tests on Arm. I thought this may have been a consequence of all the recent work on `rts/Linker.c` so I checked out git commit 20e30d5f3d932d63933 (the one just before the dreaded commit 04e8366608fee4f which seemed to kick off a bunch of heavy rework in this file) but that revision causes another, even more mysterious linking failure. From what I have seen, this only affects 32 bit Arm. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 22 21:39:41 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Nov 2015 21:39:41 -0000 Subject: [GHC] #11123: Arm: checkProddableBlock: invalid fixup in runtime linker (was: Arm: checkProddableBlock: invalid fixup in runtime linke) In-Reply-To: <044.92e8587d5182968d745cf903b273dfec@haskell.org> References: <044.92e8587d5182968d745cf903b273dfec@haskell.org> Message-ID: <059.946443246599d01f38daad7b8c6de776@haskell.org> #11123: Arm: checkProddableBlock: invalid fixup in runtime linker ----------------------------------------+----------------------------- 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: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+----------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 22 22:18:49 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Nov 2015 22:18:49 -0000 Subject: [GHC] #11124: GHC does not shadow -package-name/-this-package-key Message-ID: <045.512e4506941c11005f6cceacb0d5a42d@haskell.org> #11124: GHC does not shadow -package-name/-this-package-key -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Package | Version: 7.11 system | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Steps to reproduce: 1. Install a package named `a` with these contents: **a.cabal** {{{ name: a version: 0.1.0.0 cabal-version: >=1.10 library exposed-modules: A build-depends: base }}} **A.hs** {{{ module A where data A = A String }}} Note what unit ID/package key/package name the package installs as. On GHC 7.8 it will be something like `a-0.1.0.0`, on GHC 7.10 it will be something like `a_LKCPrTJwOTOLk4OU37YmeN`, on GHC 8.0 it will be something like `a-0.1.0.0-LKCPrTJwOTOLk4OU37Yme`. 2. Install a package named `b` with these contents: **b.cabal** {{{ name: b version: 0.1.0.0 cabal-version: >=1.10 library exposed-modules: B build-depends: base, a }}} **b.hs** {{{ module B where import A b = A "foo" }}} 3. Go back to `a`, and load `A.hs` in GHCi with `ghci A.hs -package-name a-0.1.0.0 -package-db ../db`. Notice that we can `import B` from this GHCi session: {{{ ezyang at sabre:~/Dev/labs/ii/a$ ghci A.hs -package-name a-0.1.0.0 -package- db ../db GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling A ( A.hs, interpreted ) Ok, modules loaded: A. *A> import B *A B> b Loading package a-0.1.0.0 ... linking ... done. Loading package b-0.1.0.0 ... linking ... done. A "asdfsdf" *A B> Leaving GHCi. }}} 3. Edit `A.hs` so that now contains: {{{ module A where data A = A Int }}} 4. Load in GHCi again: {{{ ezyang at sabre:~/Dev/labs/ii/a$ ghci A.hs -package-name a-0.1.0.0 -package- db ../db GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling A ( A.hs, interpreted ) Ok, modules loaded: A. *A> import B *A B> b Loading package a-0.1.0.0 ... linking ... done. Loading package b-0.1.0.0 ... linking ... done. A 3458765062984598387 }}} Disaster! Actually, this bug is relatively harmless: 1. If you try to actually reinstall package a, that's a "dangerous" reinstall and it's known that reinstalls can break things. 2. It's hard to convince Cabal to trigger this, since importing `B` requires `b` in the build-depends, and that would constitute a circular package dependency. (You can't separate it out because of (1)) 3. If you don't specify `-package-name` (or similar) the local `A` and the remote `A` will have different identities, no problem. 4. When you do specify `-package-name`, you can't build a main executable (so the only way to run is by loading into GHCi, as shown above.) 5. Sometimes, GHCi will notice that something is amiss if it tries to load the object file for both the remote A and the local A. But the fix seems simple: if a user specifies `-package-name`, it should be AS IF they also specified `-ignore-package`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 22 23:10:32 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Nov 2015 23:10:32 -0000 Subject: [GHC] #11019: ApiAnnotations: Make all RdrName occurences Located In-Reply-To: <044.6f9b0661f882f5c32756a32bbf81653d@haskell.org> References: <044.6f9b0661f882f5c32756a32bbf81653d@haskell.org> Message-ID: <059.42557279b0c58b19d3fb821bc0fb56ed@haskell.org> #11019: ApiAnnotations: Make all RdrName occurences Located -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:1512 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"3df9563e590bbfbfe1bc9171a0e8fc93ceef690d/ghc" 3df9563e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3df9563e590bbfbfe1bc9171a0e8fc93ceef690d" ApiAnnotations: Make all RdrName occurences Located At the moment the API Annotations can only be used on the ParsedSource, as there are changes made to the RenamedSource that prevent it from being used to round trip source code. It is possible to build a map from every Located Name in the RenamedSource from its location to the Name, which can then be used when resolved names are required when changing the ParsedSource. However, there are instances where the identifier is not located, specifically (GHC.VarPat name) (GHC.HsVar name) (GHC.UserTyVar name) (GHC.HsTyVar name) Replace each of the name types above with (Located name) Updates the haddock submodule. Test Plan: ./validate Reviewers: austin, goldfire, bgamari Reviewed By: bgamari Subscribers: goldfire, thomie, mpickering Differential Revision: https://phabricator.haskell.org/D1512 GHC Trac Issues: #11019 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 22 23:10:32 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Nov 2015 23:10:32 -0000 Subject: [GHC] #11060: Failing tests on 32 bit platforms In-Reply-To: <044.8903e45b189743246ba884746b94acaa@haskell.org> References: <044.8903e45b189743246ba884746b94acaa@haskell.org> Message-ID: <059.148242f609106e89ae5bc396d62be9be@haskell.org> #11060: Failing tests on 32 bit platforms -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Test Suite | 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): Phab:D1510 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"64737f2dfa0ff9ca4f4c056143b3591cedd32652/ghc" 64737f2d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="64737f2dfa0ff9ca4f4c056143b3591cedd32652" New expected test output for 32 bit platforms Test Plan: Test on Arm and PowerPc. Reviewers: bgamari, thomie, austin Differential Revision: https://phabricator.haskell.org/D1510 GHC Trac Issues: #11060 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 22 23:10:32 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Nov 2015 23:10: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.b8a5c9fd094f7d9aca8cacf93d170126@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: #10424 | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, | Phab:D1268, Phab:D1360, Phab:D1373, | Phab:D1396, Phab:D1457, Phab:D1468, Wiki Page: | Phab:D1487, Phab:D1504, Phab:D1508 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"6393dd8e437f68856b2e7889e576ed1bfb0a9678/ghc" 6393dd8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6393dd8e437f68856b2e7889e576ed1bfb0a9678" Make abstractVars deterministic in SetLevel This fixes a non-determinism bug where depending on the order of uniques allocated, the type variables would be in a different order when abstracted for the purpose of lifting out an expression. Test Plan: I've added a new testcase that reproduces the problem ./validate Reviewers: simonmar, austin, bgamari, simonpj Reviewed By: simonpj Subscribers: nomeata, thomie Differential Revision: https://phabricator.haskell.org/D1504 GHC Trac Issues: #4012 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 22 23:35:06 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Nov 2015 23:35:06 -0000 Subject: [GHC] #11019: ApiAnnotations: Make all RdrName occurences Located In-Reply-To: <044.6f9b0661f882f5c32756a32bbf81653d@haskell.org> References: <044.6f9b0661f882f5c32756a32bbf81653d@haskell.org> Message-ID: <059.07bdb8207aacc2bc94ccca454e860e7e@haskell.org> #11019: ApiAnnotations: Make all RdrName occurences Located -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:1512 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 22 23:35:29 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Nov 2015 23:35:29 -0000 Subject: [GHC] #11060: Failing tests on 32 bit platforms In-Reply-To: <044.8903e45b189743246ba884746b94acaa@haskell.org> References: <044.8903e45b189743246ba884746b94acaa@haskell.org> Message-ID: <059.0aa74b2ce168333c5d9a97aa8dd35049@haskell.org> #11060: Failing tests on 32 bit platforms -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Test Suite | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1510 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 22 23:36:06 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Nov 2015 23:36:06 -0000 Subject: [GHC] #7253: Top-level bindings in ghci In-Reply-To: <048.88d72a7323b37dac89e81e376b48b907@haskell.org> References: <048.88d72a7323b37dac89e81e376b48b907@haskell.org> Message-ID: <063.b43660f960555947d00b66c8c6d615b4@haskell.org> #7253: Top-level bindings in ghci -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: roshats Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.6.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1299 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 23 08:16:27 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Nov 2015 08:16:27 -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.707d1d2cf341ef42318c3e34a6bd12fd@haskell.org> #10320: -ddump-to-file should create empty dump files when there was nothing to dump -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: tvv 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by tvv): * owner: => tvv Comment: I think it's better to keep one but truncate its size. At least it can show that flags were specified correctly and there's nothing to dump. Seems that `-ddump-rule-rewrites` should be handled too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 23 09:11:13 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Nov 2015 09:11:13 -0000 Subject: [GHC] #11125: Typechecker can't infer StM m Bool ~ Bool from StM m a ~ a Message-ID: <045.db6b3b66e24dfa0abdc3126897d12f3a@haskell.org> #11125: Typechecker can't infer StM m Bool ~ Bool from StM m a ~ a -------------------------------------+------------------------------------- Reporter: nikomi | 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 Rev(s): | Wiki Page: -------------------------------------+------------------------------------- We found a problem where TC correctly infers StM m a ~ a but fails to infer StM m Bool ~ Bool in what appears to be the same situation. Here is a small sample showing the problem: {{{#!hs {-# LANGUAGE FlexibleContexts, FlexibleInstances #-} module Problem where import qualified Control.Monad.STM as STM import Control.Monad.STM (STM) import Control.Monad.Trans.Control (MonadBaseControl, liftBaseWith) class MonadSTM m where liftSTM :: STM a -> m a instance MonadSTM STM where liftSTM = id always :: (Monad m, MonadSTM m, MonadBaseControl STM m) => m Bool -> m () always inv = liftBaseWith $ \runInSTM -> STM.always (runInSTM inv) alwaysSucceeds :: (Monad m, MonadSTM m, MonadBaseControl STM m) => m a -> m () alwaysSucceeds inv = liftBaseWith $ \runInSTM -> STM.alwaysSucceeds (runInSTM inv) }}} The compiler error is {{{ Problem.hs:15:54: Couldn't match type ?Control.Monad.Trans.Control.StM m Bool? with ?Bool? Expected type: STM Bool Actual type: STM (Control.Monad.Trans.Control.StM m Bool) Relevant bindings include runInSTM :: Control.Monad.Trans.Control.RunInBase m STM (bound at Problem.hs:15:30) inv :: m Bool (bound at Problem.hs:15:8) always :: m Bool -> m () (bound at Problem.hs:15:1) In the first argument of ?STM.always?, namely ?(runInSTM inv)? In the expression: STM.always (runInSTM inv) }}} Function {{{always}}} can be made to compile by adding {{{StM m Bool ~ Bool}}}: {{{#!hs always :: (Monad m, MonadSTM m, MonadBaseControl STM m, StM m Bool ~ Bool) => m Bool -> m () }}} but then the problem is just shifted to the caller: {{{ Couldn't match type ?(Either [Char] Bool, Int)? with ?Bool? Expected type: Bool Actual type: StM (RSET TestData Int String STM) Bool In the second argument of ?($)?, namely ?always sanityCheck? In a stmt of a 'do' block: atomically $ always sanityCheck In the expression: do { atomically $ always sanityCheck; atomically $ updateTX 1 2; atomically stashSum } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 23 09:21:02 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Nov 2015 09:21:02 -0000 Subject: [GHC] #11125: Typechecker can't infer StM m Bool ~ Bool from StM m a ~ a In-Reply-To: <045.db6b3b66e24dfa0abdc3126897d12f3a@haskell.org> References: <045.db6b3b66e24dfa0abdc3126897d12f3a@haskell.org> Message-ID: <060.96ef9b25d61b15a581b79323893676fe@haskell.org> #11125: Typechecker can't infer StM m Bool ~ Bool from StM m a ~ a -------------------------------------+------------------------------------- Reporter: nikomi | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * component: Compiler => Compiler (Type checker) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 23 09:57:39 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Nov 2015 09:57:39 -0000 Subject: [GHC] #11125: Typechecker can't infer StM m Bool ~ Bool from StM m a ~ a In-Reply-To: <045.db6b3b66e24dfa0abdc3126897d12f3a@haskell.org> References: <045.db6b3b66e24dfa0abdc3126897d12f3a@haskell.org> Message-ID: <060.01c25dafd7b8e2edc42edc7d3e3c2bad@haskell.org> #11125: Typechecker can't infer StM m Bool ~ Bool from StM m a ~ a -------------------------------------+------------------------------------- Reporter: nikomi | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Are you sure that it indeed solves `StM m a ~ a`, because how could it? From reading the type signatures, I get the impression that `STM.alwaysSucceeds`?s is rather instantiated with `StM m a`. Note that {{{ alwaysSucceeds :: forall m a. (Monad m, MonadSTM m, MonadBaseControl STM m) => m a -> m () alwaysSucceeds inv = liftBaseWith $ \runInSTM -> STM.alwaysSucceeds (runInSTM inv :: STM (StM m a)) }}} compiles, but {{{ alwaysSucceeds :: forall m a. (Monad m, MonadSTM m, MonadBaseControl STM m) => m a -> m () alwaysSucceeds inv = liftBaseWith $ \runInSTM -> STM.alwaysSucceeds (runInSTM inv :: STM a) }}} does not (`Couldn't match type ?a? with ?StM m a?`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 23 10:09:19 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Nov 2015 10:09:19 -0000 Subject: [GHC] #11125: Typechecker can't infer StM m Bool ~ Bool from StM m a ~ a In-Reply-To: <045.db6b3b66e24dfa0abdc3126897d12f3a@haskell.org> References: <045.db6b3b66e24dfa0abdc3126897d12f3a@haskell.org> Message-ID: <060.9759d4218213a54b13c889a3111c62c5@haskell.org> #11125: Typechecker can't infer StM m Bool ~ Bool from StM m a ~ a -------------------------------------+------------------------------------- Reporter: nikomi | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): Btw, it may be useful to know the definition of the associated type `StM`: {{{#!hs class MonadBase b m => MonadBaseControl b m | m -> b where type StM m a :: * liftBaseWith :: (RunInBase m b -> b a) -> m a restoreM :: StM m a -> m a instance MonadBaseControl IO IO where type StM IO a = a liftBaseWith f = f id restoreM = return instance MonadBaseControl STM STM where type StM STM a = a liftBaseWith f = f id restoreM = return }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 23 10:17:53 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Nov 2015 10:17:53 -0000 Subject: [GHC] #11028: Refactor ConDecl In-Reply-To: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> References: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> Message-ID: <061.c897267f6f8e1f6693426e7ff004dd2a@haskell.org> #11028: Refactor ConDecl -------------------------------------+------------------------------------- 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jstolarek): Replying to simonpj: > The `con_old_rec` is a warning thing for GADTs (see current source code) Incidentally, I removed that field not so long ago - see ea8c116ac9eb916fdb6360a01c285bc8698dfaf9. {{{#!hs data ConDecl name | ConDeclGADT { con_names :: [Located name] , con_type :: LHsSigType name -- The type after the ?::? , con_doc :: Maybe LHsDocString , con_old_rec :: Bool } }}} What is `LHsSigType`? A synonym for `LHsType`? If so then, perhaps it would be a good idea to have separate fields for storing foralls and the context? I'm looking at my work on #10828 (Phab:D1465) and I think the implementation in `DsMeta` would get a bit more difficult if foralls and context are folded into one field with the whole type. Of course we can create functions that extract these information from `ConDecl` but wouldn't separate fields be easier? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 23 10:19:24 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Nov 2015 10:19:24 -0000 Subject: [GHC] #11028: Refactor ConDecl In-Reply-To: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> References: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> Message-ID: <061.9a68a0de5d5256008b6b5300315f4509@haskell.org> #11028: Refactor ConDecl -------------------------------------+------------------------------------- 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jstolarek): * cc: jstolarek (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 23 10:23:54 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Nov 2015 10:23:54 -0000 Subject: [GHC] #11125: Typechecker can't infer StM m Bool ~ Bool from StM m a ~ a In-Reply-To: <045.db6b3b66e24dfa0abdc3126897d12f3a@haskell.org> References: <045.db6b3b66e24dfa0abdc3126897d12f3a@haskell.org> Message-ID: <060.c04803ae6d6f4f39ae5993ccbd11e1ce@haskell.org> #11125: Typechecker can't infer StM m Bool ~ Bool from StM m a ~ a -------------------------------------+------------------------------------- Reporter: nikomi | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nikomi): The definitions of the original STM functions could also be useful: {{{#!hs always :: STM Bool -> STM () alwaysSucceeds :: STM a -> STM () }}} In my sample code I can see no relevant difference between {{{always}}} and {{{alwaysSucceeds}}} other than the argument type: m Bool vs. m a - conforming the argument types of the functions I want to lift: STM Bool vs. STM a. Yet the function with the generic type {{{a}}} compiles and the one with the specific type {{{Bool}}} does not - I have another sample where a usage of {{{m ()}}} fails to compile with exactly the same error right next to {{{m a}}}s that compile file (in those cases the base monad is IO, not STM) So from my limited point of view (with no insight into the TC) the difference is generic vs. specific. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 23 10:29:44 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Nov 2015 10:29:44 -0000 Subject: [GHC] #11028: Refactor ConDecl In-Reply-To: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> References: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> Message-ID: <061.009de5880128162cc9b62025e0bf6a6d@haskell.org> #11028: Refactor ConDecl -------------------------------------+------------------------------------- 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Jan: see branch `wip/spj-wildcard-refactor`, and https://phabricator.haskell.org/D1428, which will land shortly -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 23 10:35:57 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Nov 2015 10:35:57 -0000 Subject: [GHC] #11125: Typechecker can't infer StM m Bool ~ Bool from StM m a ~ a In-Reply-To: <045.db6b3b66e24dfa0abdc3126897d12f3a@haskell.org> References: <045.db6b3b66e24dfa0abdc3126897d12f3a@haskell.org> Message-ID: <060.7d1f367e9b99690f3d70d120e125f5f0@haskell.org> #11125: Typechecker can't infer StM m Bool ~ Bool from StM m a ~ a -------------------------------------+------------------------------------- Reporter: nikomi | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => closed * resolution: => invalid Comment: More relevant types: {{{ liftBaseWith :: (RunInBase m b -> b a) -> m a type RunInBase m b = forall a. m a -> b (StM m a) }}} so the `runInST` function in your code changes the return type from `a` to `StM m a`. Note the docs: > The difference with liftBase is that before lifting the base computation liftBaseWith captures the state of m. It then provides the base computation with a RunInBase function that allows running m computations in the base monad on the captured state. I?m confident that GHC is doing the right thing here, and it?s just `monad-control`?s API that is confusing here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 23 10:37:51 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Nov 2015 10:37:51 -0000 Subject: [GHC] #11119: WERROR in build.mk doesn't work In-Reply-To: <047.e00d8c0ace59eb944ad6685d6676a367@haskell.org> References: <047.e00d8c0ace59eb944ad6685d6676a367@haskell.org> Message-ID: <062.ae7f91b2bbb7b12c6f37d2a7781119ec@haskell.org> #11119: WERROR in build.mk doesn't work -------------------------------------+------------------------------------- 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Fair point; I should have left a note about this. I've added one in 02c689cd1ce2a55adf6318eb9bd69f227f1abda2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 23 10:37:57 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Nov 2015 10:37:57 -0000 Subject: [GHC] #11119: WERROR in build.mk doesn't work In-Reply-To: <047.e00d8c0ace59eb944ad6685d6676a367@haskell.org> References: <047.e00d8c0ace59eb944ad6685d6676a367@haskell.org> Message-ID: <062.569f681765609880ce4e21ce876a39db@haskell.org> #11119: WERROR in build.mk doesn't work -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 23 10:49:40 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Nov 2015 10:49:40 -0000 Subject: [GHC] #11125: Typechecker can't infer StM m Bool ~ Bool from StM m a ~ a In-Reply-To: <045.db6b3b66e24dfa0abdc3126897d12f3a@haskell.org> References: <045.db6b3b66e24dfa0abdc3126897d12f3a@haskell.org> Message-ID: <060.ca48fdf04416c3a17ceb9f3366e37ecf@haskell.org> #11125: Typechecker can't infer StM m Bool ~ Bool from StM m a ~ a -------------------------------------+------------------------------------- Reporter: nikomi | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nikomi): Regardless of the API being confusing or not - using exactly the same thing with {{{a}}} vs. any specific type and one works but the other doesn't makes me rather confident something is fishy here :-( Any suggestions how to circumvent this non-bug? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 23 10:50:03 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Nov 2015 10:50:03 -0000 Subject: [GHC] #11122: Ambiguous inferred type causes a panic In-Reply-To: <049.1088c8ba6b56b1d64805be5246c7971a@haskell.org> References: <049.1088c8ba6b56b1d64805be5246c7971a@haskell.org> Message-ID: <064.e89950e0c4e7a814d94e1963f0148ae5@haskell.org> #11122: Ambiguous inferred type causes a panic -------------------------------------+------------------------------------- Reporter: tuplanolla | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by tuplanolla: Old description: > Consider the following program. > > {{{#!hs > {-# LANGUAGE PartialTypeSignatures #-} > > module Main where > > import Text.Parsec > import Text.Parsec.String > > parser :: Parser _ > parser = read <$> many digit > > data Wrapper = Wrapper Int > > wrapperParser = Wrapper <$> parser > }}} > > I am not sure whether it is valid or not, but it breaks the type checker > as follows. > > {{{#!hs > Program.hs:9:1: > No instance for (Read w_) > When checking that ?parser? has the specified type > parser :: forall w_. Parser w_ > Probable cause: the inferred type is ambiguous > > Program.hs:13:29: > Couldn't match type ?w_? with ?Int? > ?w_? is untouchable > inside the constraints () > bound by the inferred type of > wrapperParser :: ParsecT > String () > Data.Functor.Identity.Identity Wrapper > at Program.hs:13:1-34ghc: panic! (the 'impossible' happened) > (GHC version 7.10.2 for x86_64-unknown-linux): > No skolem info: w__avnz[sk] > }}} > > Disabling `PartialTypeSignatures` makes no difference. > Switching from `parsec-3.1.9` to `megaparsec-4.1.1` and changing `many > digit` to `some digitChar` does not have an effect either. > Replacing `_` with `Int` seems to be the only obvious way to make the > problem disappear. > Alas that defeats the point of using partial type signatures or typed > holes in the first place. New description: Consider the following program. {{{#!hs {-# LANGUAGE NoMonomorphismRestriction, PartialTypeSignatures #-} module Main where import Text.Parsec import Text.Parsec.String parser :: Parser _ parser = read <$> many digit data Wrapper = Wrapper Int deriving Show wrapperParser = Wrapper <$> parser main :: IO () main = parseTest wrapperParser "0" }}} I am not sure whether it is valid or not, but it breaks the type checker as follows. {{{#!hs Main.hs:9:1: No instance for (Read w_) When checking that ?parser? has the specified type parser :: forall w_. Parser w_ Probable cause: the inferred type is ambiguous Main.hs:13:29: Couldn't match type ?w_? with ?Int? ?w_? is untouchable inside the constraints () bound by the inferred type of wrapperParser :: ParsecT String () Data.Functor.Identity.Identity Wrapper at Main.hs:13:1-34ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-linux): No skolem info: w__a2BN[sk] }}} Disabling `PartialTypeSignatures` makes no difference. Switching from `parsec` to `megaparsec` and changing `many digit` to `some digitChar` does not have an effect either. Removing `NoMonomorphismRestriction` makes the problem disappear, as does changing `_` to `Int`. The libraries used were * `array-0.5.1.0`, * `base-4.8.1.0`, * `binary-0.7.5.0`, * `bytestring-0.10.6.0`, * `containers-0.5.6.2`, * `deepseq-1.4.1.1`, * `ghc-prim-0.4.0.0`, * `integer-gmp-1.0.0.0`, * `megaparsec-4.1.1`, * `mtl-2.2.1`, * `parsec-3.1.9`, * `text-1.2.1.3` and * `transformers-0.4.2.0`. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 23 10:53:01 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Nov 2015 10:53:01 -0000 Subject: [GHC] #11122: Ambiguous inferred type causes a panic In-Reply-To: <049.1088c8ba6b56b1d64805be5246c7971a@haskell.org> References: <049.1088c8ba6b56b1d64805be5246c7971a@haskell.org> Message-ID: <064.b82468cc171e8b46d067deb74c08b761@haskell.org> #11122: Ambiguous inferred type causes a panic -------------------------------------+------------------------------------- Reporter: tuplanolla | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: duplicate | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10615 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => closed * resolution: => duplicate * related: => #10615 Comment: This looks like a duplicate of #10615. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 23 10:59:35 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Nov 2015 10:59:35 -0000 Subject: [GHC] #11126: Entered absent arg in a Repa program Message-ID: <049.08d17e678ab01e39cf7b040134e05fa3@haskell.org> #11126: Entered absent arg in a Repa program -------------------------------------+------------------------------------- Reporter: tuplanolla | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following program. {{{#!hs module Main where import Data.Array.Repa data Stuff = !(Array U DIM1 Double) `With` !Double deriving Show through :: Maybe Double -> Stuff -> Stuff m `through` (a `With` _) = let b = a +^ (negate `smap` sumS (extend (Z :. All :. (1 :: Int)) a)) c = maybe b (const (negate `smap` a)) m in computeUnboxedS c `With` sumAllS b main :: IO () main = print $ Just 1 `through` (fromListUnboxed (Z :. 1) [1] `With` 1) }}} It should produce the following result once run. {{{#!hs AUnboxed (Z :. 1) (fromList [-1.0]) `With` 0.0 }}} However, when built using `repa-3.4.0.1` and compiled with the options `-O3 -Wall -funfolding-keeness-factor1000 -funfolding-use-threshold1000`, it crashes as follows. {{{#!hs Main: Oops! Entered absent arg arr2 Array D DIM1 Double }}} Adding `-fno-strictness` to the compiler options or removing strictness annotations from the code makes the problem disappear, so this looks like a strictness analyzer problem. The libraries used were * `QuickCheck-2.8.1`, * `array-0.5.1.0`, * `base-4.8.1.0`, * `bytestring-0.10.6.0`, * `containers-0.5.6.2`, * `deepseq-1.4.1.1`, * `ghc-prim-0.4.0.0`, * `integer-gmp-1.0.0.0`, * `pretty-1.1.2.0`, * `primitive-0.6`, * `random-1.1`, * `repa-3.4.0.1`, * `template-haskell-2.10.0.0`, * `tf-random-0.5`, * `time-1.5.0.1`, * `transformers-0.4.2.0` and * `vector-0.10.12.3`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 23 11:12:35 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Nov 2015 11:12:35 -0000 Subject: [GHC] #7298: GHCi is setting stdin/stdout to NoBuffering in runghc when DYNAMIC_GHC_PROGRAMS=YES In-Reply-To: <044.34213a5738911dce009c62eab496ee22@haskell.org> References: <044.34213a5738911dce009c62eab496ee22@haskell.org> Message-ID: <059.4a13611cb0ea1f09c1a2618eaf0cf445@haskell.org> #7298: GHCi is setting stdin/stdout to NoBuffering in runghc when DYNAMIC_GHC_PROGRAMS=YES -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: GHCi | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghc-e/should_run/T2228 Blocked By: | Blocking: Related Tickets: #2228 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.2.1 Comment: While it's a bit late to handle this for 8.0 let's at least try for 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 23 12:11:50 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Nov 2015 12:11:50 -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.ebea14eccb97ba610e3ebc3e7991933b@haskell.org> #10320: -ddump-to-file should create empty dump files when there was nothing to dump -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: tvv Type: bug | Status: patch 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 Rev(s): Phab:D1514 Wiki Page: | -------------------------------------+------------------------------------- Changes (by tvv): * status: new => patch * differential: => Phab:D1514 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 23 12:34:46 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Nov 2015 12:34:46 -0000 Subject: [GHC] #11125: Typechecker can't infer StM m Bool ~ Bool from StM m a ~ a In-Reply-To: <045.db6b3b66e24dfa0abdc3126897d12f3a@haskell.org> References: <045.db6b3b66e24dfa0abdc3126897d12f3a@haskell.org> Message-ID: <060.226f4dd315c22237ef7f38777b71b0a8@haskell.org> #11125: Typechecker can't infer StM m Bool ~ Bool from StM m a ~ a -------------------------------------+------------------------------------- Reporter: nikomi | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): > Regardless of the API being confusing or not - using exactly the same thing with a vs. any specific type and one works but the other doesn't makes me rather confident something is fishy here :-( `a` can be instantiated to `StM m a` (note that these are different `a`s), but `Bool` cannot be instantiated, and is different from `StM m Bool`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 23 12:48:02 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Nov 2015 12:48:02 -0000 Subject: [GHC] #11127: Update cabal submodule to 1.22 branch HEAD Message-ID: <045.b86ccf3972e67654868d36d88f8530d9@haskell.org> #11127: Update cabal submodule to 1.22 branch HEAD -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: libraries | Version: (other) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- For 7.10.3, this will fold in a critical fix for Mac (the Cabal side of #10568), along with a fix to prevent c-sources from being recompiled unnecessarily (a big deal when working with large C/C++ bindings). The commit is 5acbc41 https://github.com/haskell/cabal/tree/1.22 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 23 12:48:31 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Nov 2015 12:48:31 -0000 Subject: [GHC] #11127: Update cabal submodule to 1.22 branch HEAD In-Reply-To: <045.b86ccf3972e67654868d36d88f8530d9@haskell.org> References: <045.b86ccf3972e67654868d36d88f8530d9@haskell.org> Message-ID: <060.88252a1e091c90666905d166bce44520@haskell.org> #11127: Update cabal submodule to 1.22 branch HEAD -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: libraries | Version: (other) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by lukexi: Old description: > For 7.10.3, this will fold in a critical fix for Mac (the Cabal side of > #10568), along with a fix to prevent c-sources from being recompiled > unnecessarily (a big deal when working with large C/C++ bindings). > > The commit is 5acbc41 > > https://github.com/haskell/cabal/tree/1.22 New description: For 7.10.3, this will fold in a critical fix for Mac (the Cabal side of #10568), along with a fix to prevent c-sources from being recompiled unnecessarily (a big deal when working with large C/C++ bindings). The commit is `5acbc41` https://github.com/haskell/cabal/tree/1.22 -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 23 13:10:11 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Nov 2015 13:10:11 -0000 Subject: [GHC] #11127: Update cabal submodule to 1.22 branch HEAD In-Reply-To: <045.b86ccf3972e67654868d36d88f8530d9@haskell.org> References: <045.b86ccf3972e67654868d36d88f8530d9@haskell.org> Message-ID: <060.127cfbaf80bcab72ba54d5fe13793739@haskell.org> #11127: Update cabal submodule to 1.22 branch HEAD -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.10.3 Component: libraries | Version: (other) | Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => wontfix Comment: 7.10.3 is a minor release before the quite major 8.0 and consequently we are trying to keep the delta small. This desire, coupled with the fact that Cabal can be easily updated after installation, convinced me that the potential risk that a bump (which involves more than 20k lines of changes) would carry outweighs the relatively minor benefits. Sorry! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 23 13:10:53 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Nov 2015 13:10:53 -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.c2b9a8a2c1d3a3566ee4ca620c981a96@haskell.org> #8736: GHCi doesn't load .dyn_o files appropriately -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: thoughtpolice Type: bug | Status: new Priority: high | Milestone: 8.0.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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): This will be fixed by #11100 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 23 13:11:21 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Nov 2015 13:11:21 -0000 Subject: [GHC] #11100: Remote GHCi In-Reply-To: <047.346d10a0114be8596e5485c83dbed9dd@haskell.org> References: <047.346d10a0114be8596e5485c83dbed9dd@haskell.org> Message-ID: <062.26f39393f222be867bbd81ccb9d3fa1a@haskell.org> #11100: Remote GHCi -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: new 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: #11047, #8736 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * related: #11047 => #11047, #8736 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 23 13:21:37 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Nov 2015 13:21:37 -0000 Subject: [GHC] #11127: Update cabal submodule to 1.22 branch HEAD In-Reply-To: <045.b86ccf3972e67654868d36d88f8530d9@haskell.org> References: <045.b86ccf3972e67654868d36d88f8530d9@haskell.org> Message-ID: <060.122e6c719da7ac7bf2ebaf35d612798a@haskell.org> #11127: Update cabal submodule to 1.22 branch HEAD -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.10.3 Component: libraries | Version: (other) | Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by refold): I'd argue that bumping Cabal from 1.22.4.0 to 1.22.5.0 for a minor GHC release is a sensible thing to do. The diff is much smaller than 20K and contains only bugfixes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 23 13:32:32 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Nov 2015 13:32:32 -0000 Subject: [GHC] #11127: Update cabal submodule to 1.22 branch HEAD In-Reply-To: <045.b86ccf3972e67654868d36d88f8530d9@haskell.org> References: <045.b86ccf3972e67654868d36d88f8530d9@haskell.org> Message-ID: <060.5589e42783c90651e1efd9bc8f396675@haskell.org> #11127: Update cabal submodule to 1.22 branch HEAD -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.10.3 Component: libraries | Version: (other) | Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by refold): Basically, the only changes in Cabal 1.22.5.0 are: * [https://github.com/haskell/cabal/commit/1a64dcb0818ba609c4d6f1b60392802b43ad802b The aforementioned Mac framework fix (a one-liner).] * [https://github.com/haskell/cabal/commit/eb4687233852b5a9b5544b815eed0a44a947032d C sources recompilation fix.] * [https://github.com/haskell/cabal/commit/1c1228a808b55331ac1db6d71fd2f8533f5fc57e Support for Haddock response files.] So I vote for bumping Cabal from 1.22.4.0 to 1.22.5.0 for 7.10.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 23 13:42:22 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Nov 2015 13:42:22 -0000 Subject: [GHC] #10952: Use IPids instead of package keys in HPC tix files In-Reply-To: <046.2961695834220c5d8e713a72077c82af@haskell.org> References: <046.2961695834220c5d8e713a72077c82af@haskell.org> Message-ID: <061.22d0b4af8d27c56c8aa089a13477a28a@haskell.org> #10952: Use IPids instead of package keys in HPC tix files -------------------------------------+------------------------------------- Reporter: mgsloan | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Code Coverage | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Feuerbach): I've just run into this issue. Here's my problem. I want to merge tix files produced by running unit tests (via "stack test") and integration tests (via running actual executables that use the libraries being tested). As it happens, stack (via Cabal) runs tests by using an in-place version of the library, while the executable is using the properly installed version. This prevents me from merging the tix files and causes a lot of headache. If my understanding is correct, IPIDs by themselves won't help me; hpc will also need to learn to merge data from different installations of the same package. I do need this for 7.10 (not necessarily the official release; I can build ghc myself, although a release would be nice). I can also invest a bit of time into this if someone (Ed?) gave me directions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 23 14:08:49 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Nov 2015 14:08:49 -0000 Subject: [GHC] #11128: New `-fwarn-noncanonical-monad-instances` warning Message-ID: <042.e02ab93445edf67c384ef57b5dac6baf@haskell.org> #11128: New `-fwarn-noncanonical-monad-instances` warning -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr 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): | Wiki Page: -------------------------------------+------------------------------------- placeholder -- I needed a ticket number; will flesh out description asap -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 23 14:42:33 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Nov 2015 14:42:33 -0000 Subject: [GHC] #11128: New `-fwarn-noncanonical-monad-instances` warning In-Reply-To: <042.e02ab93445edf67c384ef57b5dac6baf@haskell.org> References: <042.e02ab93445edf67c384ef57b5dac6baf@haskell.org> Message-ID: <057.d52dea2fbd141d7c8c78b009ace1e87a@haskell.org> #11128: New `-fwarn-noncanonical-monad-instances` warning -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: feature request | 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 Rev(s): Phab:D1516 Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * status: new => patch * differential: => Phab:D1516 Old description: > placeholder -- I needed a ticket number; will flesh out description asap New description: (see description in Phab:D1516 for the meantime) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 23 15:12:50 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Nov 2015 15:12:50 -0000 Subject: [GHC] #11128: New `-fwarn-noncanonical-monad-instances` warning In-Reply-To: <042.e02ab93445edf67c384ef57b5dac6baf@haskell.org> References: <042.e02ab93445edf67c384ef57b5dac6baf@haskell.org> Message-ID: <057.21d74c965a4231136d23fb53132d0eef@haskell.org> #11128: New `-fwarn-noncanonical-monad-instances` warning -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: feature request | 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 Rev(s): Phab:D1516 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Do you intentionally disallow `return x = pure x`, which some people might write? (No strong opinion here, having precisely one official way is probably desirable, but let?s at least document that it has been given thought.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 23 16:39:34 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Nov 2015 16:39:34 -0000 Subject: [GHC] #11051: GHCi with +t option set shows type representations In-Reply-To: <046.80bf6e2eddeb6b8db1c64cf901c24623@haskell.org> References: <046.80bf6e2eddeb6b8db1c64cf901c24623@haskell.org> Message-ID: <061.0786cec2cb0d43ad38216b7134efb8c4@haskell.org> #11051: GHCi with +t option set shows type representations -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): As it turns out generic deriving is also bitten by this, {{{ GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help ?> :set +t ?> :set -XDeriveGeneric ?> import GHC.Generics ?> data Hello = Hello Int deriving (Eq, Generic) abstract C1_0Hello abstract D1Hello data Hello = Hello Int abstract S1_0_0Hello }}} For the record, `hscDeclsWithLocation` in `HscMain` is responsible for the evaluation and generation of `TyThings`. Currently it drops `TyThings` corresponding to implicit `TyCons`/`Ids` and `DFunIds`, {{{#!hs let tcs = filterOut isImplicitTyCon (mg_tcs simpl_mg) patsyns = mg_patsyns simpl_mg ext_ids = [ id | id <- bindersOfBinds core_binds , isExternalName (idName id) , not (isDFunId id || isImplicitId id) ] -- We only need to keep around the external bindings -- (as decided by TidyPgm), since those are the only ones -- that might later be looked up by name. But we can exclude -- - DFunIds, which are in 'cls_insts' (see Note [ic_tythings] in HscTypes -- - Implicit Ids, which are implicit in tcs -- c.f. TcRnDriver.runTcInteractive, which reconstructs the TypeEnv }}} This would be one place to drop the bindings covered by this ticket. However, in order to do this we need to find a way to encode the fact that the bindings are generated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 23 17:09:55 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Nov 2015 17:09:55 -0000 Subject: [GHC] #11129: Nested TH not allowed in declarations Message-ID: <049.2232bb065317d29c28313c6977fe3f2a@haskell.org> #11129: Nested TH not allowed in declarations -------------------------------------+------------------------------------- Reporter: andrewthad | 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 Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I tried to do the following with the `singletons` and `derive` libraries: {{{#!hs $(singletons [d| data CrudRoute = AddR | EditR | DeleteR | ViewR deriving (Eq,Ord,Enum,Bounded,Show) data MyRoute = UsersR | ProfileR | RenameR | DogR CrudRoute deriving (Eq,Ord,Show) $( derive makeEnum ''MyRoute ) |]) }}} GHC fails with the following error message: Splices within declaration brackets not (yet) handled by Template Haskell Here is the github issue where this originated: https://github.com/goldfirere/singletons/issues/135#issuecomment-158936027 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 23 17:18:27 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Nov 2015 17:18:27 -0000 Subject: [GHC] #10656: Ability to get stack traces from Haskell code In-Reply-To: <046.afad267b86c2cf45e3280bfe1e22e59b@haskell.org> References: <046.afad267b86c2cf45e3280bfe1e22e59b@haskell.org> Message-ID: <061.74807b5d6a442c6152db1f712d55c157@haskell.org> #10656: Ability to get stack traces from Haskell code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Tarrasch Type: feature request | 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: #3693 | Differential Rev(s): Phab:D963 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: This has been addressed in Phab:D1196. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 23 17:20:21 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Nov 2015 17:20:21 -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.6ca429a6bf123e5791f18c79e6c0c8ad@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, Wiki Page: | Phab:D1214 -------------------------------------+------------------------------------- Comment (by bgamari): I didn't hear about this. It is currently quite possible to use just plain `perf` but it works relatively poorly while profiling Haskell code due various simplifications to the debug information which GHC must make to fit it into DWARF. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 23 17:21:55 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Nov 2015 17:21:55 -0000 Subject: [GHC] #11112: Error message for accidentally using -> instead of => In-Reply-To: <048.74997cdddf4fddb6f6be3b86d81e7d7a@haskell.org> References: <048.74997cdddf4fddb6f6be3b86d81e7d7a@haskell.org> Message-ID: <063.3bdff3dc8d120ae52ed328fe6e5dbabf@haskell.org> #11112: Error message for accidentally using -> instead of => -------------------------------------+------------------------------------- Reporter: JulesBean | 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: | typecheck/should_fail/tcfail057 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"5955510e5f57464b1f4f42b510e3558d6e691380/ghc" 5955510e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5955510e5f57464b1f4f42b510e3558d6e691380" Improve constraint-used-as-type error msg This responds to Trac #11112 by improving the error message when the kind checker discovers something of kind Constraint used when a type is expected }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 23 17:43:14 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Nov 2015 17:43:14 -0000 Subject: [GHC] #11112: Error message for accidentally using -> instead of => In-Reply-To: <048.74997cdddf4fddb6f6be3b86d81e7d7a@haskell.org> References: <048.74997cdddf4fddb6f6be3b86d81e7d7a@haskell.org> Message-ID: <063.03a5f80af662df7728899fdd2a533fde@haskell.org> #11112: Error message for accidentally using -> instead of => -------------------------------------+------------------------------------- Reporter: JulesBean | 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: | typecheck/should_fail/tcfail057, | typecheck/should_fail/T11112 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: typecheck/should_fail/tcfail057 => typecheck/should_fail/tcfail057, typecheck/should_fail/T11112 * resolution: => fixed Comment: Good idea! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 23 18:28:33 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Nov 2015 18:28:33 -0000 Subject: [GHC] #11129: Nested TH not allowed in declarations In-Reply-To: <049.2232bb065317d29c28313c6977fe3f2a@haskell.org> References: <049.2232bb065317d29c28313c6977fe3f2a@haskell.org> Message-ID: <064.31e5790fe489c4c678c067f32ec412fd@haskell.org> #11129: Nested TH not allowed in declarations -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #6089 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jstolarek): * status: new => closed * resolution: => duplicate * related: => #6089 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 23 18:30:40 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Nov 2015 18:30:40 -0000 Subject: [GHC] #6089: Allow declaration splices inside declaration brackets In-Reply-To: <044.85bbefd435d2792cc792b502a5ebe47e@haskell.org> References: <044.85bbefd435d2792cc792b502a5ebe47e@haskell.org> Message-ID: <059.a393f876fe14ca2cfb6a66cf3c31ca2f@haskell.org> #6089: Allow declaration splices inside declaration brackets -------------------------------------+------------------------------------- Reporter: igloo | Owner: simonpj Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11129 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jstolarek): * related: => #11129 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 23 20:58:25 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Nov 2015 20:58:25 -0000 Subject: [GHC] #11028: Refactor ConDecl In-Reply-To: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> References: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> Message-ID: <061.44afe6a3441bdef3ba79359f3f9deab4@haskell.org> #11028: Refactor ConDecl -------------------------------------+------------------------------------- Reporter: simonpj | Owner: alanz 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * owner: => alanz Comment: I am making a start on this, using `wip/spj-wildcard-refactor` as the base. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 23 22:49:31 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Nov 2015 22:49:31 -0000 Subject: [GHC] #11028: Refactor ConDecl In-Reply-To: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> References: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> Message-ID: <061.d93ff970c728b24a8e869986634aea8f@haskell.org> #11028: Refactor ConDecl -------------------------------------+------------------------------------- Reporter: simonpj | Owner: alanz 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Old description: > The `ConDecl` type in `HsDecls` is an uneasy compromise. For the most > part, `HsSyn` directly reflects the syntax written by the programmer; and > that gives just the right "pegs" on which to hang Alan's > [wiki:ApiAnnotations API annotations]. But `ConDecl` doesn't properly > reflect the syntax of Haskell-98 and GADT-style data type declarations. > > To be concrete, here's a draft new data type > {{{ > data ConDecl name > | ConDeclGADT > { con_names :: [Located name] > , con_type :: LHsSigType name -- The type after the ?::? > , con_doc :: Maybe LHsDocString > , con_old_rec :: Bool } > > | ConDeclH98 > { con_name :: Located name > > , con_implict :: HsImplicitBndrs () > -- ^ Implicit binders, added by renamer > > , con_qvars :: Maybe [LHsTyVarBndr name] > -- User-written foralls (if any) > > , con_cxt :: Maybe (LHsContext name) > -- ^ User-written context (if any) > > , con_details :: HsConDeclDetails name > -- ^ Arguments > > , con_doc :: Maybe LHsDocString > -- ^ A possible Haddock comment. > } deriving (Typeable) > }}} > Note that > * For GADTs, just keep a type. That's what the user writes. (NB: > `HsType` can represent records on the LHS of an arrow: `{ x:Int,y:Bool } > -> T` > > * `con_qvars` and `con_cxt` are both `Maybe` because they are both > optional (the `forall` and the context of an existential data type) > > * The `con_old_rec` is a warning thing for GADTs (see current source > code) > > This ticket is just to track the thought and invite feedback. New description: The `ConDecl` type in `HsDecls` is an uneasy compromise. For the most part, `HsSyn` directly reflects the syntax written by the programmer; and that gives just the right "pegs" on which to hang Alan's [wiki:ApiAnnotations API annotations]. But `ConDecl` doesn't properly reflect the syntax of Haskell-98 and GADT-style data type declarations. To be concrete, here's a draft new data type {{{ data ConDecl name | ConDeclGADT { con_names :: [Located name] , con_type :: LHsSigType name -- The type after the ?::? , con_doc :: Maybe LHsDocString } | ConDeclH98 { con_name :: Located name , con_implict :: HsImplicitBndrs () -- ^ Implicit binders, added by renamer , con_qvars :: Maybe [LHsTyVarBndr name] -- User-written foralls (if any) , con_cxt :: Maybe (LHsContext name) -- ^ User-written context (if any) , con_details :: HsConDeclDetails name -- ^ Arguments , con_doc :: Maybe LHsDocString -- ^ A possible Haddock comment. } deriving (Typeable) }}} Note that * For GADTs, just keep a type. That's what the user writes. (NB: `HsType` can represent records on the LHS of an arrow: `{ x:Int,y:Bool } -> T` * `con_qvars` and `con_cxt` are both `Maybe` because they are both optional (the `forall` and the context of an existential data type) This ticket is just to track the thought and invite feedback. -- Comment (by simonpj): Terrific. Please make a branch and push to it, so I can join in. Will you use the above data type as the basis? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 23 22:57:34 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Nov 2015 22:57:34 -0000 Subject: [GHC] #11028: Refactor ConDecl In-Reply-To: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> References: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> Message-ID: <061.86fb2e4a30562c8990e809759f3997c0@haskell.org> #11028: Refactor ConDecl -------------------------------------+------------------------------------- Reporter: simonpj | Owner: alanz 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Old description: > The `ConDecl` type in `HsDecls` is an uneasy compromise. For the most > part, `HsSyn` directly reflects the syntax written by the programmer; and > that gives just the right "pegs" on which to hang Alan's > [wiki:ApiAnnotations API annotations]. But `ConDecl` doesn't properly > reflect the syntax of Haskell-98 and GADT-style data type declarations. > > To be concrete, here's a draft new data type > {{{ > data ConDecl name > | ConDeclGADT > { con_names :: [Located name] > , con_type :: LHsSigType name -- The type after the ?::? > , con_doc :: Maybe LHsDocString } > > | ConDeclH98 > { con_name :: Located name > > , con_implict :: HsImplicitBndrs () > -- ^ Implicit binders, added by renamer > > , con_qvars :: Maybe [LHsTyVarBndr name] > -- User-written foralls (if any) > > , con_cxt :: Maybe (LHsContext name) > -- ^ User-written context (if any) > > , con_details :: HsConDeclDetails name > -- ^ Arguments > > , con_doc :: Maybe LHsDocString > -- ^ A possible Haddock comment. > } deriving (Typeable) > }}} > Note that > * For GADTs, just keep a type. That's what the user writes. (NB: > `HsType` can represent records on the LHS of an arrow: `{ x:Int,y:Bool } > -> T` > > * `con_qvars` and `con_cxt` are both `Maybe` because they are both > optional (the `forall` and the context of an existential data type) > > This ticket is just to track the thought and invite feedback. New description: The `ConDecl` type in `HsDecls` is an uneasy compromise. For the most part, `HsSyn` directly reflects the syntax written by the programmer; and that gives just the right "pegs" on which to hang Alan's [wiki:ApiAnnotations API annotations]. But `ConDecl` doesn't properly reflect the syntax of Haskell-98 and GADT-style data type declarations. To be concrete, here's a draft new data type {{{ data ConDecl name | ConDeclGADT { con_names :: [Located name] , con_type :: LHsSigType name -- The type after the ?::? , con_doc :: Maybe LHsDocString } | ConDeclH98 { con_name :: Located name , con_qvars :: Maybe (LHsQTyVars name) -- User-written forall (if any), and its implicit -- kind variables -- Non-Nothing needs -XExistentialQuantification , con_cxt :: Maybe (LHsContext name) -- ^ User-written context (if any) , con_details :: HsConDeclDetails name -- ^ Arguments , con_doc :: Maybe LHsDocString -- ^ A possible Haddock comment. } deriving (Typeable) }}} Note that * For GADTs, just keep a type. That's what the user writes. (NB: `HsType` can represent records on the LHS of an arrow: `{ x:Int,y:Bool } -> T` * `con_qvars` and `con_cxt` are both `Maybe` because they are both optional (the `forall` and the context of an existential data type * For `ConDeclGADT` the type variables of the data type do ''not'' scope over the `con_type`; whereas for `ConDeclH98` they ''do'' scope over `con_cxt` and `con_details`. This ticket is just to track the thought and invite feedback. -- Comment (by simonpj): PS: I have edited the proposed data type a bit. Do you agree with it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 24 00:37:27 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Nov 2015 00:37:27 -0000 Subject: [GHC] #10952: Use IPids instead of package keys in HPC tix files In-Reply-To: <046.2961695834220c5d8e713a72077c82af@haskell.org> References: <046.2961695834220c5d8e713a72077c82af@haskell.org> Message-ID: <061.128e6e087edb44b0ecb4692b4718c3d4@haskell.org> #10952: Use IPids instead of package keys in HPC tix files -------------------------------------+------------------------------------- Reporter: mgsloan | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Code Coverage | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): mgsloan: To answer your seven weeks ago question: tix module names will include the full package name + version number + hash (they will just be what you think of as the IPID). I am not sure this DIRECTLY solves your problem; you still need an IPID, but you can avoid going through ghc-pkg. (Unless you need to support backwards compatibility). Feuerbach: I don't quite understand your problem. Is the assigned package key from the inplace and the installed version actually different? I don't think should be true in 7.10; if it is that's some sort of bug. Is this giving you grief for 7.8 as well? I can advise on package key/IPID related issues, but I know very little about the hpc tool. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 24 00:43:56 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Nov 2015 00:43:56 -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.cd06ab0dc252509fc0aa16d4224227fc@haskell.org> #10726: Upgrade MingW-w64 distributions for windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.3 Component: Build System | Version: 7.11 Resolution: | 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 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by lukexi): * Attachment "add_missing_symbols.patch" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 24 00:48:11 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Nov 2015 00:48: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.8521ce072a2d5f5492401676b8d91ba4@haskell.org> #10726: Upgrade MingW-w64 distributions for windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: task | Status: patch Priority: high | Milestone: 7.10.3 Component: Build System | Version: 7.11 Resolution: | 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 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by lukexi): * priority: normal => high * status: new => patch Comment: OK, with these 5 symbols added all of my libraries are working perfectly again. {{{ diff --git a/rts/Linker.c b/rts/Linker.c index 68f1f59..a939e35 100644 --- a/rts/Linker.c +++ b/rts/Linker.c @@ -525,6 +525,11 @@ typedef struct _RtsSymbolVal { SymI_HasProto(isalnum) \ SymI_HasProto(isascii) \ RTS___MINGW_VFPRINTF_SYM \ + SymI_HasProto(__mingw_vsscanf) \ + SymI_HasProto(__mingw_vprintf) \ + SymI_HasProto(__mingw_vsprintf) \ + SymI_HasProto(__ms_vsnprintf) \ + SymI_HasProto(strdup) \ SymI_HasProto(strcmp) \ SymI_HasProto(memmove) \ SymI_HasProto(realloc) \ }}} After fully upgrading my MSYS2 installation I was also able to remove the brittle `extra-lib-dirs` hacks in my libraries that needed `libstdc++-6.dll`, which is great! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 24 02:20:09 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Nov 2015 02:20:09 -0000 Subject: [GHC] #10382: Template Haskell (non-quasi) quotes should work with stage 1 compiler In-Reply-To: <045.918a9569238e9d04ed4e2e3a730bb569@haskell.org> References: <045.918a9569238e9d04ed4e2e3a730bb569@haskell.org> Message-ID: <060.38be6977e1f5428cd2fab8661ccaeac7@haskell.org> #10382: Template Haskell (non-quasi) quotes should work with stage 1 compiler -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Template Haskell | 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 Rev(s): Phab:D876 Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I was trying to update TH parts of user manual about which quotes can be run by stage1 compiler, and on the way I found out that tests in `quotes/` directory are currently not running under stage1. I tried this: - I run a test using top-level Makefile, e.g. `make TEST=T2632` in `testsuite/`. - I realized it's running using stage2 compiler. But the whole point of moving these tests to a new directory was to test them using stage1 compiler. - When I tried compiling the test using stage1 compiler(I copied the command and replaced stage2 with stage1), it failed with this: {{{ $ ./tests/quotes && "/home/omer/haskell/ghc/inplace/test spaces/ghc- stage1" -c T2632.hs -fforce-recomp -dcore-lint -dcmm-lint -dno-debug- output -no-user-package-db -rtsopts -fno-warn-tabs -fno-warn-missed- specialisations -fno-ghci-history -XTemplateHaskell -package template- haskell T2632.hs:10:9: error: Can't find interface-file declaration for type constructor or class DecsQ Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error In the expression: [d| func = 0 `op` 3 |] In an equation for ?decl1?: decl1 = [d| func = 0 `op` 3 |] T2632.hs:12:9: error: Can't find interface-file declaration for type constructor or class DecsQ Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error In the expression: [d| op x y = x func = 0 `op` 3 |] In an equation for ?decl2?: decl2 = [d| op x y = x func = 0 `op` 3 |] }}} I also tried the same thing on some manually created simple TH code and they all failed with same error. It seems like there's a bug somewhere. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 24 02:38:06 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Nov 2015 02:38:06 -0000 Subject: [GHC] #11127: Update cabal submodule to 1.22.5 (was: Update cabal submodule to 1.22 branch HEAD) In-Reply-To: <045.b86ccf3972e67654868d36d88f8530d9@haskell.org> References: <045.b86ccf3972e67654868d36d88f8530d9@haskell.org> Message-ID: <060.f444b611d663e345e1d3eaa6b6ebd576@haskell.org> #11127: Update cabal submodule to 1.22.5 -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Type: task | Status: new Priority: high | Milestone: 7.10.3 Component: libraries | Version: (other) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by lukexi): * status: closed => new * type: bug => task * resolution: wontfix => Old description: > For 7.10.3, this will fold in a critical fix for Mac (the Cabal side of > #10568), along with a fix to prevent c-sources from being recompiled > unnecessarily (a big deal when working with large C/C++ bindings). > > The commit is `5acbc41` > > https://github.com/haskell/cabal/tree/1.22 New description: For 7.10.3, this will fold in a critical fix for Mac (the Cabal side of #10568), along with a fix to prevent c-sources from being recompiled unnecessarily (a big deal when working with large C/C++ bindings). The commit is `fb7ce39` https://github.com/haskell/cabal/tree/1.22 -- Comment: Hi Ben, I'll assume you misread the title and thought I was asking for a bump to Cabal actual HEAD, since that is indeed a 22K line diff : ). This is just a bump from 1.22.4 to 1.22.5 and it's about 58 lines. https://github.com/haskell/cabal/compare/75266d2222eeefccfc26f28ca5d6c2dccf6de73f...1.22 I'll go ahead and reopen this based on that assumption, hope that's not rude : ). Mikhail tagged a 1.22.5 release so the relevant commit is now `75266d2`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 24 02:39:50 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Nov 2015 02:39:50 -0000 Subject: [GHC] #11127: Update cabal submodule to 1.22.5 In-Reply-To: <045.b86ccf3972e67654868d36d88f8530d9@haskell.org> References: <045.b86ccf3972e67654868d36d88f8530d9@haskell.org> Message-ID: <060.278df0dabea37d46deaef47acb80c175@haskell.org> #11127: Update cabal submodule to 1.22.5 -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Type: task | Status: new Priority: high | Milestone: 7.10.3 Component: libraries | Version: (other) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by lukexi): (oops, I meant `fb7ce39`) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 24 02:46:27 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Nov 2015 02:46:27 -0000 Subject: [GHC] #10382: Template Haskell (non-quasi) quotes should work with stage 1 compiler In-Reply-To: <045.918a9569238e9d04ed4e2e3a730bb569@haskell.org> References: <045.918a9569238e9d04ed4e2e3a730bb569@haskell.org> Message-ID: <060.acbcd4700b691beb0e6ea7cbea6fc39a@haskell.org> #10382: Template Haskell (non-quasi) quotes should work with stage 1 compiler -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: normal | 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 Rev(s): Phab:D876 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * owner: ezyang => * status: closed => new * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 24 02:46:50 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Nov 2015 02:46:50 -0000 Subject: [GHC] #10382: Template Haskell (non-quasi) quotes should work with stage 1 compiler In-Reply-To: <045.918a9569238e9d04ed4e2e3a730bb569@haskell.org> References: <045.918a9569238e9d04ed4e2e3a730bb569@haskell.org> Message-ID: <060.2e429ab442dba07eb06b63f7b942a9b0@haskell.org> #10382: Template Haskell (non-quasi) quotes should work with stage 1 compiler -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: normal | 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 Rev(s): Phab:D876 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): We also need a way to force the test suite to run stage1 in some cases, so we can catch this regression next time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 24 03:26:51 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Nov 2015 03:26:51 -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.8150ed7fdf90659c56e6c027a04d9ae9@haskell.org> #10726: Upgrade MingW-w64 distributions for windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: task | Status: patch Priority: high | Milestone: 7.10.3 Component: Build System | Version: 7.11 Resolution: | 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 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by lukexi): I've uploaded a build with the patch here (along with bumping Cabal to 1.22.5): https://github.com/lukexi/ghc/releases/download/ghc-7.10.3-rc2-plus- export-symbols/ghc-7.10.2.20151117-x86_64-unknown-mingw32.tar.bz2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 24 07:37:19 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Nov 2015 07:37:19 -0000 Subject: [GHC] #11028: Refactor ConDecl In-Reply-To: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> References: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> Message-ID: <061.9f9bfcc44cbe8b4e7b961e71033eb9f2@haskell.org> #11028: Refactor ConDecl -------------------------------------+------------------------------------- Reporter: simonpj | Owner: alanz 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alanz): Yes, it maps more clearly on to the original. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 24 07:47:56 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Nov 2015 07:47:56 -0000 Subject: [GHC] #10952: Use IPids instead of package keys in HPC tix files In-Reply-To: <046.2961695834220c5d8e713a72077c82af@haskell.org> References: <046.2961695834220c5d8e713a72077c82af@haskell.org> Message-ID: <061.92a0793d90aae195409bc793115fb015@haskell.org> #10952: Use IPids instead of package keys in HPC tix files -------------------------------------+------------------------------------- Reporter: mgsloan | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Code Coverage | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Feuerbach): Is the assigned package key from the inplace and the installed version actually different? Yes it is. The two versions also have different package ids (which may be the cause; I'm not sure about what goes into a package key): {{{ --- ./lib/.stack- work/dist/x86_64-linux/Cabal-1.22.4.0/package.conf.inplace/presta- lib-1.0-inplace.conf 2015-11-24 09:32:13.518081305 +0200 +++ ./.stack-work/install/x86_64-linux/lts-3.3/7.10.2/pkgdb/presta- lib-1.0-1e1cf758eabdea7023a4cecbff20ce1f.conf 2015-11-24 09:29:31.266011461 +0200 @@ -1,7 +1,7 @@ name: presta-lib version: 1.0 -id: presta-lib-1.0-inplace -key: prest_1NxNAwYoYvk6w7VMhPEYyX +id: presta-lib-1.0-1e1cf758eabdea7023a4cecbff20ce1f +key: prest_8KWvpj6fKCvE66cwDmJopU }}} Is this giving you grief for 7.8 as well? Well, the issue being discussed wasn't present in ghc 7.8, so, no, it wasn't. (And we also don't use 7.8 at work anymore.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 24 07:53:18 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Nov 2015 07:53:18 -0000 Subject: [GHC] #11128: New `-fwarn-noncanonical-monad-instances` warning In-Reply-To: <042.e02ab93445edf67c384ef57b5dac6baf@haskell.org> References: <042.e02ab93445edf67c384ef57b5dac6baf@haskell.org> Message-ID: <057.47c5690e0448f0a81413930ba3abf445@haskell.org> #11128: New `-fwarn-noncanonical-monad-instances` warning -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: feature request | 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 Rev(s): Phab:D1516 Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:2 nomeata]: > Do you intentionally disallow `return x = pure x`, which some people might write? (No strong opinion here, having precisely one official way is probably desirable, but let?s at least document that it has been given thought.) Yes, that was quite intentional, and there are a couple of reasons actually: - I found only *one* single `return a = pure a` on Hackage when I grepped for `rgrep 'return *[a-z] *= *pure *[a-z]'`; this is maybe because any instructions I saw for making code AMP-proof used rather pointsfree equational style e.g. (`return = pure`), and the Haddock documentation in `base` uses that style too - the warning is easier to document, implement, and less corner-cases to worry about - "canonical" somewhat implies we want a single unique form here, this also has the benefit of being able to have a simpler regexp to find all `return *= *pure` patterns in your codebase (e.g. if you want to drop those when base<4.8 compat doesn't matter anymore) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 24 09:27:00 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Nov 2015 09:27:00 -0000 Subject: [GHC] #11028: Refactor ConDecl In-Reply-To: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> References: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> Message-ID: <061.777d0755dc6d93984e25a5094a7dfba5@haskell.org> #11028: Refactor ConDecl -------------------------------------+------------------------------------- Reporter: simonpj | Owner: alanz 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alanz): I wonder if we should use `ConDeclSimple` instead of `ConDeclH98`. Alternatively `mkSimpleConDecl` should become `mkCondeclH98`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 24 09:33:11 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Nov 2015 09:33:11 -0000 Subject: [GHC] #11028: Refactor ConDecl In-Reply-To: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> References: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> Message-ID: <061.cda34ddf27250b4da0f96b17b898c41d@haskell.org> #11028: Refactor ConDecl -------------------------------------+------------------------------------- Reporter: simonpj | Owner: alanz 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alanz): Also, at the moment the `con_doc` field is never set for a GADT. It should either be removed or the parser modified to allow docs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 24 09:52:08 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Nov 2015 09:52:08 -0000 Subject: [GHC] #11028: Refactor ConDecl In-Reply-To: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> References: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> Message-ID: <061.ea8db7f181c68d2d6d1a188ddb49ec22@haskell.org> #11028: Refactor ConDecl -------------------------------------+------------------------------------- Reporter: simonpj | Owner: alanz 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jstolarek): Replying to [comment:11 alanz]: > I wonder if we should use `ConDeclSimple` instead of `ConDeclH98`. > > Alternatively `mkSimpleConDecl` should become `mkCondeclH98`. I vote for the latter - `mkConDeclH98` is more informative than `mkSimpleConDecl`. >Also, at the moment the `con_doc` field is never set for a GADT. It should either be removed or the parser modified to allow docs. Again, my vote for the latter. If we store docs for H98 constructors then we should also store them for GADTs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 24 09:58:34 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Nov 2015 09:58:34 -0000 Subject: [GHC] #10382: Template Haskell (non-quasi) quotes should work with stage 1 compiler In-Reply-To: <045.918a9569238e9d04ed4e2e3a730bb569@haskell.org> References: <045.918a9569238e9d04ed4e2e3a730bb569@haskell.org> Message-ID: <060.e45ab5bf75981d4700472a2cdcc62ad9@haskell.org> #10382: Template Haskell (non-quasi) quotes should work with stage 1 compiler -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: normal | 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 Rev(s): Phab:D876 Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): Replying to [comment:20 ezyang]: > We also need a way to force the test suite to run stage1 in some cases, so we can catch this regression next time. I see three options: * Option 1 (change validate) - create a directory with tests that should be tested with the stage1 compiler. - In ./validate, add something like `make -C testsuite/tests/stage1-tests stage=1` (The full command would also include: `$MAKE_TEST_TARGET $BINDIST $TEST_VERBOSITY THREADS=$threads SUMMARY_FILE=...)` - Make sure the grepping for results in testsuite_summary.txt still does the right thing (bit fiddly) - Minor point: define target synonyms `fasttest` and `slowtest` in `testsuite/Makefile` and `testsuite/mk/test.mk`) * Option 2 (driver support) - add a new setup function to testsuite/driver/testlib.py: something like `def stage(n)` or `def stage1()` - assign the `STAGE1_GHC` variable from testsuite/mk/boilerplate.mk should to a new option config.stage1 (add `--config 'stage1=$(call quote_path,$(STAGE1_GHC))'` to RUNTEST_OPTS in testsuite/mk/test.mk, and change testsuite/driver/runtests.py and testsuite/driver/testglobals.py. - add a `compiler` field to TestOptions (testsuite/driver/testglobals.py). By default it should contain config.compiler (do so in `def test` in testsuite/driver/testlib.py, not sure..) - the setup function `stage1()` sets opts.compiler to config.stage1, but only when the stage1 compiler is available. When TEST_HC is specified or when TEST_HC is implied to be an installed compiler, STAGE1_GHC won't be defined. - change all uses of config.compiler to opts.compiler (grep also for '{compiler}'). * Option 3 (Makefile) - define the test in a Makefile. Refer to `STAGE1_GHC` instead of `TEST_HC`. Skip if empty. The drawback of option 1 is that a failing validate might confuse GHC developers, because they can't reproduce the test failure when running the test locally (they'd have to specify make stage=1, which isn't obvious). Many questions on IRC/Phabricator/mail. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 24 10:33:15 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Nov 2015 10:33:15 -0000 Subject: [GHC] #11123: Arm: checkProddableBlock: invalid fixup in runtime linker In-Reply-To: <044.92e8587d5182968d745cf903b273dfec@haskell.org> References: <044.92e8587d5182968d745cf903b273dfec@haskell.org> Message-ID: <059.b95bc2b01945d691e82f593eeddfe5e6@haskell.org> #11123: Arm: checkProddableBlock: invalid fixup in runtime linker ----------------------------------------+----------------------------- 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: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+----------------------------- Comment (by erikd): The error occurs even with `inplace/bin/ghc-stage2 --interactive`. Running as `inplace/bin/ghc-stage2 +RTS -Dl -RTS --interactive` it finishes off with: {{{ addOTabName(GLOB): 0xb6c7cba0 /home/erikd/Git/ghc-upstream/libraries/ghc- prim/ dist-install/build/HSghc-prim-0.5.0.0.o hs_word2float64 addSection: (nil)-0x19d3e1 (size 1692641), kind 3 addSection: (nil)-0x92 (size 146), kind 3 loadOc: done. resolveObjs: start relocations for section 1 using symtab 15 and strtab 16 Rel entry 0 is raw( 0x1c 0x5c962b)lookupSymbol: looking up stg_upd_frame_info lookupSymbol: value of stg_upd_frame_info is 0x1efba00 `stg_upd_frame_info' resolves to 0x1efba00 Reloc: P = 0xb6c02050 S = 0x1efba00 A = 0xe3002000 ghc-stage2: internal error: checkProddableBlock: (called from line 5064) invalid fixup in runtime linker: 0xb6c02050 (GHC version 7.11.20151124 for arm_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted }}} At first I thought a `start` value of `nil` (as is being passed to `addSection` was a problem, but that happens on x86_64 as well, without a problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 24 10:33:33 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Nov 2015 10:33:33 -0000 Subject: [GHC] #11112: Error message for accidentally using -> instead of => In-Reply-To: <048.74997cdddf4fddb6f6be3b86d81e7d7a@haskell.org> References: <048.74997cdddf4fddb6f6be3b86d81e7d7a@haskell.org> Message-ID: <063.db0bd3a0a9f46e787c7b5196967ba6af@haskell.org> #11112: Error message for accidentally using -> instead of => -------------------------------------+------------------------------------- Reporter: JulesBean | 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: | typecheck/should_fail/tcfail057, | typecheck/should_fail/T11112 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by JulesBean): Great! Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 24 10:42:33 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Nov 2015 10:42:33 -0000 Subject: [GHC] #11028: Refactor ConDecl In-Reply-To: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> References: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> Message-ID: <061.f37b6681356bf77aecad781c3e7d4dc7@haskell.org> #11028: Refactor ConDecl -------------------------------------+------------------------------------- Reporter: simonpj | Owner: alanz 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes, I think I prefer `mkConDeclH98` too. As to `con_doc` it depends on the Haddock folk. Maybe file a ticket on the Haddock issue tracker; I don't know if they have a story about documentation GADT data types. But they should! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 24 10:52:59 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Nov 2015 10:52:59 -0000 Subject: [GHC] #11028: Refactor ConDecl In-Reply-To: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> References: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> Message-ID: <061.12529b39c078f16d6492ed032090bdb7@haskell.org> #11028: Refactor ConDecl -------------------------------------+------------------------------------- Reporter: simonpj | Owner: alanz 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alanz): Seems I was wrong about the `con_doc`, it is added after the fact by `addConDoc` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 24 11:32:43 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Nov 2015 11:32:43 -0000 Subject: [GHC] #9015: A documented way to differentiate between statements, declarations, imports, etc. In-Reply-To: <054.7f6a461675f798415503e3e2ad38cdb0@haskell.org> References: <054.7f6a461675f798415503e3e2ad38cdb0@haskell.org> Message-ID: <069.7e5f806c29ee44906fe4139d9989a910@haskell.org> #9015: A documented way to differentiate between statements, declarations, imports, etc. -------------------------------------+------------------------------------- Reporter: splinterofchaos | Owner: roshats Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: GHC API | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: ghc-api/T9015 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1518 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * testcase: => ghc-api/T9015 * differential: => Phab:D1518 * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 24 11:48:44 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Nov 2015 11:48:44 -0000 Subject: [GHC] #11128: New `-fwarn-noncanonical-monad-instances` warning In-Reply-To: <042.e02ab93445edf67c384ef57b5dac6baf@haskell.org> References: <042.e02ab93445edf67c384ef57b5dac6baf@haskell.org> Message-ID: <057.253c4c6f2ed9dec76ac2d544564df61f@haskell.org> #11128: New `-fwarn-noncanonical-monad-instances` warning -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: feature request | 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 Rev(s): Phab:D1516 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"f09f2470a76bb08b7f51d2f5663daa672b86f618/ghc" f09f2470/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f09f2470a76bb08b7f51d2f5663daa672b86f618" Implement new `-fwarn-noncanonical-monad-instances` Warn about incoherent/non-canonical 'Applicative'/'Monad' instance declarations. Specifically the following invariants are checked: In 'Monad' instances declarations warn if the any of the following conditions does not hold: * If `return` is overridden it must be canonical (i.e. `return = pure`). * If `(>>)` is overridden it must be canonical (i.e. `(>>) = (*>)`). In 'Applicative' instance declarations: * Warn if 'pure' is defined backwards (i.e. `pure = return`). * Warn if '(*>)' is defined backwards (i.e. `(*>) = (>>)`). NB, this warning flag is not enabled via `-Wall` nor `-Wcompat`. This addresses #11128 Reviewers: quchen, austin, bgamari Reviewed By: bgamari Differential Revision: https://phabricator.haskell.org/D1516 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 24 12:15:08 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Nov 2015 12:15:08 -0000 Subject: [GHC] #11128: New `-fwarn-noncanonical-monad-instances` warning In-Reply-To: <042.e02ab93445edf67c384ef57b5dac6baf@haskell.org> References: <042.e02ab93445edf67c384ef57b5dac6baf@haskell.org> Message-ID: <057.175ecef61e890d591731b6d3063c7a93@haskell.org> #11128: New `-fwarn-noncanonical-monad-instances` warning -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: feature request | 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 Rev(s): Phab:D1516 Wiki Page: | -------------------------------------+------------------------------------- Description changed by hvr: Old description: > (see description in Phab:D1516 for the meantime) New description: When declaring `Applicative` and `Monad` instances, there's a degree of freedom in which way to define `return`,`pure`,`(>>)`,`(*>)`. For instance, defining {{{#!hs instance Applicative T1 where pure = return (<*>) = ap instance Monad T1 where return = ... (>>=) = ... (>>) = ... }}} is ok, but it's leaves `(*>)` with a possibly less optimised version than `(>>)`. This can cause performance regressions when generalising code from `Monad` to `Applicative`. Moreover, starting with `base-4.8`, the `return` method gained a default implementation `return = pure` which follows the preferred or "canonical" direction of having implementations flow from superclasses to their subclasses. So this warning is a "lint"-style check to help detect `Monad` instances where the definitions of `return`/`(>>)` are not canonical, i.e. don't match `return = pure` and `(>>) = (*>)` respectively. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 24 12:19:52 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Nov 2015 12:19:52 -0000 Subject: [GHC] #11128: New `-fwarn-noncanonical-monad-instances` warning In-Reply-To: <042.e02ab93445edf67c384ef57b5dac6baf@haskell.org> References: <042.e02ab93445edf67c384ef57b5dac6baf@haskell.org> Message-ID: <057.ba4aefbad8d00e7160d1ec5df095df95@haskell.org> #11128: New `-fwarn-noncanonical-monad-instances` warning -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: feature request | 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 Rev(s): Phab:D1516 Wiki Page: | -------------------------------------+------------------------------------- Description changed by hvr: Old description: > When declaring `Applicative` and `Monad` instances, there's a degree of > freedom in which way to define `return`,`pure`,`(>>)`,`(*>)`. For > instance, defining > > {{{#!hs > instance Applicative T1 where > pure = return > (<*>) = ap > > instance Monad T1 where > return = ... > (>>=) = ... > (>>) = ... > }}} > > is ok, but it's leaves `(*>)` with a possibly less optimised version than > `(>>)`. This can cause performance regressions when generalising code > from `Monad` to `Applicative`. > > Moreover, starting with `base-4.8`, the `return` method gained a default > implementation `return = pure` which follows the preferred or "canonical" > direction of having implementations flow from superclasses to their > subclasses. > > So this warning is a "lint"-style check to help detect `Monad` instances > where the definitions of `return`/`(>>)` are not canonical, i.e. don't > match `return = pure` and `(>>) = (*>)` respectively. New description: When declaring `Applicative` and `Monad` instances, there's a degree of freedom in which way to define `return`,`pure`,`(>>)`,`(*>)`. For instance, defining {{{#!hs instance Applicative T1 where pure = return (<*>) = ap instance Monad T1 where return = ... (>>=) = ... (>>) = {- optimised impl -} }}} is ok, but this leaves `(*>)` with a possibly less optimised version than `(>>)`. This can cause performance regressions when generalising code from `Monad` to `Applicative`. Moreover, starting with `base-4.8`, the `return` method gained a default implementation `return = pure` which follows the preferred or "canonical" direction of having implementations flow from superclasses to their subclasses. A proper "canonical" definition of `T1` is consequently: {{{#!hs instance Applicative T1 where pure = ... (<*>) = ap (*>) = {- optimised impl -} instance Monad T1 where return = pure -- can be left off since base-4.8 (>>=) = ... (>>) = (*>) -- NB: default impl of (>>) /= (*>) }}} So this warning is a "lint"-style check to help detect `Monad` instances where the definitions of `return`/`(>>)` are not canonical, i.e. don't match `return = pure` and `(>>) = (*>)` respectively. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 24 12:23:39 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Nov 2015 12:23:39 -0000 Subject: [GHC] #11128: New `-fwarn-noncanonical-monad-instances` warning In-Reply-To: <042.e02ab93445edf67c384ef57b5dac6baf@haskell.org> References: <042.e02ab93445edf67c384ef57b5dac6baf@haskell.org> Message-ID: <057.d3d03e4ffdf0f0fde0cb872b07c6c4a8@haskell.org> #11128: New `-fwarn-noncanonical-monad-instances` warning -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: feature request | 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: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1516 Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 24 12:34:04 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Nov 2015 12:34:04 -0000 Subject: [GHC] #11028: Refactor ConDecl In-Reply-To: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> References: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> Message-ID: <061.044955d0e48b232d3f983e03cdacceba@haskell.org> #11028: Refactor ConDecl -------------------------------------+------------------------------------- Reporter: simonpj | Owner: alanz 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alanz): At the moment `kcConDecl` is defined as {{{#!hs kcConDecl (ConDecl { con_names = names, con_qvars = ex_tvs , con_cxt = ex_ctxt, con_details = details , con_res = res }) = addErrCtxt (dataConCtxtName names) $ -- the 'False' says that the existentials don't have a CUSK, as the -- concept doesn't really apply here. We just need to bring the variables -- into scope! do { _ <- kcHsTyVarBndrs False ex_tvs $ do { _ <- tcHsContext ex_ctxt ; mapM_ (tcHsOpenType . getBangType) (hsConDeclArgTys details) ; _ <- tcConRes res ; return (panic "kcConDecl", ()) } ; return () } }}} I am working on the `ConDeclGADT` case, and have {{{#!hs kcConDecl (ConDeclGADT { con_name = name , con_type = HsIB { hsib_kvs = ex_kvs , hsib_tvs = ex_tvs , hsib_body = res_ty} }) = addErrCtxt (dataConCtxtName [name]) $ -- the 'False' says that the existentials don't have a CUSK, as the -- concept doesn't really apply here. We just need to bring the variables -- into scope! do { _ <- kcHsTyVarBndrs False ex_tvs $ ..... ; return () } }}} It is not clear to me whether `kcHsTyVarBndrs False ex_tvs` should be checking `ex_kvs`, `ex_tvs`, or both. I suspect `ex_kvs` only. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 24 12:39:51 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Nov 2015 12:39:51 -0000 Subject: [GHC] #11028: Refactor ConDecl In-Reply-To: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> References: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> Message-ID: <061.5341b3b8d7c367b780b100e5c90e26bb@haskell.org> #11028: Refactor ConDecl -------------------------------------+------------------------------------- Reporter: simonpj | Owner: alanz 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): No no! `con_type` is a `LHsSigType`. So use `TcHsType.kcClassSigType` (give it a less specific name!); it does exactly the right thing. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 24 12:49:11 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Nov 2015 12:49:11 -0000 Subject: [GHC] #11120: Missing type representations In-Reply-To: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> References: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> Message-ID: <062.a5cf05e76cc8567ff946de81789db0b1@haskell.org> #11120: Missing type representations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: high | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > 1. You say (in Note [Grand plan for Typeable]) that there is trouble > making the TyCon/Module information for the types in GHC.Types. But > what precisely goes wrong? I agree that it seems a bit fishy, but I > don't actually see the spot where trouble lurks. Did you try this? The difficulty is we can't generate the `TyCon` and `Module` for things in `GHC.Types` when `TyCon` and `Module` are not yet defined. The Grand Plan comment says: It's hard to generate the TyCon/Module bindings when the types TyCon and Module aren't yet available; i.e. when compiling GHC.Types Now what we ''could'' do (and it'd probably be a goodea) would be to put * TyCon * Module * Char * List * TrName in `GHC.Types`, and move the other types (eg `Float`, `Double`) out, so that their type-reps *can* be derived by the normal mechanism. > 3. Let's assume that we really can't clean up this mess. It still seems > that several TyCons are missing from Data.Typeable.Internal. Like > promoted nil and cons, and Nat, and Symbol. At the least, we should > put a loud comment in the export list of GHC.Types saying that > everything defined there must be accompanied by a definition in > Data.Typeable.Internal. You are right. The above might ameliorate the problem. If it'd make your kind-equality work easier by all means do this. > 2. Even more bizarre would be putting TyCon/Module info for GHC.Prim > stuff (I'm thinking about the super-magical TYPE) right in GHC.Prim. But currently `TyCon` uses list and `Char`. Do you want to put them in `GHC.Prim`? How would that differ, really, from what we have now. And `TyCon` and `Module` both require actual code, whereas `GHC.Prim` types have no code. To respond to your suggestion more clearly I'd need more info on what you have in mind. > 4. `Data.Typeable.Internal` uses `mkGhcTypesTyCon`, which refers to `GHC.Types` I don't understand the issue here. > That looks like the tycon's fingerprint is bogus whenever the module is compiled with `-dsuppress-uniques`. But I always understood `-dsuppress- uniques` to be a flag used only to control output, and that it should affect only the pretty-printer. So I'm very dubious of this code. Good point. But failing to suppress means that `-ddump-simpl` will show some unique values. Maybe that's ok. It's mainly use to reduce test- suite wobbles. I'm honestly not sure what to do here, but not too bothered either way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 24 13:02:49 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Nov 2015 13:02:49 -0000 Subject: [GHC] #11014: re-order GHC type errors for clarity In-Reply-To: <047.63b2ee64fbc0e8cf4ea8e84a14f0ce30@haskell.org> References: <047.63b2ee64fbc0e8cf4ea8e84a14f0ce30@haskell.org> Message-ID: <062.1e2c195071dfef8313d959c7e6ab8986@haskell.org> #11014: re-order GHC type errors for clarity -------------------------------------+------------------------------------- Reporter: elaforge | Owner: elaforge Type: feature request | 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 Rev(s): Phab:D1427 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"c05fdddec71f9dc8ebe62d751ccf03367128072a/ghc" c05fddd/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c05fdddec71f9dc8ebe62d751ccf03367128072a" Rearrange error msgs and add section markers (Trac #11014). This puts the "Relevant bindings" section at the end. It uses a TcErrors.Report Monoid to divide messages by importance and then mappends them together. This is not the most efficient way since there are various intermediate Reports and list appends, but it probably doesn't matter since error messages shouldn't get that large, and are usually prepended. In practice, everything is `important` except `relevantBindings`, which is `supplementary`. ErrMsg's errMsgShortDoc and errMsgExtraInfo were extracted into ErrDoc, which has important, context, and suppelementary fields. Each of those three sections is marked with a bullet character, '?' on unicode terminals and '*' on ascii terminals. Since this breaks tons of tests, I also modified testlib.normalise_errmsg to strip out '?'s. --- Additional notes: To avoid prepending * to an empty doc, I needed to filter empty docs. This seemed less error-prone than trying to modify everyone who produces SDoc to instead produce Maybe SDoc. So I added `Outputable.isEmpty`. Unfortunately it needs a DynFlags, which is kind of bogus, but otherwise I think I'd need another Empty case for SDoc, and then it couldn't be a newtype any more. ErrMsg's errMsgShortString is only used by the Show instance, which is in turn only used by Show HscTypes.SourceError, which is in turn only needed for the Exception instance. So it's probably possible to get rid of errMsgShortString, but that would a be an unrelated cleanup. Fixes #11014. Test Plan: see above Reviewers: austin, simonpj, thomie, bgamari Reviewed By: thomie, bgamari Subscribers: simonpj, nomeata, thomie Differential Revision: https://phabricator.haskell.org/D1427 GHC Trac Issues: #11014 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 24 13:02:49 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Nov 2015 13:02:49 -0000 Subject: [GHC] #11000: Implement `-Wcompat` In-Reply-To: <042.320fb0d4d15a64c4acbdb24f3f1efcf0@haskell.org> References: <042.320fb0d4d15a64c4acbdb24f3f1efcf0@haskell.org> Message-ID: <057.5a1fc21366808732e41878b517dbe1a2@haskell.org> #11000: Implement `-Wcompat` -------------------------------------+------------------------------------- Reporter: hvr | Owner: quchen Type: feature request | Status: patch Priority: high | 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:D1495 Wiki Page: Design/Warnings | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"6d147939628c8503d682ffbe2985ca435d7a7c1d/ghc" 6d14793/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6d147939628c8503d682ffbe2985ca435d7a7c1d" Add -Wcompat warning flag group Reviewers: hvr, austin, thomie, bgamari Reviewed By: hvr, austin, thomie, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1495 GHC Trac Issues: #11000 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 24 13:57:43 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Nov 2015 13:57:43 -0000 Subject: [GHC] #11000: Implement `-Wcompat` In-Reply-To: <042.320fb0d4d15a64c4acbdb24f3f1efcf0@haskell.org> References: <042.320fb0d4d15a64c4acbdb24f3f1efcf0@haskell.org> Message-ID: <057.b439b866f4747b878a4fdd643ff7365a@haskell.org> #11000: Implement `-Wcompat` -------------------------------------+------------------------------------- Reporter: hvr | Owner: quchen Type: feature request | Status: closed Priority: high | 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: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1495 Wiki Page: Design/Warnings | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: This has been merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 24 13:58:15 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Nov 2015 13:58:15 -0000 Subject: [GHC] #11014: re-order GHC type errors for clarity In-Reply-To: <047.63b2ee64fbc0e8cf4ea8e84a14f0ce30@haskell.org> References: <047.63b2ee64fbc0e8cf4ea8e84a14f0ce30@haskell.org> Message-ID: <062.99dbd9b4203329112f6f4c4a8dd6e093@haskell.org> #11014: re-order GHC type errors for clarity -------------------------------------+------------------------------------- Reporter: elaforge | Owner: elaforge Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1427 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: This has been merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 24 14:18:53 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Nov 2015 14:18:53 -0000 Subject: [GHC] #10483: Refactor HsForAllTy In-Reply-To: <046.9d853f4d4b58831f7571afd11de45120@haskell.org> References: <046.9d853f4d4b58831f7571afd11de45120@haskell.org> Message-ID: <061.85addaad63ac8ded6b83d904814de067@haskell.org> #10483: Refactor HsForAllTy -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | 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 Rev(s): Phab:D953 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => wontfix Comment: Abandoned in favour of `wip/spj-wildcard-refactor` and Phab:D1428. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 24 19:14:00 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Nov 2015 19:14:00 -0000 Subject: [GHC] #10382: Template Haskell (non-quasi) quotes should work with stage 1 compiler In-Reply-To: <045.918a9569238e9d04ed4e2e3a730bb569@haskell.org> References: <045.918a9569238e9d04ed4e2e3a730bb569@haskell.org> Message-ID: <060.05157def0a8244d98b2538c9a46c345d@haskell.org> #10382: Template Haskell (non-quasi) quotes should work with stage 1 compiler -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: normal | 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 Rev(s): Phab:D876 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): Reading these options, an alternative comes to mind: what if we just made stage1 another WAY just like prof, etc.? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 24 21:19:49 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Nov 2015 21:19:49 -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.35ed787d0fe6d376c891c4d1f0fc3995@haskell.org> #10726: Upgrade MingW-w64 distributions for windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: task | Status: patch Priority: high | Milestone: 7.10.3 Component: Build System | Version: 7.11 Resolution: | 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 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I'm joining the conversation pretty late here, but how exactly did you know which symbols to export in `Linker.c`? I ask since I'm getting some pretty similar errors to what you've been reporting with different packages. For example, when loading `logfloat` in GHCi HEAD: {{{ $ ghc-stage2 --interactive GHCi, version 7.11.20151123: http://www.haskell.org/ghc/ :? for help > import Data.Number.LogFloat > log1p 1.0 : C:\Users\ryanscot\AppData\Roaming\cabal\x86_64-windows- ghc-7.11.20151123\logfloat-0.13.3.3-4JZYNCXKwghOD60rvMUAcn\HSlogfloat-0.13.3.3-4JZYNCXKwghOD60rvMUAcn.o: unknown symbol `log1p' ghc-stage2.exe: unable to load package `logfloat-0.13.3.3' }}} And when loading `sdl2` in GHCi HEAD: {{{ $ ghc-stage2 --interactive GHCi, version 7.11.20151123: http://www.haskell.org/ghc/ :? for help > import SDL > ticks GHC runtime linker: fatal error: I found a duplicate definition for symbol wmain whilst processing object file C:/Users/ryanscot/Documents/Software/ghc/inplace/mingw/bin/../lib/gcc/x86_64-w64-mingw32/5.2.0/../../../../x86_64-w64-mingw32/lib/../lib/libmingw32.a This could be caused by: * Loading two different object files which export the same symbol * Specifying the same object file twice on the GHCi command line * An incorrect `package.conf' entry, causing some object to be loaded twice. ghc-stage2.exe: panic! (the 'impossible' happened) (GHC version 7.11.20151123 for x86_64-unknown-mingw32): loadArchive "C:/Users/ryanscot/Documents/Software/ghc/inplace/mingw/bin/../lib/gcc/x86_64-w64-mingw32/5.2.0/../../../../x86_64-w64-mingw32/lib/../lib/libmingw32.a": failed Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Is this because `libmingw32`/`libmingwex` aren't being linked against when building GHC? Also, how can I figure out which symbols to reexport as a temporary fix? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 24 21:21:28 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Nov 2015 21:21:28 -0000 Subject: [GHC] #11123: Arm: checkProddableBlock: invalid fixup in runtime linker In-Reply-To: <044.92e8587d5182968d745cf903b273dfec@haskell.org> References: <044.92e8587d5182968d745cf903b273dfec@haskell.org> Message-ID: <059.b0237b5056e8f848498388a38e4299f4@haskell.org> #11123: Arm: checkProddableBlock: invalid fixup in runtime linker ----------------------------------------+----------------------------- 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: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+----------------------------- Comment (by erikd): From IRC: {{{ erikd: re your linker issue, perhaps getSectionKind_ELF fails to recognize that section as proddable - the printouts mention sections of kind 3 (afaict that's "other"), and "other" sections aren't marked as proddable in ocGetNames_ELF }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 24 21:33:06 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Nov 2015 21:33:06 -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.104fd2dcd2368ec6df8593669b77e745@haskell.org> #10726: Upgrade MingW-w64 distributions for windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: task | Status: patch Priority: high | Milestone: 7.10.3 Component: Build System | Version: 7.11 Resolution: | 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 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): @Lukexi thanks, I'll put the patch up soon. @RyanGIScott hmm can you add -v to the first one and paste the output again? For the second one, I think `libmingw32` has a main function of its own. Try adding `-no-hs-main` but that might be broken based on #2459 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 24 21:48:40 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Nov 2015 21:48:40 -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.8e333e314b92b9b033b4ffe664017a3d@haskell.org> #10726: Upgrade MingW-w64 distributions for windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: task | Status: patch Priority: high | Milestone: 7.10.3 Component: Build System | Version: 7.11 Resolution: | 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 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * Attachment "logfloat_output.txt" added. runghc -v LogFloat.hs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 24 21:49:12 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Nov 2015 21:49: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.1d2ada65c1fd822de23b90402834e22b@haskell.org> #10726: Upgrade MingW-w64 distributions for windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: task | Status: patch Priority: high | Milestone: 7.10.3 Component: Build System | Version: 7.11 Resolution: | 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 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * Attachment "audioexample_output.txt" added. runghc -v -no-hs-main AudioExample.hs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 24 21:53:25 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Nov 2015 21:53:25 -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.8085cf284eec43b479d328cdd44b3e10@haskell.org> #10726: Upgrade MingW-w64 distributions for windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: task | Status: patch Priority: high | Milestone: 7.10.3 Component: Build System | Version: 7.11 Resolution: | 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 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I've attached the results of invoking `runghc -v` on two different files. `LogFloat.hs` is this: {{{#!hs module Main (main) where import Data.Number.LogFloat (log1p) main :: IO () main = print $ log1p 1.0 }}} `AudioExample.hs` is [https://github.com/haskell- game/sdl2/blob/69156dd7b5aad421d70096a47defe02ec3c24688/examples/AudioExample.hs this file], just with the module name `Main` instead of `AudioExample`. Adding `-no-hs-main` didn't appear to change the error message. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 24 22:24:42 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Nov 2015 22:24:42 -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.d982da38d0acabf636f73a8f83b92af9@haskell.org> #10726: Upgrade MingW-w64 distributions for windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: task | Status: patch Priority: high | Milestone: 7.10.3 Component: Build System | Version: 7.11 Resolution: | 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 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): @RyanGIScott The first one is indeed because you can't like against `libmingwex` {{{ $ dlltool.exe --output-def libmingwex.def --export-all-symbols libmingwex.a $ grep "log1p" libmingwex.def log1p @ 494 log1pf @ 495 log1pl @ 496 }}} So re-exporting `log1p` should fix it. But this feels like a moving target. Try adding `SymI_HasProto(log1p)` to the list. If you're on `HEAD`, these symbols have been moved to `RtsSymbols.c`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 24 22:59:42 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Nov 2015 22:59:42 -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.fc16720fe33bb7d377486ba39976ecd6@haskell.org> #10726: Upgrade MingW-w64 distributions for windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: task | Status: patch Priority: high | Milestone: 7.10.3 Component: Build System | Version: 7.11 Resolution: | 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 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): I'm currently trying to track down an issue in `HEAD` so I can't test this myself atm, but @RyanGIScott can you try something for me, since you're linking against `libm.a` try just adding `-lmsvcr120` and see if that links. You may have an older version of the library so check the output of `dir c:\Windows\System32\msvcr*.dll`. This should work since `libm.a` is a stub just to satisfy linking because the symbols are In the Microsoft runtime. @Lukexi instead of re-exporting the symbols, try using the stock `RC3`, can you rebuild your C parts with `-D__USE_MINGW_ANSI_STDIO=0`. This will make `MingW-w64` drop the `__mingw` prefixes and then the symbols should be found in the `msvcr*.dll` as well. So then you can just link against that as well. This could be a workaround if the patch doesn't make it in `7.10.3`. I haven't gotten any response to whether it would. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 24 23:22:43 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Nov 2015 23:22:43 -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.22d1650fa71796efe5bf49e21c77b57f@haskell.org> #10726: Upgrade MingW-w64 distributions for windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: task | Status: patch Priority: high | Milestone: 7.10.3 Component: Build System | Version: 7.11 Resolution: | 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 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Wow, I ran `runghc -lmsvcr120 LogFloat.hs` and it works perfectly. It turns out there's another quirk: if I go to the `logfloat` source and run `ghc-stage2 --interactive -isrc src/Data/Number/LogFloat.hs`, I can then invoke `log1p 1.0` without any linker issues. If I run `cabal repl` instead and then call `log1p 1.0`, it can't find the `log1p` symbol. Hm. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 24 23:33:23 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Nov 2015 23:33: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.67beedc133aabfe89c1289be2dee0587@haskell.org> #10726: Upgrade MingW-w64 distributions for windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: task | Status: patch Priority: high | Milestone: 7.10.3 Component: Build System | Version: 7.11 Resolution: | 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 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): LogFloat seems to have a fallback method to a less accurate version depending on if FFI is used: {{{ #ifdef __USE_FFI__ foreign import ccall unsafe "math.h log1p" log1p :: Double -> Double #else -- See statistics:Statistics.Math for a more accurate Haskell -- implementation. log1p :: Double -> Double {-# INLINE [0] log1p #-} log1p x = log (1 + x) #endif }}} `__USE_FFI__` is set in the cabal file but of course won't be set using `--interactive`. Adding `-D__USE_FFI__` to the command should trigger the same error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 24 23:39:45 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Nov 2015 23:39:45 -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.344f6e98702c3815d459323c8da39ece@haskell.org> #9832: Get rid of PERL dependency of `ghc-split` ---------------------------------+---------------------------------------- Reporter: hvr | Owner: Phyx- Type: task | Status: new Priority: high | Milestone: 8.0.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 Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by mfdyck.google): So now as #8405 is closed, is this obsolete? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 24 23:44:40 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Nov 2015 23:44:40 -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.898c4f2a3d5dbb6af3c498db66896d8f@haskell.org> #9832: Get rid of PERL dependency of `ghc-split` ---------------------------------+---------------------------------------- Reporter: hvr | Owner: Phyx- Type: task | Status: new Priority: high | Milestone: 8.0.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 Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by Phyx-): As I understood `--gc-sections` doesn't currently work on Windows due to a binutils bug. So we can't actually use it yet. Also I'm not sure the linker script issue has been solved, it's just been turned off because `--gc-sections` doesn't work anyway. So the PERL script is still there AFAIK, afterwards this issue can probably be about actually removing the script and perl bindist? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 25 00:19:24 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Nov 2015 00:19:24 -0000 Subject: [GHC] #10952: Use IPids instead of package keys in HPC tix files In-Reply-To: <046.2961695834220c5d8e713a72077c82af@haskell.org> References: <046.2961695834220c5d8e713a72077c82af@haskell.org> Message-ID: <061.a0fd9e599549c580d319ba634f6e1b0f@haskell.org> #10952: Use IPids instead of package keys in HPC tix files -------------------------------------+------------------------------------- Reporter: mgsloan | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Code Coverage | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mgsloan): ezyang: Thanks for the infos! It's fine if it doesn't directly solve the problem, as long as there's enough information to be able to munge the resulting tix files in reasonable ways. As is, we can't really tell which package a particular tix entry refers to unless we know about the specific package key it uses. @Feuerbach: Yes, that's a rather unfortunate Cabal bug - https://github.com/haskell/cabal/issues/2870 - which is fixed in the development version. I don't think stack can do anything about it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 25 03:27:52 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Nov 2015 03:27:52 -0000 Subject: [GHC] #11069: :cd in GHCi unloads modules In-Reply-To: <046.f148df7c02b3f284ee9bbb87ae5f7b67@haskell.org> References: <046.f148df7c02b3f284ee9bbb87ae5f7b67@haskell.org> Message-ID: <061.ff3a633343768ebfae395da5e84f9866@haskell.org> #11069: :cd in GHCi unloads modules -------------------------------------+------------------------------------- Reporter: mgsloan | Owner: Type: bug | Status: new Priority: low | Milestone: Component: GHCi | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mgsloan): My understanding is that it's unloading the objects because relative paths are being used within GHC. [https://ghc.haskell.org/trac/ghc/ticket/2973 This issue] seems relevant, but Simon's commit message "we should virtualise the CWD inside the GHC API, not in the client" suggests to me that we'd prefer that GHC not care about CWD. To me, the ideal resolution is to use absolute paths within GHC, but perhaps this is a tall order. For example, `:load` would convert relative paths to absolute. Then, modules don't need to be unloaded for `:cd` to work. An alternative solution for my particular case would be to have `:cd` not unload the modules if all of the search paths are absolute. This is the case when ghci is run by `stack ghci`, and probably when it's run by `cabal repl` as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 25 09:43:21 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Nov 2015 09:43:21 -0000 Subject: [GHC] #11028: Refactor ConDecl In-Reply-To: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> References: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> Message-ID: <061.cc7c504d667f31c5ac696533b625eb52@haskell.org> #11028: Refactor ConDecl -------------------------------------+------------------------------------- Reporter: simonpj | Owner: alanz 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alanz): `tcConDecl` returns a `DataCon`. For `ConDeclGADT`, should I bring in a function {{{#!hs gadtDeclDetails :: LHsSigType name -> HsConDeclDetails name gadtDeclDetails (HsIB {hsib_body = lbody_ty}) = details where (tvs, cxt, tau) = splitLHsSigmaTy lbody_ty details -- See Note [Sorting out the result type] = case tau of L _ (HsFunTy (L l (HsRecTy flds)) res_ty) -> RecCon (L l flds) _other -> PrefixCon [] }}} and then proceed with the process as it is now? Should there be a call to `tcHsSigType`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 25 10:12:54 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Nov 2015 10:12:54 -0000 Subject: [GHC] #11130: GHCi should not defer typed holes Message-ID: <045.84e51b5d00d3a4acd23d3673c087a32a@haskell.org> #11130: GHCi should not defer typed holes -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: ghci/scripts/T10248 | Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In the function `tcUserStmt` in compiler/typecheck/TcRnDriver.hs, before going over the different ways ('plans') to lift an expression typed at the prompt into the GHCi monad, `Opt_DeferTypeErrors` is disabled. Here is the accompanying comment: {{{ -- Ensure that type errors don't get deferred when type checking the -- naked expression. Deferring type errors here is unhelpful because the -- expression gets evaluated right away anyway. It also would potentially -- emit redundant type-error warnings, one from each plan. ; plan <- unsetGOptM Opt_DeferTypeErrors $ }}} Since `Opt_DeferTypeErrors` implies `Opt_DeferTypedHoles`, `Opt_DeferTypedHoles` should be disabled here as well. This will improve the error message for T10248. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 25 10:13:06 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Nov 2015 10:13:06 -0000 Subject: [GHC] #11130: GHCi should not defer typed holes In-Reply-To: <045.84e51b5d00d3a4acd23d3673c087a32a@haskell.org> References: <045.84e51b5d00d3a4acd23d3673c087a32a@haskell.org> Message-ID: <060.12c674e67cd0581b1c9f3c5dab776622@haskell.org> #11130: GHCi should not defer typed holes -------------------------------------+------------------------------------- Reporter: thomie | Owner: thomie Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | ghci/scripts/T10248 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * owner: => thomie -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 25 10:52:17 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Nov 2015 10:52:17 -0000 Subject: [GHC] #11130: GHCi should not defer typed holes In-Reply-To: <045.84e51b5d00d3a4acd23d3673c087a32a@haskell.org> References: <045.84e51b5d00d3a4acd23d3673c087a32a@haskell.org> Message-ID: <060.3a0f857be4a567d5551f44d3b104f2aa@haskell.org> #11130: GHCi should not defer typed holes -------------------------------------+------------------------------------- Reporter: thomie | Owner: thomie Type: bug | 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: Incorrect | Test Case: warning at compile-time | ghci/scripts/T10248 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1527 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch * differential: => Phab:D1527 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 25 10:55:01 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Nov 2015 10:55:01 -0000 Subject: [GHC] #10249: GHCi leaky abstraction: error message mentions `ghciStepIO` In-Reply-To: <051.818ff8bc84030bedfa7f9663d4a7c3ef@haskell.org> References: <051.818ff8bc84030bedfa7f9663d4a7c3ef@haskell.org> Message-ID: <066.1d475e90140fc2e53ed078618bfcaaa7@haskell.org> #10249: GHCi leaky abstraction: error message mentions `ghciStepIO` -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: thomie Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | ghci/scripts/T10249 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1528 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * owner: => thomie * testcase: => ghci/scripts/T10249 * differential: => Phab:D1528 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 25 10:57:12 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Nov 2015 10:57:12 -0000 Subject: [GHC] #10249: GHCi leaky abstraction: error message mentions `ghciStepIO` In-Reply-To: <051.818ff8bc84030bedfa7f9663d4a7c3ef@haskell.org> References: <051.818ff8bc84030bedfa7f9663d4a7c3ef@haskell.org> Message-ID: <066.87a45232e59369145227a0d11c16c6e4@haskell.org> #10249: GHCi leaky abstraction: error message mentions `ghciStepIO` -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: thomie Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | ghci/scripts/T10249 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1527, Wiki Page: | Phab:D1528 -------------------------------------+------------------------------------- Changes (by thomie): * differential: Phab:D1528 => Phab:D1527, Phab:D1528 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 25 10:58:41 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Nov 2015 10:58:41 -0000 Subject: [GHC] #10952: Use IPids instead of package keys in HPC tix files In-Reply-To: <046.2961695834220c5d8e713a72077c82af@haskell.org> References: <046.2961695834220c5d8e713a72077c82af@haskell.org> Message-ID: <061.e1bda85d784a39aaa2ff596664348f31@haskell.org> #10952: Use IPids instead of package keys in HPC tix files -------------------------------------+------------------------------------- Reporter: mgsloan | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Code Coverage | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Feuerbach): Wow thanks Michael, that's great news! Building stack with Cabal HEAD is much easier than patching and building ghc. And I've verified that doing so indeed fixes my problem, so this ticket shouldn't affect me much anymore. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 25 12:18:39 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Nov 2015 12:18:39 -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.7948b0b79f23c83a482a92a78d2715e5@haskell.org> #10751: Implement Phase 1 of MonadFail Proposal (MFP) -------------------------------------+------------------------------------- Reporter: hvr | Owner: quchen Type: task | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | 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:D1248 Wiki Page: | prime:Libraries/Proposals/MonadFail| -------------------------------------+------------------------------------- Changes (by hvr): * wikipage: => prime:Libraries/Proposals/MonadFail -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 25 12:38:58 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Nov 2015 12:38:58 -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.afefe459cf2695a4ad06db52caca0f78@haskell.org> #10365: Implement Semigroup as a superclass of Monoid Proposal (Phase 1) -------------------------------------+------------------------------------- Reporter: gidyn | Owner: quchen 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 Wiki Page: | prime:Libraries/Proposals/SemigroupMonoid| -------------------------------------+------------------------------------- Changes (by hvr): * wikipage: => prime:Libraries/Proposals/SemigroupMonoid Old 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. New description: More details in prime:Libraries/Proposals/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: update wiki page link -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 25 12:46:10 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Nov 2015 12:46:10 -0000 Subject: [GHC] #11131: Eta reduction/expansion loop Message-ID: <046.05a37106a92734e76c568321a42d7017@haskell.org> #11131: Eta reduction/expansion loop -------------------------------------+------------------------------------- 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 Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In the build log for HEAD today you'll see: {{{ WARNING: file compiler\simplCore\SimplCore.hs, line 604 Simplifier bailing out after 10 iterations [148, 4, 4, 4, 4, 4, 4, 4, 4, 4] Size = {terms: 290, types: 237, coercions: 56} }}} when compiling`Data/ByteString/Builder/Prim/Internal/Floating.hs`. There is a loop here: in each simplifier pass we get an eta-expansion and an eta reduction, which cancel each other out. This is bad. Here is the offending snippet of code {{{ ((bindIO @ () @ () ($fStorableDouble_$cpoke (castPtr @ Word8 @ Double op) x) ((\ (ds :: ()) -> (\ (eta_B1 :: State# RealWorld) -> (k `cast` (NTCo:IO[0] <()>_R :: IO () ~R# (State# RealWorld -> (# State# RealWorld, () #)))) eta_B1) `cast` (Sym (NTCo:IO[0] <()>_R) :: (State# RealWorld -> (# State# RealWorld, () #)) ~R# IO ())) `cast` (<()>_R -> NTCo:IO[0] <()>_R ; Sym (NTCo:IO[0] <()>_R) :: (() -> IO ()) ~R# (() -> IO ())))) `cast` (NTCo:IO[0] <()>_R :: IO () ~R# (State# RealWorld -> (# State# RealWorld, () #)))) }}} At this point `k` is in scope with arity 2. Actually its binding is {{{ k :: IO () k = bindIO @ Word64 @ () a_s2As a_s2Au }}} I'm not precisely sure why this goes wrong, but it's very clearly bogus, so I'm opening a ticket to keep track. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 25 12:48:38 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Nov 2015 12:48:38 -0000 Subject: [GHC] #11132: Remove deprecated quasiquote syntax Message-ID: <049.b5cabc5003b189dcfb4647d31724ba19@haskell.org> #11132: Remove deprecated quasiquote syntax -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering 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): Phab:D1530 | Wiki Page: -------------------------------------+------------------------------------- The [$qq| quasiquote syntax has been deprecated since around 2010. I counted 216 uses of it on hackage in a handful of packages, some in comments. http://lpaste.net/145938 Here is the commit which deprecated it - https://github.com/ghc/ghc/commit/9ba922ee06b048774d7a82964867ff768a78126e Mailing list thread - https://mail.haskell.org/pipermail/ghc- devs/2015-November/010573.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 25 13:03:15 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Nov 2015 13:03:15 -0000 Subject: [GHC] #11133: Misaligned stack leads to dynamic linker crash Message-ID: <047.8155bb9438e714745077aa2a988b27de@haskell.org> #11133: Misaligned stack leads to dynamic linker crash --------------------------------------+---------------------------------- Reporter: trippels | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------------- {{{ Running programs compiled with ghc leads to a crash of the glibc dynamic linker. This happens because ghc doesn't align the stack correctly during lazy symbol resolution. Example: markus at x4 glibc-build % gdb --args /var/tmp/glibc-build/elf/ld- linux-x86-64.so.2 /home/markus/bin/xmonad Reading symbols from /var/tmp/glibc-build/elf/ld-linux-x86-64.so.2...done. (gdb) run Starting program: /var/tmp/glibc-build/elf/ld-linux-x86-64.so.2 /home/markus/bin/xmonad [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. _dl_lookup_symbol_x (undef_name=0x7ffff75cb3c5 "__gmpn_invert_limb", undef_map=0x7ffff76494d0, ref=ref at entry=0x7fffffffa170, symbol_scope=0x7ffff7649828, version=0x0, type_class=type_class at entry=1, flags=1, skip_map=0x0) at dl- lookup.c:809 809 struct sym_val current_value = { NULL, NULL }; (gdb) bt #0 _dl_lookup_symbol_x (undef_name=0x7ffff75cb3c5 "__gmpn_invert_limb", undef_map=0x7ffff76494d0, ref=ref at entry=0x7fffffffa170, symbol_scope=0x7ffff7649828, version=0x0, type_class=type_class at entry=1, flags=1, skip_map=0x0) at dl- lookup.c:809 #1 0x0000555555564413 in _dl_fixup (l=, reloc_arg=) at ../elf/dl-runtime.c:111 #2 0x000055555556ce1f in _dl_runtime_resolve_sse () at ../sysdeps/x86_64 /dl-trampoline.h:112 #3 0x00007ffff762093a in __gmpn_divrem_1 () from /usr/lib/libgmp.so.10 #4 0xee6b280000000000 in ?? () #5 0x00007ffff6b0b138 in ?? () #6 0x00007ffff6b057d0 in ?? () #7 0x00000000ffffffe2 in ?? () #8 0x00007ffff6b057b8 in ?? () #9 0x00007ffff6b051b0 in ?? () #10 0x00007ffff6b0b1b0 in ?? () #11 0x00000000006b47d8 in ?? () #12 0x00000000006142a9 in ?? () #13 0x0000000000000000 in ?? () (gdb) disass Dump of assembler code for function _dl_lookup_symbol_x: ... => 0x000055555555e93a <+154>: movaps %xmm0,-0x80(%rbp) The crash happens because the incoming stack alignment is wrong: rax 0xffffffff 4294967295 rbx 0x7ffff763c360 140737343898464 rcx 0x7ffff75cb3d7 140737343435735 rdx 0x0 0 rsi 0x33f9b936d4fb49a0 3745228210287888800 rdi 0x7ffff75cb3c5 140737343435717 rbp 0x7fffffffa148 0x7fffffffa148 rsp 0x7fffffffa058 0x7fffffffa058 r8 0x0 0 r9 0x1 1 r10 0x7ffff76494d0 140737343952080 r11 0x7ffff7620840 140737343785024 r12 0x0 0 r13 0x0 0 r14 0x7ffff76494d0 140737343952080 r15 0x7fffffffa170 140737488331120 rip 0x55555555e93a 0x55555555e93a <_dl_lookup_symbol_x+154> eflags 0x10246 [ PF ZF IF RF ] cs 0x33 51 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 0000000000001470 <_dl_lookup_symbol_x>: 1470: 55 push %rbp 1471: 48 89 e5 mov %rsp,%rbp 1474: 41 57 push %r15 1476: 41 56 push %r14 1478: 41 55 push %r13 147a: 41 54 push %r12 147c: 49 89 d5 mov %rdx,%r13 147f: 53 push %rbx 1480: 49 89 f7 mov %rsi,%r15 1483: 4d 89 c6 mov %r8,%r14 1486: 48 81 ec a8 00 00 00 sub $0xa8,%rsp 148d: 0f b6 17 movzbl (%rdi),%edx 1490: 48 89 bd 68 ff ff ff mov %rdi,-0x98(%rbp) 1497: 48 89 8d 50 ff ff ff mov %rcx,-0xb0(%rbp) 149e: 44 89 8d 5c ff ff ff mov %r9d,-0xa4(%rbp) 14a5: 4c 8b 65 18 mov 0x18(%rbp),%r12 14a9: 84 d2 test %dl,%dl 14ab: 0f 84 cb 02 00 00 je 177c <_dl_lookup_symbol_x+0x30c> 14b1: 48 89 f9 mov %rdi,%rcx 14b4: b8 05 15 00 00 mov $0x1505,%eax 14b9: 0f 1f 80 00 00 00 00 nopl 0x0(%rax) 14c0: 48 89 c6 mov %rax,%rsi 14c3: 48 83 c1 01 add $0x1,%rcx 14c7: 48 c1 e6 05 shl $0x5,%rsi 14cb: 48 01 f0 add %rsi,%rax 14ce: 48 01 d0 add %rdx,%rax 14d1: 0f b6 11 movzbl (%rcx),%edx 14d4: 84 d2 test %dl,%dl 14d6: 75 e8 jne 14c0 <_dl_lookup_symbol_x+0x50> 14d8: 89 c0 mov %eax,%eax 14da: 48 89 85 60 ff ff ff mov %rax,-0xa0(%rbp) 14e1: 66 0f ef c0 pxor %xmm0,%xmm0 14e5: b8 ff ff ff ff mov $0xffffffff,%eax 14ea: 4d 85 f6 test %r14,%r14 14ed: 48 89 85 78 ff ff ff mov %rax,-0x88(%rbp) => 14f4: 0f 29 45 80 movaps %xmm0,-0x80(%rbp) (0x7fffffffa058 + 0xa8) % 16 == 0 (instead of the correct 8) Please see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68537 for further info. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 25 13:06:32 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Nov 2015 13:06:32 -0000 Subject: [GHC] #11028: Refactor ConDecl In-Reply-To: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> References: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> Message-ID: <061.16ee1c8fc76877b64cf016d03fb13b39@haskell.org> #11028: Refactor ConDecl -------------------------------------+------------------------------------- Reporter: simonpj | Owner: alanz 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes, because of the possibility of `HsRecTy`, you can't use `tcHsSigType`. So something like what you propose looks good. Ca you make a branch and push what you have so that I can see? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 25 13:45:53 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Nov 2015 13:45:53 -0000 Subject: [GHC] #11134: Limit frequency of idle GCs Message-ID: <047.b7adbd5e9207ae18bb8e48502cfb8e5f@haskell.org> #11134: Limit frequency of idle GCs -------------------------------------+------------------------------------- Reporter: dcturner | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Runtime | Version: 7.10.2 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In a server process with a relatively large heap (100s of MB) serving regular but relatively infrequent requests (~1 per sec) the idle GC runs after essentially every request which turns out to be extremely expensive: switching it off takes us from ~30% CPU to ~0.3% CPU. It is certainly useful have the GC run when idle but running it *every* time the process goes idle isn't necessary. It doesn't work to increase the delay (e.g. say -I2) as then the idle GC would never run, because the requests are rather regular. I'd quite like to be able to say something of the form "do a GC if idle for at least 0.3s as long as the idle GC has not run in the last 120s" - where 120s is another option passed to the RTS. Does this sound like a reasonable idea? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 25 14:11:59 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Nov 2015 14:11:59 -0000 Subject: [GHC] #11028: Refactor ConDecl In-Reply-To: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> References: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> Message-ID: <061.40386c705ef44afdeaf1b7af741df933@haskell.org> #11028: Refactor ConDecl -------------------------------------+------------------------------------- Reporter: simonpj | Owner: alanz 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alanz): I just pushed an update to ` wip/T11028` It now compiles for stage1. Only. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 25 14:55:39 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Nov 2015 14:55:39 -0000 Subject: [GHC] #11014: re-order GHC type errors for clarity In-Reply-To: <047.63b2ee64fbc0e8cf4ea8e84a14f0ce30@haskell.org> References: <047.63b2ee64fbc0e8cf4ea8e84a14f0ce30@haskell.org> Message-ID: <062.448d83a6704e408f9474d89891157087@haskell.org> #11014: re-order GHC type errors for clarity -------------------------------------+------------------------------------- Reporter: elaforge | Owner: elaforge Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1427 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Evan, thank you for doing this. I think it's a step forward. I failed to review your patch in a timely way, but I've now had a quick look. Some questions * The Monoid instance of `Report` is suspicious. Do you ''really'' merge two separate reports, combining their important and relevant-bindings stuff? Of course not! Rather, you use it exclusively to combine a degenerate report with only 'important' stuff and another degenerate report with only 'supplementary' stuff. This seems confusing and indirect. Instead of {{{ let report = important given_msg `mappend` relevant_bindings binds_msg }}} why not say {{{ let report = mkReport given_msg binds_msg }}} and drop the suspicious Monoid instance. * It will not have escaped your attention that `TcErrors.Report` and `ErrUtils.ErrDoc` are virtually identical. Could you perhaps just combine them? To get the `errDocContext` you could either (I suppose) start with it empty, and add it; or make `mkReport` monadic (better probably). * I'd love you to do as you suggest and get rid of `errMsgShortString`. * Are you sure you need to filter out empty docs? Can't you just avoid putting empty docs into the [SDoc] in the first place? Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 25 14:56:57 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Nov 2015 14:56:57 -0000 Subject: [GHC] #11014: re-order GHC type errors for clarity In-Reply-To: <047.63b2ee64fbc0e8cf4ea8e84a14f0ce30@haskell.org> References: <047.63b2ee64fbc0e8cf4ea8e84a14f0ce30@haskell.org> Message-ID: <062.6dbb00aa318ec1ebbe545b004573e1b1@haskell.org> #11014: re-order GHC type errors for clarity -------------------------------------+------------------------------------- Reporter: elaforge | Owner: Type: feature request | 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 Rev(s): Phab:D1427 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: closed => new * owner: elaforge => * resolution: fixed => Comment: PS: I'll re-open to track progress -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 25 16:22:09 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Nov 2015 16:22:09 -0000 Subject: [GHC] #11024: Fix strange parsing of BooleanFormula In-Reply-To: <049.1026878f17212bef28601e22c8ebf782@haskell.org> References: <049.1026878f17212bef28601e22c8ebf782@haskell.org> Message-ID: <064.5f7b8484071e26577f6be9af3b8a6bf8@haskell.org> #11024: Fix strange parsing of BooleanFormula -------------------------------------+------------------------------------- Reporter: mpickering | Owner: bollu Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bollu): * owner: => bollu -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 25 16:30:31 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Nov 2015 16:30:31 -0000 Subject: [GHC] #11105: Put the generic-default type in the Class In-Reply-To: <046.c36ed1c92d97e0f8dc99e08834c73406@haskell.org> References: <046.c36ed1c92d97e0f8dc99e08834c73406@haskell.org> Message-ID: <061.1714ce44a54d830f134916e3d09853db@haskell.org> #11105: Put the generic-default type in the Class -------------------------------------+------------------------------------- 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"924f851700ca9ba7e0e7483b7ca4de62a4a74e15/ghc" 924f8517/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="924f851700ca9ba7e0e7483b7ca4de62a4a74e15" Refactor default methods (Trac #11105) This patch does some signficant refactoring to the treatment of default methods in class declarations, and more generally to the type checking of type/class decls. Highlights: * When the class has a generic-default method, such as class C a where op :: a -> a -> Bool default op :: Ord a => a -> a -> a the ClassOpItem records the type of the generic-default, in this case the type (Ord a => a -> a -> a) * I killed off Class.DefMeth in favour of the very-similar BasicTypes.DefMethSpec. However it turned out to be better to use a Maybe, thus Maybe (DefMethSpec Type) with Nothing meaning "no default method". * In TcTyClsDecls.tcTyClGroup, we used to accumulate a [TyThing], but I found a way to make it much simpler, accumulating only a [TyCon]. Much less wrapping and unwrapping. * On the way I also fixed Trac #10896 in a better way. Instead of killing off all ambiguity checks whenever there are any type errors (the fix in commit 8e8b9ed), I instead recover in TcTyClsDecls.checkValidTyCl. There was a lot of associated simplification all round }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 25 16:30:31 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Nov 2015 16:30:31 -0000 Subject: [GHC] #10896: BadSock triggers failing ASSERT In-Reply-To: <045.e2606f0aace406a963850215a356a8ed@haskell.org> References: <045.e2606f0aace406a963850215a356a8ed@haskell.org> Message-ID: <060.76aae38d76609bd9a600e3c5fd278cee@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 Rev(s): Phab:D1260 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"924f851700ca9ba7e0e7483b7ca4de62a4a74e15/ghc" 924f8517/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="924f851700ca9ba7e0e7483b7ca4de62a4a74e15" Refactor default methods (Trac #11105) This patch does some signficant refactoring to the treatment of default methods in class declarations, and more generally to the type checking of type/class decls. Highlights: * When the class has a generic-default method, such as class C a where op :: a -> a -> Bool default op :: Ord a => a -> a -> a the ClassOpItem records the type of the generic-default, in this case the type (Ord a => a -> a -> a) * I killed off Class.DefMeth in favour of the very-similar BasicTypes.DefMethSpec. However it turned out to be better to use a Maybe, thus Maybe (DefMethSpec Type) with Nothing meaning "no default method". * In TcTyClsDecls.tcTyClGroup, we used to accumulate a [TyThing], but I found a way to make it much simpler, accumulating only a [TyCon]. Much less wrapping and unwrapping. * On the way I also fixed Trac #10896 in a better way. Instead of killing off all ambiguity checks whenever there are any type errors (the fix in commit 8e8b9ed), I instead recover in TcTyClsDecls.checkValidTyCl. There was a lot of associated simplification all round }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 25 16:31:13 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Nov 2015 16:31:13 -0000 Subject: [GHC] #11105: Put the generic-default type in the Class In-Reply-To: <046.c36ed1c92d97e0f8dc99e08834c73406@haskell.org> References: <046.c36ed1c92d97e0f8dc99e08834c73406@haskell.org> Message-ID: <061.3f5c6ceb402d844b8c4d48282d7da314@haskell.org> #11105: Put the generic-default type in the Class -------------------------------------+------------------------------------- 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 25 16:54:15 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Nov 2015 16:54:15 -0000 Subject: [GHC] #11121: Introduce `-XTemplateHaskellQuotes` pragma for subset of TH In-Reply-To: <042.c278176d2dd239200103849cc54d10cc@haskell.org> References: <042.c278176d2dd239200103849cc54d10cc@haskell.org> Message-ID: <057.0b205892ba8b228a1814f7391f67017d@haskell.org> #11121: Introduce `-XTemplateHaskellQuotes` pragma for subset of TH -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: patch 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: #10382, #11102 | Differential Rev(s): Phab:D1511 Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * status: new => patch Old description: > TODO: describe why we need this New description: Cabal needs to be able to detect whether a full or partial TemplateHaskell implementation is available. However, if `-XTemplateHaskell` has no clear meaning we can't properly specify which language extensions a package requires nor make accurate decisions based on the availability of compiler features. Moreover, the quotation subset of TemplateHaskell seems to be SafeHaskell compatible, so it makes sense to split it off into a sub-extension. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 25 17:14:21 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Nov 2015 17:14:21 -0000 Subject: [GHC] #11133: Misaligned stack leads to dynamic linker crash In-Reply-To: <047.8155bb9438e714745077aa2a988b27de@haskell.org> References: <047.8155bb9438e714745077aa2a988b27de@haskell.org> Message-ID: <062.5fd33d25492f79e50187ec98914220a8@haskell.org> #11133: Misaligned stack leads to dynamic linker crash ----------------------------------+-------------------------------------- Reporter: trippels | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: invalid | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Changes (by trippels): * status: new => closed * resolution: => invalid Comment: It turned out to be a GMP bug. From the GMP 6.1.0 release notes: Fixed ABI incompatible stack alignment in calls from assembly code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 25 19:39:15 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Nov 2015 19:39:15 -0000 Subject: [GHC] #11135: Migrate more of Data.Functor.* from transformers to base. Message-ID: <042.83233f22e5175dafd0dee94fc12c4d5f@haskell.org> #11135: Migrate more of Data.Functor.* from transformers to base. -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: highest | Milestone: 8.0.1 Component: | Version: 7.10.2 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This was proposed in https://mail.haskell.org/pipermail/libraries/2015-July/026014.html Edward says the following modules are up for migration: - `Data.Functor.Classes` - `Data.Functor.Product` - `Data.Functor.Sum` - `Data.Functor.Compose` related/optionally/undecided: - `Data.Functor.Reverse` - `Control.Applicative.Backwards` not moved because redundant (c.f. `Const`): - `Data.Functor.Constant` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 25 20:07:33 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Nov 2015 20:07:33 -0000 Subject: [GHC] #11028: Refactor ConDecl In-Reply-To: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> References: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> Message-ID: <061.2547c5ce37416a189bb9dbbc4e4a4e07@haskell.org> #11028: Refactor ConDecl -------------------------------------+------------------------------------- Reporter: simonpj | Owner: alanz 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alanz): Commit https://phabricator.haskell.org/rGHCff2978cac0cd fails with the res_ty not matching, When type checking {{{#!hs data MaybeO ex t where JustO :: t -> MaybeO O t NothingO :: MaybeO C t }}} This code generates. {{{ libraries/hoopl/src/Compiler/Hoopl/Block.hs:66:3: error: ? Data constructor ?JustO? returns type ?t -> MaybeO O t? instead of an instance of its parent type ?MaybeO ex t? ? In the definition of data constructor ?JustO? In the data type declaration for ?MaybeO? }}} I am pretty sure the `res_ty'` variable in [1] should be `MaybeO O t` but it is not clear how this happens in the original code. [1] https://github.com/ghc/ghc/blob/ff2978cac0cd133c2434480e311bed6aea72c6f1/compiler/typecheck/TcTyClsDecls.hs#L1398 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 25 21:10:24 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Nov 2015 21:10:24 -0000 Subject: [GHC] #11133: Misaligned stack leads to dynamic linker crash In-Reply-To: <047.8155bb9438e714745077aa2a988b27de@haskell.org> References: <047.8155bb9438e714745077aa2a988b27de@haskell.org> Message-ID: <062.875d87c5964bb2c87e26783e6cd601ef@haskell.org> #11133: Misaligned stack leads to dynamic linker crash ----------------------------------+-------------------------------------- Reporter: trippels | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: invalid | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Comment (by rwbarton): This kind of report is still super helpful since others may encounter the same issue. Thanks! Do you happen to know whether this GMP bug was introduced in a recent version of GMP? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 25 21:31:17 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Nov 2015 21:31:17 -0000 Subject: [GHC] #11133: Misaligned stack leads to dynamic linker crash In-Reply-To: <047.8155bb9438e714745077aa2a988b27de@haskell.org> References: <047.8155bb9438e714745077aa2a988b27de@haskell.org> Message-ID: <062.ef431d785437a73eea8b37268568b6d5@haskell.org> #11133: Misaligned stack leads to dynamic linker crash ----------------------------------+-------------------------------------- Reporter: trippels | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: invalid | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Comment (by trippels): I assume it was introduced in GMP 6.0.0, that was released in March 2014. Unfortunately they have no public source repository, so one cannot easily double check. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 25 21:37:58 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Nov 2015 21:37:58 -0000 Subject: [GHC] #11133: Misaligned stack leads to dynamic linker crash In-Reply-To: <047.8155bb9438e714745077aa2a988b27de@haskell.org> References: <047.8155bb9438e714745077aa2a988b27de@haskell.org> Message-ID: <062.c6ba733e5dbca8ce885ab6089ae66beb@haskell.org> #11133: Misaligned stack leads to dynamic linker crash ----------------------------------+-------------------------------------- Reporter: trippels | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: invalid | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Comment (by trippels): Oh, it turns out they actually have one. See: https://gmplib.org/repo/gmp/log?rev=stack (the fixes from July 2014) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 25 21:44:52 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Nov 2015 21:44:52 -0000 Subject: [GHC] #11028: Refactor ConDecl In-Reply-To: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> References: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> Message-ID: <061.1ceccf4701e7fa6599a4d2c1a65a1256@haskell.org> #11028: Refactor ConDecl -------------------------------------+------------------------------------- Reporter: simonpj | Owner: alanz 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alanz): Ok, the problem is in `rnConDecl` in the `ConDeclGADT` case, which in this branch simply calls `rnHsSigType`. Instead it should perform as per the original, which splits the result type,leaving it as `MaybeO ex t` in this case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 25 21:56:11 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Nov 2015 21:56:11 -0000 Subject: [GHC] #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation In-Reply-To: <046.e40c84b285c82dadde0ff9ddf8e0c79c@haskell.org> References: <046.e40c84b285c82dadde0ff9ddf8e0c79c@haskell.org> Message-ID: <061.11b71f28c7a9716082b6cffee9262256@haskell.org> #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation -------------------------------+-------------------------------------- Reporter: Doug310 | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: gmp Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Changes (by rwbarton): * keywords: exponentiation => gmp -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 25 22:00:28 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Nov 2015 22:00:28 -0000 Subject: [GHC] #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation In-Reply-To: <046.e40c84b285c82dadde0ff9ddf8e0c79c@haskell.org> References: <046.e40c84b285c82dadde0ff9ddf8e0c79c@haskell.org> Message-ID: <061.673a1cfcc637edae2305585c55dfee25@haskell.org> #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation -------------------------------+-------------------------------------- Reporter: Doug310 | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: gmp Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Comment (by rwbarton): From the GMP 6.1.0 release notes (released November 1): > * Stack usage trimmed; we believe 512 KiB is now sufficient for any GMP call, irrespective of operand size. So, this should indeed not be an issue for GMP 6.1.0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 25 22:01:39 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Nov 2015 22:01:39 -0000 Subject: [GHC] #10382: Template Haskell (non-quasi) quotes should work with stage 1 compiler In-Reply-To: <045.918a9569238e9d04ed4e2e3a730bb569@haskell.org> References: <045.918a9569238e9d04ed4e2e3a730bb569@haskell.org> Message-ID: <060.4970c03289938b0fb86f922f894e5913@haskell.org> #10382: Template Haskell (non-quasi) quotes should work with stage 1 compiler -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: normal | 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 Rev(s): Phab:D876 Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): As far as I can see WAY only effects the arguments passed to GHC, so it doesn't help unless we do some refactoring in the test driver, and the test driver is ... messy. Can we do this with less amount of work by adding a new field to `testglobals.TestOptions`, something like `stage`, and then in `testlib.simple_build()` we check the option and override `compiler` variable? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 25 22:09:40 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Nov 2015 22:09:40 -0000 Subject: [GHC] #11028: Refactor ConDecl In-Reply-To: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> References: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> Message-ID: <061.c5134935c3d8b8d99c343763be9ce671@haskell.org> #11028: Refactor ConDecl -------------------------------------+------------------------------------- Reporter: simonpj | Owner: alanz 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Replying to [comment:22 alanz]: > Ok, the problem is in `rnConDecl` in the `ConDeclGADT` case, which in this branch simply calls `rnHsSigType`. > > Instead it should perform as per the original, which splits the result type,leaving it as `MaybeO ex t` in this case. Wait! Why? What would the difference be in the result of `rnConDecl`? I'm suspicious; I'd like to understand better. An example perhaps? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 25 22:17:25 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Nov 2015 22:17:25 -0000 Subject: [GHC] #11028: Refactor ConDecl In-Reply-To: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> References: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> Message-ID: <061.905341f9fe5867ac821fd284923819af@haskell.org> #11028: Refactor ConDecl -------------------------------------+------------------------------------- Reporter: simonpj | Owner: alanz 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alanz): The key factor is the work currently done in `rnConResult`, {{{#!hs rnConResult doc _con details (ResTyGADT ls ty) = do { (ty', fvs) <- rnLHsType doc ty ; let (arg_tys, res_ty) = splitHsFunType ty' -- We can finally split it up, -- now the renamer has dealt with fixities -- See Note [Sorting out the result type] in RdrHsSyn ; case details of InfixCon {} -> pprPanic "rnConResult" (ppr ty) -- See Note [Sorting out the result type] in RdrHsSyn RecCon {} -> do { unless (null arg_tys) (addErr (badRecResTy doc)) ; return (details, ResTyGADT ls res_ty, fvs) } PrefixCon {} -> return (PrefixCon arg_tys, ResTyGADT ls res_ty, fvs)} }}} `splitHsFunTy` on `t -> MaybeO a b` will return `([t],MaybeO a b)`, and the latter is then returned as the new `res_ty` My understanding is that we are doing this so that the ParsedSource more accurately reflects what was seen, which can simplify the API Annotations work. Perhaps we should add a `PostRn` field to the `ConDeclGADT` to capture the new `details` and `res_ty`. Alternatively, everything except the `rnLHsType` in `rnConResult` can move to the type checking. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 25 22:25:08 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Nov 2015 22:25:08 -0000 Subject: [GHC] #11028: Refactor ConDecl In-Reply-To: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> References: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> Message-ID: <061.a1d23c30ac777cc38efb5045eb9abaaf@haskell.org> #11028: Refactor ConDecl -------------------------------------+------------------------------------- Reporter: simonpj | Owner: alanz 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Alternatively, everything except the `rnLHsType` in `rnConResult` can move to the type checking. That sounds exactly right. `Note [Sorting out the result type]` in `RdrHsSyn` seems entirely redundant with the new `ConDeclGADT` form. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 25 22:40:20 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Nov 2015 22:40:20 -0000 Subject: [GHC] #11067: Spurious superclass cycle error with type equalities In-Reply-To: <045.f5d44ba3aad0bf1ca48ae450e6c33b15@haskell.org> References: <045.f5d44ba3aad0bf1ca48ae450e6c33b15@haskell.org> Message-ID: <060.a4b92a20eb3b2910954e75bad98ec77a@haskell.org> #11067: Spurious superclass cycle error with type equalities -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): See also #10592, #10318. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 25 22:53:32 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Nov 2015 22:53:32 -0000 Subject: [GHC] #11067: Spurious superclass cycle error with type equalities In-Reply-To: <045.f5d44ba3aad0bf1ca48ae450e6c33b15@haskell.org> References: <045.f5d44ba3aad0bf1ca48ae450e6c33b15@haskell.org> Message-ID: <060.19185cba68a9afa78980fdcefb5eb288@haskell.org> #11067: Spurious superclass cycle error with type equalities -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): In your example GHC is being stupidly conservative. Consider the superclasses of `(H1 f g)`: {{{ transitive superclasses of (H1 f g) = (by immediate superclsases of H1) Forall (H f g) = (expand Forall) H f g (Skolem (H f g)) = (superclasses of H) f (Skolem (H f g)) ~ g (Skolem (H f g)) }}} And there the process stops. Once we get to an ''equality'' we can't go further. We do not have an infinite tower of superclasses, and that is statically visible. GHC is probably worried about the occurrences of `H` on the bottom line, but it shouldn't be. That would (probably) be fairly easy to fix. The possibility of type functions in a "superclass" position is more worrying. As you point out, the type function could hide arbitrary recursion and indeed loops could result. I'm strongly inclined to make type function in superclass positions illegal: {{{ class F ty => C a }}} would be illegal if `F` is a type function. However {{{ class D (F ty) => C a }}} would be ok (c.f. #10318). I have yet to see a good reason for a type function in head position, except to work around bugs. Maybe we could allow it with some suitably terrifying-sounding extension. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 25 23:07:22 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Nov 2015 23:07:22 -0000 Subject: [GHC] #11131: Eta reduction/expansion loop In-Reply-To: <046.05a37106a92734e76c568321a42d7017@haskell.org> References: <046.05a37106a92734e76c568321a42d7017@haskell.org> Message-ID: <061.fb0efd7bb7824bbfd04a1eb1b7987b79@haskell.org> #11131: Eta reduction/expansion loop -------------------------------------+------------------------------------- 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > In the build log for HEAD today you'll see: > {{{ > WARNING: file compiler\simplCore\SimplCore.hs, line 604 > Simplifier bailing out after 10 iterations [148, 4, 4, 4, 4, 4, 4, 4, > 4, 4] > Size = {terms: 290, types: 237, coercions: 56} > }}} > when compiling`Data/ByteString/Builder/Prim/Internal/Floating.hs`. > > There is a loop here: in each simplifier pass we get an eta-expansion and > an eta reduction, which cancel each other out. This is bad. > > Here is the offending snippet of code > {{{ > ((bindIO @ () @ () > ($fStorableDouble_$cpoke > (castPtr @ Word8 @ Double op) > x) > ((\ (ds :: ()) -> > (\ (eta_B1 :: State# RealWorld) -> > (k `cast` (NTCo:IO[0] <()>_R > :: IO () > ~R# (State# RealWorld -> (# State# RealWorld, () > #)))) > eta_B1) > `cast` (Sym (NTCo:IO[0] <()>_R) > :: (State# RealWorld -> (# State# RealWorld, () #)) > ~R# IO ())) > `cast` (<()>_R > -> NTCo:IO[0] <()>_R ; Sym (NTCo:IO[0] <()>_R) > :: (() -> IO ()) ~R# (() -> IO ())))) > `cast` (NTCo:IO[0] <()>_R > :: IO () ~R# (State# RealWorld -> (# State# RealWorld, () #)))) > }}} > At this point `k` is in scope with arity 2. Actually its binding is > {{{ > k :: IO () > k = bindIO @ Word64 @ () a_s2As a_s2Au > }}} > I'm not precisely sure why this goes wrong, but it's very clearly bogus, > so I'm opening a ticket to keep track. New description: In the build log for HEAD today you'll see: {{{ WARNING: file compiler\simplCore\SimplCore.hs, line 604 Simplifier bailing out after 10 iterations [148, 4, 4, 4, 4, 4, 4, 4, 4, 4] Size = {terms: 290, types: 237, coercions: 56} }}} when compiling`Data/ByteString/Builder/Prim/Internal/Floating.hs`. There is a loop here: in each simplifier pass we get an eta-expansion and an eta reduction, which cancel each other out. This is bad. Here is the offending snippet of code {{{ ((bindIO @ () @ () ($fStorableDouble_$cpoke (castPtr @ Word8 @ Double op) x) ((\ (ds :: ()) -> (\ (eta_B1 :: State# RealWorld) -> (k `cast` (NTCo:IO[0] <()>_R :: IO () ~R# (State# RealWorld -> (# State# RealWorld, () #)))) eta_B1) `cast` (Sym (NTCo:IO[0] <()>_R) :: (State# RealWorld -> (# State# RealWorld, () #)) ~R# IO ())) `cast` (<()>_R -> NTCo:IO[0] <()>_R ; Sym (NTCo:IO[0] <()>_R) :: (() -> IO ()) ~R# (() -> IO ())))) `cast` (NTCo:IO[0] <()>_R :: IO () ~R# (State# RealWorld -> (# State# RealWorld, () #)))) }}} At this point `k` is in scope with arity 1. Actually its binding is {{{ k :: IO () k = bindIO @ Word64 @ () a_s2As a_s2Au }}} I'm not precisely sure why this goes wrong, but it's very clearly bogus, so I'm opening a ticket to keep track. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 25 23:15:13 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Nov 2015 23:15:13 -0000 Subject: [GHC] #11108: Weak references related crash In-Reply-To: <046.1b25661a2ebf5aa23d3a93aae541239e@haskell.org> References: <046.1b25661a2ebf5aa23d3a93aae541239e@haskell.org> Message-ID: <061.26884f6975a4d68fa593f0067c306b24@haskell.org> #11108: Weak references related crash -------------------------------------+------------------------------------- Reporter: Saulzar | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Given that we have no fix for this I'm simply going to note that in the users guide and pull the trigger on 7.10.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 25 23:21:08 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Nov 2015 23:21:08 -0000 Subject: [GHC] #11108: Weak references related crash In-Reply-To: <046.1b25661a2ebf5aa23d3a93aae541239e@haskell.org> References: <046.1b25661a2ebf5aa23d3a93aae541239e@haskell.org> Message-ID: <061.617ff1628ae9a1836450ec959b3546a3@haskell.org> #11108: Weak references related crash -------------------------------------+------------------------------------- Reporter: Saulzar | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 7.10.3 => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 25 23:32:23 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Nov 2015 23:32:23 -0000 Subject: [GHC] #10639: Tight (non-allocating) loop freezes the scheduler In-Reply-To: <048.3130b8c9dae40d4cc95f52d78c185152@haskell.org> References: <048.3130b8c9dae40d4cc95f52d78c185152@haskell.org> Message-ID: <063.c79f02679267e902aa8e7f86899fdc5a@haskell.org> #10639: Tight (non-allocating) loop freezes the scheduler -------------------------------------+------------------------------------- Reporter: gizmo.mk0 | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1127 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"9aa94586fde73e818e32e5cc0e6420f6ed36a80b/ghc" 9aa94586/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9aa94586fde73e818e32e5cc0e6420f6ed36a80b" Note STM's vulnerability to non-allocating loops Test Plan: Read it Reviewers: austin, fryguybob Reviewed By: austin Subscribers: thomie, fryguybob Differential Revision: https://phabricator.haskell.org/D1523 GHC Trac Issues: #10639, #367 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 25 23:32:23 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Nov 2015 23:32:23 -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.b706cbfc3f082883c858b2af9565ad81@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 Rev(s): -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"9aa94586fde73e818e32e5cc0e6420f6ed36a80b/ghc" 9aa94586/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9aa94586fde73e818e32e5cc0e6420f6ed36a80b" Note STM's vulnerability to non-allocating loops Test Plan: Read it Reviewers: austin, fryguybob Reviewed By: austin Subscribers: thomie, fryguybob Differential Revision: https://phabricator.haskell.org/D1523 GHC Trac Issues: #10639, #367 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 25 23:32:23 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Nov 2015 23:32:23 -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.e2e0307c5f1698cccc3a24d355be783b@haskell.org> #10751: Implement Phase 1 of MonadFail Proposal (MFP) -------------------------------------+------------------------------------- Reporter: hvr | Owner: quchen Type: task | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | 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:D1248 Wiki Page: | prime:Libraries/Proposals/MonadFail| -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"c7a058fb8fa4e9dea55692924b49057d63b2fffd/ghc" c7a058fb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c7a058fb8fa4e9dea55692924b49057d63b2fffd" User's Guide: Add links to MFP wiki page Test Plan: IIAM Reviewers: austin, bgamari, quchen Reviewed By: bgamari, quchen Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1529 GHC Trac Issues: #10751 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 25 23:32:23 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Nov 2015 23:32:23 -0000 Subject: [GHC] #11108: Weak references related crash In-Reply-To: <046.1b25661a2ebf5aa23d3a93aae541239e@haskell.org> References: <046.1b25661a2ebf5aa23d3a93aae541239e@haskell.org> Message-ID: <061.9b296b6b84ee59c1565e03223d3b78a6@haskell.org> #11108: Weak references related crash -------------------------------------+------------------------------------- Reporter: Saulzar | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"d2a2d5ebb08caedcd2a2a7a9e06ed6f4cbba96e7/ghc" d2a2d5e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d2a2d5ebb08caedcd2a2a7a9e06ed6f4cbba96e7" Note #11108 in the bugs section of users guide }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 26 00:00:19 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Nov 2015 00:00:19 -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.e3eac9297f5c77a1c2b3b668a198475a@haskell.org> #10726: Upgrade MingW-w64 distributions for windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: task | Status: patch Priority: high | Milestone: 7.10.3 Component: Build System | Version: 7.11 Resolution: | 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 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Alright, I've applied Luke's patch from comment:48 to `ghc-7.10` as bbbf79b91747dbb5ab284f075927d1e1e27aba95./ This will hopefully serve as a sufficient workaround for 7.10.3, although I do hope we can do better for 8.0. Thanks for the testing, everyone! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 26 00:00:45 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Nov 2015 00:00:45 -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.24846b475c684ab540be3260d69381a5@haskell.org> #10726: Upgrade MingW-w64 distributions for windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: task | Status: patch Priority: high | Milestone: 8.0.1 Component: Build System | Version: 7.11 Resolution: | 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 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 7.10.3 => 8.0.1 Comment: Bumping to 8.0.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 26 00:47:10 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Nov 2015 00:47:10 -0000 Subject: [GHC] #8440: Get rid of the remaining static flags In-Reply-To: <052.744af3e10192bedb98c0b515d9a6cc6d@haskell.org> References: <052.744af3e10192bedb98c0b515d9a6cc6d@haskell.org> Message-ID: <067.79168e16c56a155b056bd35a2eaf7903@haskell.org> #8440: Get rid of the remaining static flags -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: siddhanathan Type: task | Status: new Priority: high | Milestone: 8.0.1 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by siddhanathan): * owner: => siddhanathan -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 26 02:00:07 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Nov 2015 02:00:07 -0000 Subject: [GHC] #10952: Use IPids instead of package keys in HPC tix files In-Reply-To: <046.2961695834220c5d8e713a72077c82af@haskell.org> References: <046.2961695834220c5d8e713a72077c82af@haskell.org> Message-ID: <061.fcf771bcac2bb3ce0ca856ef98756447@haskell.org> #10952: Use IPids instead of package keys in HPC tix files -------------------------------------+------------------------------------- Reporter: mgsloan | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Code Coverage | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mgsloan): @Feuerbach Great! @ezyang Feel free to close this ticket if the changes you describe are sure to be in ghc 8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 26 06:20:16 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Nov 2015 06:20:16 -0000 Subject: [GHC] #11067: Spurious superclass cycle error with type equalities In-Reply-To: <045.f5d44ba3aad0bf1ca48ae450e6c33b15@haskell.org> References: <045.f5d44ba3aad0bf1ca48ae450e6c33b15@haskell.org> Message-ID: <060.f0d9a9300ea01bceaf41e5f4783a704f@haskell.org> #11067: Spurious superclass cycle error with type equalities -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by oerjan): Replying to [comment:8 simonpj]: First, I don't think #10592 and #10318 are that relevant, because there is no ''actual'' infinite recursion involved, it's all terminating. Not that it wouldn't be nice to support true infinite recursion, too, if it were possible. > That would (probably) be fairly easy to fix. Unfortunately this is only a special case of the problem, where I first discovered it. > The possibility of type functions in a "superclass" position is more worrying. As you point out, the type function could hide arbitrary recursion and indeed loops could result. I'm strongly inclined to make type function in superclass positions illegal: > {{{ > class F ty => C a > }}} > would be illegal if `F` is a type function. However > {{{ > class D (F ty) => C a > }}} > would be ok (c.f. #10318). Disallowing this without changing a lot more would kill `Data.Constraint.Forall` (again), because removing all the superclass type functions doesn't currently work either. The problem, as my comment [comment:4] implies, is that even with just `ConstraintKinds` and no type function classes, it is still possible to create terminating recursion: {{{ Monoid2 t => ForallF Monoid1 t => Monoid1 (t (SkolemF Monoid1 t)) => ForallF Monoid (t (SkolemF Monoid1 t)) => Monoid (t (SkolemF Monoid t)) (SkolemF Monoid (t (SkolemF Monoid1 t)))) }}} (modulo errors, my own computer is in for repairs so I cannot test). The only thing that should have to be a type family here is the `SkolemF`, and this works perfectly with `ForallF` as a class, ''except'' for GHC's cycle error. Inserting a type function in the chain currently allows it to work, as in the current `constraints` implementation. > I have yet to see a good reason for a type function in head position, except to work around bugs. Maybe we could allow it with some suitably terrifying-sounding extension. I'm just a hobbyist Haskeller, discussing more than programming, and maybe my mind works differently, but I think type function superclasses may have severely ''underused'' potential. As far as I know, they're the only way to make the superclasses of a class vary "dynamically", in a way that sometimes gives ''much'' better type inference than just putting the constraints on an instance. I can think of twice I've been using type function superclasses for non- buggy reasons: 1. Back in the #9858 discussion, I dabbled with how to express kind-aware `Typeable` in plain GHC 7.8 terms. An associated type function superclass was essential to get reasonable type inference of `Typeable` for the parts of a type or kind. Which in some ways ended up ''more'' flexible than the implementation GHC currently has, thus #10343. 2. I [https://github.com/ekmett/constraints/pull/17 proposed] another addition to `Data.Constraint.Forall`, a varargs convenience class to deal with the awkwardness of quantifying over several type variables simultaneously: {{{ class ForallV' p => ForallV (p :: k) instance ForallV' p => ForallV p type family ForallV' (p :: k) :: Constraint type instance ForallV' (p :: Constraint) = p type instance ForallV' (p :: k -> Constraint) = Forall p type instance ForallV' (p :: k1 -> k2 -> k3) = ForallF ForallV p class InstV (p :: k) c | k c -> p where instV :: ForallV p :- c -- Omitting instances }}} `ForallV` must be a class, otherwise the corresponding `instV` method cannot be type inferred. (Also, it's used as an unapplied argument in the last line, but ''that'' can be got around, I think, by making it more point-free.) `ForallV'` must be a superclass type function, because the implementation is genuinely branching on kind. And `ForallV` is intended to be used for constraints, ''including'' as a superclass. (I suppose ''injective'' families could do everything but the last bit.) ---- It seems to me that the superclass cycle detection works fine ''without'' `ConstraintKinds`, but with it, you immediately run into the problem: The superclass cycle detection seems to be designed on the assumption: "a class is used twice in a superclass chain" and "the superclass chain doesn't terminate" are equivalent. With `ConstraintKinds`, this assumption ''fails'', spectacularly. Type families exacerbate this problem, by making it much easier to express (and want to express) genuine terminating recursion of types, but they do ''not'' fundamentally cause it. I don't understand why a superclass "cycle" should not be handled in exactly the same way as ordinary instance lookup, as far as termination is concerned. `UndecidableInstances` could work analogously with both, by only triggering an error when there is an actual, ''certain'' blowup. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 26 08:52:13 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Nov 2015 08:52:13 -0000 Subject: [GHC] #11028: Refactor ConDecl In-Reply-To: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> References: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> Message-ID: <061.aa0768a19c4303c1ceef27f73c1d2b46@haskell.org> #11028: Refactor ConDecl -------------------------------------+------------------------------------- Reporter: simonpj | Owner: alanz 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alanz): The current error is {{{ compiler/cmm/CmmNode.hs:88:20: error: Record syntax is illegal here: {cml_pred :: CmmExpr, cml_true, cml_false :: {-# UNPACK #-} !Label, cml_likely :: Maybe Bool} }}} which is a record style GADT constructor declaration. I do not understand how {{{#!hs rnHsTyKi _ doc ty@(HsRecTy flds) = do { addErr (hang (ptext (sLit "Record syntax is illegal here:")) 2 (ppr ty)) ; (flds', fvs) <- rnConDeclFields [] doc flds ; return (HsRecTy flds', fvs) } }}} works. The error is always added, I do not see `discardErrors` in `rnConDeclFields`. What am I missing? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 26 12:12:08 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Nov 2015 12:12:08 -0000 Subject: [GHC] #11028: Refactor ConDecl In-Reply-To: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> References: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> Message-ID: <061.abea5b91b398bd8cffaa7b6477fc8bbf@haskell.org> #11028: Refactor ConDecl -------------------------------------+------------------------------------- Reporter: simonpj | Owner: alanz 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I think you should just move the check to the typechecker. It's there to stop you writing {{{ f :: { x::Int } -> Int f = blah }}} in normal code. But the renamer now treats a GADT constructor type uniformly, so we don't want to reject it. The type checker treats them differently, so it can reject `HsRecTy` in ordinary types but not in GADTs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 26 12:25:54 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Nov 2015 12:25:54 -0000 Subject: [GHC] #11028: Refactor ConDecl In-Reply-To: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> References: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> Message-ID: <061.46ea6593eb574c663a4fa0907906762d@haskell.org> #11028: Refactor ConDecl -------------------------------------+------------------------------------- Reporter: simonpj | Owner: alanz 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alanz): Something else I am bumping my head against is that `rnField` gets passed an empty `fl_env` and so `lookupField` generates a panic when the lookup fails. It seems that the new `RdrHsSyn.gadtDeclDetails` needs to be called before this, but unless the results are stored the names may be discarded. I do not know enough about this atm. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 26 12:58:54 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Nov 2015 12:58:54 -0000 Subject: [GHC] #11028: Refactor ConDecl In-Reply-To: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> References: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> Message-ID: <061.a7e4b66523f446bcbab1435c18648799@haskell.org> #11028: Refactor ConDecl -------------------------------------+------------------------------------- Reporter: simonpj | Owner: alanz 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Ah yes. To rename a record we need to know what data constructor it is from; this call in `rnHsTyKi` {{{ ; (flds', fvs) <- rnConDeclFields [] doc flds }}} should not have the empty list, but rather the result of a lookup, just as in `RnSource.rnConDeclDetails`. (Indeed better to pass the `Name` of the data constructor to `rnConDeclFields`.) Where to get the `Name` of the `DataCon` from in the case of GADTs. It could be in the `HsDocContext` passed down the type renamer. Change `ConDeclCtx` to take a `Name` instead of `RdrName`s. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 26 13:14:28 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Nov 2015 13:14:28 -0000 Subject: [GHC] #11028: Refactor ConDecl In-Reply-To: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> References: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> Message-ID: <061.03840944033b8a6252a895c20e3c3449@haskell.org> #11028: Refactor ConDecl -------------------------------------+------------------------------------- Reporter: simonpj | Owner: alanz 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): BTW, a refactoring I'd love to see done is this: '''combine `RnEnv.HsDocContext` (used in the renamer) and `TcType.UserTypeCtxt` (used in the type checker)'''. Both are fairly big types; but they are practically the same already, except that the former uses `RdrName`s while the latter uses `Name`s. But that's accidental; in fact the renamer could perfectly well construct contexts with `Name`s in them. I think that everything else is just accidental differences. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 26 14:18:56 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Nov 2015 14:18:56 -0000 Subject: [GHC] #10989: :ctags and :etags command can receive haskell source files as a parameter In-Reply-To: <045.de3e950ef6c4dee2c0f5411e366ebc4e@haskell.org> References: <045.de3e950ef6c4dee2c0f5411e366ebc4e@haskell.org> Message-ID: <060.f33bb2cdc66b68c0937ef5bb22b77aa8@haskell.org> #10989: :ctags and :etags command can receive haskell source files as a parameter -------------------------------------+------------------------------------- Reporter: hugomg | Owner: tvv Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.10.2 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1471 Wiki Page: | -------------------------------------+------------------------------------- Changes (by tvv): * status: upstream => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 26 15:59:55 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Nov 2015 15:59:55 -0000 Subject: [GHC] #11028: Refactor ConDecl In-Reply-To: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> References: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> Message-ID: <061.924e9ce4e38ce7e3e6483f415a6fca78@haskell.org> #11028: Refactor ConDecl -------------------------------------+------------------------------------- Reporter: simonpj | Owner: alanz 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alanz): So `kcConDecl` can't just call `kcHsSigType`, the strict marks on arguments need to be managed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 26 16:21:06 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Nov 2015 16:21:06 -0000 Subject: [GHC] #11028: Refactor ConDecl In-Reply-To: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> References: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> Message-ID: <061.645c731b9a7bbd04ea2bb7c8b435d71a@haskell.org> #11028: Refactor ConDecl -------------------------------------+------------------------------------- Reporter: simonpj | Owner: alanz 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Bother. I guess that to typecheck a GADT decl we'll need a function with a type like this: {{{ tcGadtSigType :: LHsSigType Name -> TcM ([StrictnessMark], [FieldLabel], [Type], Type) }}} or something like that. It takes a GADT data constructor type signature, like {{{ C :: { x :: !Int, y:: Bool } -> T Int }}} and returns the typechecked pieces. Once you've got that, you can use the very same function during kind checking. Just call it and discard the result. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 26 16:26:42 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Nov 2015 16:26:42 -0000 Subject: [GHC] #11136: Associated type family: panic due to mismatch in arity of default instances Message-ID: <045.d6613b05f82c438d5c7fef89ff48ed45@haskell.org> #11136: Associated type family: panic due to mismatch in arity of default instances -------------------------------------+------------------------------------- Reporter: airini | 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 Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Having extra type parameters in the definition of default instances for an associated type family causes a ghc panic error (should be detected as a not valid instance). Smallest case example: {{{#!hs class C a where type D a type instance D a x = x }}} It produces the error: {{{ [1 of 1] Compiling Main ( SplitKindFun.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-apple-darwin): splitKindFunTysN 1 * Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Crashes similarly for additional parameters in the default instance: {{{#!hs class C a where type D a type instance D a x y = x }}} {{{ [1 of 1] Compiling Main ( SplitKindFun.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-apple-darwin): splitKindFunTysN 2 * Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Presumably the arity is not compared correctly to that of the family declaration when the kind is default `*` since the following (and equivalent) causes the panic crash: {{{#!hs class C a where type D a :: * type instance D a x = x }}} but increasing the arity of the family's kind {{{#!hs class C a where type D a :: * -> * type instance D a x = x }}} raises the appropriate error: {{{ [1 of 1] Compiling Main ( SplitKindFun.hs, interpreted ) SplitKindFun.hs:6:3: Number of parameters must match family declaration; expected 1 In the default type instance declaration for ?D? In the class declaration for ?C? Failed, modules loaded: none. }}} Longer verbose compiler output of the original error: {{{ $ ghc -v SplitKindFun.hs Glasgow Haskell Compiler, Version 7.10.2, stage 2 booted by GHC version 7.10.1.20150612 Using binary package database: /Library/Frameworks/GHC.framework/Versions/7.10.2-x86_64/usr/lib/ghc-7.10.2/package.conf.d/package.cache Using binary package database: /Users/uu/.ghc/x86_64-darwin-7.10.2/package.conf.d/package.cache wired-in package ghc-prim mapped to ghc- prim-0.4.0.0-af16264bc80979d06e37ac63e3ba9a21 wired-in package integer-gmp mapped to integer- gmp-1.0.0.0-8e0f14d0262184533b417ca1f8b44482 wired-in package base mapped to base-4.8.1.0-075aa0db10075facc5aaa59a7991ca2f wired-in package rts mapped to builtin_rts wired-in package template-haskell mapped to template- haskell-2.10.0.0-161ca39a5ae657ff216d049e722e60ea wired-in package ghc mapped to ghc-7.10.2-5c2381785a7b22838c6eda985bc898cf wired-in package dph-seq not found. wired-in package dph-par not found. Hsc static flags: wired-in package ghc-prim mapped to ghc- prim-0.4.0.0-af16264bc80979d06e37ac63e3ba9a21 wired-in package integer-gmp mapped to integer- gmp-1.0.0.0-8e0f14d0262184533b417ca1f8b44482 wired-in package base mapped to base-4.8.1.0-075aa0db10075facc5aaa59a7991ca2f wired-in package rts mapped to builtin_rts wired-in package template-haskell mapped to template- haskell-2.10.0.0-161ca39a5ae657ff216d049e722e60ea wired-in package ghc mapped to ghc-7.10.2-5c2381785a7b22838c6eda985bc898cf wired-in package dph-seq not found. wired-in package dph-par not found. *** Chasing dependencies: Chasing modules from: *SplitKindFun.hs Stable obj: [] Stable BCO: [] Ready for upsweep [NONREC ModSummary { ms_hs_date = 2015-11-26 15:20:15 UTC ms_mod = Main, ms_textual_imps = [import (implicit) Prelude] ms_srcimps = [] }] *** Deleting temp files: Deleting: compile: input file SplitKindFun.hs Created temporary directory: /var/folders/m3/cx6_zbks6qq2xtwx92njp8w40000gn/T/ghc755_0 *** Checking old interface for Main: [1 of 1] Compiling Main ( SplitKindFun.hs, SplitKindFun.o ) *** Parser: *** Renamer/typechecker: *** Deleting temp files: Deleting: /var/folders/m3/cx6_zbks6qq2xtwx92njp8w40000gn/T/ghc755_0/ghc_1.s Warning: deleting non-existent /var/folders/m3/cx6_zbks6qq2xtwx92njp8w40000gn/T/ghc755_0/ghc_1.s *** Deleting temp dirs: Deleting: /var/folders/m3/cx6_zbks6qq2xtwx92njp8w40000gn/T/ghc755_0 ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-apple-darwin): splitKindFunTysN 1 * Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 26 23:53:06 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Nov 2015 23:53:06 -0000 Subject: [GHC] #11137: configure is broken for the unix package Message-ID: <042.888db3b96dcad1b1fa54d5554235ba60@haskell.org> #11137: configure is broken for the unix package -------------------------------------+------------------------------------- Reporter: pgj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.11 libraries/unix | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- A few weeks ago (around November 1, 2015), the FreeBSD builders started to fail building GHC-HEAD with an error message something like that: {{{ [...] /usr/home/ghc-builder/work/builder/tempbuild/build/libraries/unix/dist- install/build/libHSunix-2.7.1.0-ghc7.11.20151126.so: undefined reference to `fdatasync' collect2: error: ld returned 1 exit status `gcc48' failed in phase `Linker'. (Exit code: 1) ghc/ghc.mk:121: recipe for target 'ghc/stage2/build/tmp/ghc-stage2' failed gmake[1]: *** [ghc/stage2/build/tmp/ghc-stage2] Error 1 Makefile:121: recipe for target 'all' failed gmake: *** [all] Error 2 }}} That is because {{{fdatasync(2)}}} is not implemented on FreeBSD. Apparently, it is handled in the respective file ({{{System/Posix/Unistd.hsc}}}), though it relies on the variable ({{{HAVE_FDATASYNC}}}) generated at the {{{configure}}} phase. But for some reason, the {{{configure}}} script of the {{{unix}}} package fails to detect this as it says the following: {{{ "inplace/bin/ghc-cabal" configure libraries/unix dist-install "" --with- ghc="/usr/home/ghc-builder/work/builder/tempbuild/build/inplace/bin/ghc- stage1" --with-ghc-pkg="/usr/home/ghc- builder/work/builder/tempbuild/build/inplace/bin/ghc-pkg" --disable- library-for-ghci --enable-library-vanilla --enable-library-profiling --enable-shared --with-hscolour="/usr/local/bin/HsColour" --configure- option=CFLAGS="-Wall -fno-stack-protector -Werror=unused-but-set- variable -Wno-error=inline" --configure-option=LDFLAGS=" " --configure- option=CPPFLAGS=" " --gcc-options="-Wall -fno-stack-protector -Werror =unused-but-set-variable -Wno-error=inline " --configure-option=--with- iconv-includes="/usr/local/include" --configure-option=--with-iconv- libraries="/usr/local/lib" --configure-option=--with-gmp- includes="/usr/local/include" --configure-option=--with-gmp- libraries="/usr/local/lib" --with-gcc="/usr/local/bin/gcc48" --with- ld="/usr/local/bin/ld" --configure-option=--with-cc="/usr/local/bin/gcc48" --with-ar="/usr/local/bin/ar" --with-alex="/usr/local/bin/alex" --with- happy="/usr/local/bin/happy" Configuring unix-2.7.1.0... [...] checking for fdatasync... yes }}} That is the corresponding part of the {{{config.log}}}: {{{ configure:4242: checking for fdatasync configure:4263: /usr/local/bin/gcc48 -c -Wall -fno-stack-protector -Werror=unused-but-set-variable -Wno-error=inline conftest.c >&5 conftest.c: In function 'main': conftest.c:71:1: warning: implicit declaration of function 'fdatasync' [-Wimplicit-function-declaration] fdatasync(4); ^ configure:4263: $? = 0 configure:4271: result: yes }}} Looks like GCC is willing to compile the test code, although it notes that it cannot find the declaration of the {{{fdatasync()}}} function. Unfortunately, the {{{configure}}} script does not instruct GCC to do any linking or be serious on such warnings, so it happily proceeds. For the reference, previously the {{{config.log}}} said something like that instead: {{{ configure:4230: checking for fdatasync configure:4230: /usr/local/bin/gcc48 -o conftest -Wall -fno-stack- protector -Werror=unused-but-set-variable -Wno-error=inline conftest.c >&5 /tmp//ccDCjZtO.o: In function `main': conftest.c:(.text+0xa): undefined reference to `fdatasync' collect2: error: ld returned 1 exit status configure:4230: $? = 1 [...] }}} I am inclined to think that this is caused by the commit [https://github.com/haskell/unix/commit/b06446edd4753f964a46d27ddae864fad97adc13 b06446edd4753f964a46d27ddae864fad97adc13] for the {{{unix}}} package. Perhaps the following change can fix that, at least it fixed for me: {{{ --- a/mk/warnings.mk +++ b/mk/warnings.mk @@ -16,6 +16,7 @@ SRC_CC_WARNING_OPTS += -Werror=unused-but-set-variable endif # gcc 4.6 gives 3 warning for giveCapabilityToTask not being inlined SRC_CC_WARNING_OPTS += -Wno-error=inline +SRC_CC_WARNING_OPTS += -Werror=implicit-function-declaration endif else }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 27 08:22:04 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Nov 2015 08:22:04 -0000 Subject: [GHC] #11136: Associated type family: panic due to mismatch in arity of default instances In-Reply-To: <045.d6613b05f82c438d5c7fef89ff48ed45@haskell.org> References: <045.d6613b05f82c438d5c7fef89ff48ed45@haskell.org> Message-ID: <060.8c4a65e42202958dfd45caa5c9afd4bd@haskell.org> #11136: Associated type family: panic due to mismatch in arity of default instances -------------------------------------+------------------------------------- Reporter: airini | Owner: simonpj 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: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: => simonpj Comment: I'm on this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 27 10:28:29 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Nov 2015 10:28:29 -0000 Subject: [GHC] #11127: Update cabal submodule to 1.22.5 In-Reply-To: <045.b86ccf3972e67654868d36d88f8530d9@haskell.org> References: <045.b86ccf3972e67654868d36d88f8530d9@haskell.org> Message-ID: <060.4cb44392b8156c807242e45c66c11ed3@haskell.org> #11127: Update cabal submodule to 1.22.5 -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Type: task | Status: new Priority: high | Milestone: 7.10.3 Component: libraries | Version: (other) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:5 lukexi]: > Mikhail tagged a 1.22.5 release so the relevant commit is now `fb7ce39`. nope, he didn't... there's no git-signed annotated Git tag `Cabal-v1.22.5.0` yet (like there was for http://git.haskell.org/packages/Cabal.git/tag/Cabal-v1.22.4.0) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 27 11:38:28 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Nov 2015 11:38:28 -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.e7f2c7595914037712355eec3a42446e@haskell.org> #10751: Implement Phase 1 of MonadFail Proposal (MFP) -------------------------------------+------------------------------------- Reporter: hvr | Owner: quchen Type: task | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | 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:D1248 Wiki Page: | prime:Libraries/Proposals/MonadFail| -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"d25f8535a0178984f29178f983536ab40cc471a8/ghc" d25f8535/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d25f8535a0178984f29178f983536ab40cc471a8" Update transformers submodule Most notably this pulls in `MonadFail` instances (see also #10751) - add MonadFail instance for ContT - re-order methods for consistency - Add `MonadFail` instances - Canonicalise Monad instances - instance Bifunctor Constant }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 27 11:40:49 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Nov 2015 11:40:49 -0000 Subject: [GHC] #11137: configure is broken for the unix package In-Reply-To: <042.888db3b96dcad1b1fa54d5554235ba60@haskell.org> References: <042.888db3b96dcad1b1fa54d5554235ba60@haskell.org> Message-ID: <057.ddc7256fb228697ace72f162f8af18b6@haskell.org> #11137: configure is broken for the unix package -------------------------------------+------------------------------------- Reporter: pgj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/unix | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): please report on https://github.com/haskell/unix/issues as well -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 27 12:31:46 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Nov 2015 12:31:46 -0000 Subject: [GHC] #11137: configure is broken for the unix package In-Reply-To: <042.888db3b96dcad1b1fa54d5554235ba60@haskell.org> References: <042.888db3b96dcad1b1fa54d5554235ba60@haskell.org> Message-ID: <057.ea1fde6a3a1bbd77c5e5c381e218f307@haskell.org> #11137: configure is broken for the unix package -------------------------------------+------------------------------------- Reporter: pgj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/unix | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by pgj): Okay, I have reported this as [https://github.com/haskell/unix/issues/52 issue #52]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 27 13:06:53 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Nov 2015 13:06:53 -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.ece98bb3e2e2e1f3cf1e2da7613ab941@haskell.org> #10365: Implement Semigroup as a superclass of Monoid Proposal (Phase 1) -------------------------------------+------------------------------------- Reporter: gidyn | Owner: quchen 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 Wiki Page: | prime:Libraries/Proposals/SemigroupMonoid| -------------------------------------+------------------------------------- Comment (by bgamari): @ekmett, has there been any motion on this front? At this point I have no horse in this race; nevertheless I do want to make sure that whatever option we do end up with was chosen not by chance by but conscious decision. Sadly time is quickly running out for 8.0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 27 13:23:30 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Nov 2015 13:23:30 -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.762e0daa9d3718e70e774dc1e2340f39@haskell.org> #10365: Implement Semigroup as a superclass of Monoid Proposal (Phase 1) -------------------------------------+------------------------------------- Reporter: gidyn | Owner: quchen 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 Wiki Page: | prime:Libraries/Proposals/SemigroupMonoid| -------------------------------------+------------------------------------- Comment (by nomeata): The committee decided to keep `sconcat`, and hence `NonEmpty`: https://prime.haskell.org/wiki/Libraries/Meetings/2015-11-05 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 27 13:52:26 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Nov 2015 13:52:26 -0000 Subject: [GHC] #11127: Update cabal submodule to 1.22.5 In-Reply-To: <045.b86ccf3972e67654868d36d88f8530d9@haskell.org> References: <045.b86ccf3972e67654868d36d88f8530d9@haskell.org> Message-ID: <060.b5655e2e84dc8971d749565b3363bd5f@haskell.org> #11127: Update cabal submodule to 1.22.5 -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Type: task | Status: new Priority: high | Milestone: 7.10.3 Component: libraries | Version: (other) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by refold): Yes, I just bumped the version in the .cabal file. If you want Cabal 1.22.5.0 to be released on Hackage first, I'll ask Ryan to cut a release. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 27 14:06:17 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Nov 2015 14:06:17 -0000 Subject: [GHC] #7660: warning: conflicting types when compiling via-C In-Reply-To: <049.e381ff0e988b9be58c4264b55de7ee53@haskell.org> References: <049.e381ff0e988b9be58c4264b55de7ee53@haskell.org> Message-ID: <064.168a6c028802c5d34d661f7d4e815b0c@haskell.org> #7660: warning: conflicting types when compiling via-C -------------------------------------+------------------------------------- Reporter: singpolyma | Owner: hvr Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: warning Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1506 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: This should be resolved with the above commit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 27 14:10:00 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Nov 2015 14:10:00 -0000 Subject: [GHC] #7450: Regression in optimisation time of functions with many patterns (6.12 to 7.4)? In-Reply-To: <045.5b74d940dce176e76fe47859d9b698f8@haskell.org> References: <045.5b74d940dce176e76fe47859d9b698f8@haskell.org> Message-ID: <060.a039f32a80a9676e7de07542636c1a49@haskell.org> #7450: Regression in optimisation time of functions with many patterns (6.12 to 7.4)? -------------------------------------+------------------------------------- Reporter: iustin | Owner: bgamari Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1012 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Judging by the summary in ticket:9669#comment:13 there still may be some non-linear behavior here. I need to look further into this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 27 14:10:13 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Nov 2015 14:10:13 -0000 Subject: [GHC] #7450: Regression in optimisation time of functions with many patterns (6.12 to 7.4)? In-Reply-To: <045.5b74d940dce176e76fe47859d9b698f8@haskell.org> References: <045.5b74d940dce176e76fe47859d9b698f8@haskell.org> Message-ID: <060.4aecbe8dc7a292beb54d55640699ef84@haskell.org> #7450: Regression in optimisation time of functions with many patterns (6.12 to 7.4)? -------------------------------------+------------------------------------- Reporter: iustin | Owner: 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: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1012 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: bgamari => * status: patch => new -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 27 14:10:20 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Nov 2015 14:10:20 -0000 Subject: [GHC] #7450: Regression in optimisation time of functions with many patterns (6.12 to 7.4)? In-Reply-To: <045.5b74d940dce176e76fe47859d9b698f8@haskell.org> References: <045.5b74d940dce176e76fe47859d9b698f8@haskell.org> Message-ID: <060.18506c2cc11bd0e80a3378bf9183f1ce@haskell.org> #7450: Regression in optimisation time of functions with many patterns (6.12 to 7.4)? -------------------------------------+------------------------------------- Reporter: iustin | Owner: bgamari 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: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1012 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 27 14:18:54 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Nov 2015 14:18:54 -0000 Subject: [GHC] #4213: LLVM: Add support for TNTC to LLVM compiler suite In-Reply-To: <045.baf39684c1ad6f53c42a607914cc93f4@haskell.org> References: <045.baf39684c1ad6f53c42a607914cc93f4@haskell.org> Message-ID: <060.c6b6a3b2d18024d8da20fd572c8b9fd7@haskell.org> #4213: LLVM: Add support for TNTC to LLVM compiler suite -------------------------------------+------------------------------------- Reporter: dterei | Owner: bgamari Type: feature request | Status: new Priority: low | Milestone: 8.0.1 Component: Compiler (LLVM) | Version: 6.13 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 9142 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: dterei => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 27 14:21:11 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Nov 2015 14:21:11 -0000 Subject: [GHC] #4213: LLVM: Add support for TNTC to LLVM compiler suite In-Reply-To: <045.baf39684c1ad6f53c42a607914cc93f4@haskell.org> References: <045.baf39684c1ad6f53c42a607914cc93f4@haskell.org> Message-ID: <060.f199fd680f83e71e63713308d1e29832@haskell.org> #4213: LLVM: Add support for TNTC to LLVM compiler suite -------------------------------------+------------------------------------- Reporter: dterei | Owner: bgamari Type: feature request | Status: closed Priority: low | Milestone: 8.0.1 Component: Compiler (LLVM) | Version: 6.13 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 9142 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: I resolved this in 5d5abdca31cdb4db5303999778fa25c4a1371084 by reworking the LLVM code generator to use LLVM 3.6's new support for "prefix data". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 27 14:23:44 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Nov 2015 14:23:44 -0000 Subject: [GHC] #11138: Kill the terrible LLVM Mangler Message-ID: <046.1671c4fce95e0eb48491b5a743b485ce@haskell.org> #11138: Kill the terrible LLVM Mangler -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 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 Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Since its introduction the LLVM backend has had a mangler which transforms assembler produced by LLVM. In the past this mangler was responsible for shuffling around code to make tables-next-to-code work, but the need for this has past with the resolution of #4213. At this point the only reason it exists is to mangle AVX instructions to 1. rewriting all symbols of type `@function` to `@object` to prevent symbol references from going through the PLT, which would be bad due to tables-next-to-code. 2. On x86_64, rewrite AVX instructions that require alignment to their unaligned counterparts, since the stack is only 16-byte aligned but these instructions require 32-byte alignment. While it's unclear that we will ever be able to discharge (1), it would be nice to investigate whether we can at least do something about (2) (there may even be performance to be gained!). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 27 14:25:27 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Nov 2015 14:25:27 -0000 Subject: [GHC] #10394: LLVM mangler doesn't mangle AVX instructions In-Reply-To: <047.b85b8723ab1fa78e7e23f08be8ccae23@haskell.org> References: <047.b85b8723ab1fa78e7e23f08be8ccae23@haskell.org> Message-ID: <062.762e6fd5f8c70d70b25d9c91e793c122@haskell.org> #10394: LLVM mangler doesn't mangle AVX instructions -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler (LLVM) | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1034 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: This particular issue can be closed. The more general problem of the LLVM mangler we'll track as #11138. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 27 14:25:50 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Nov 2015 14:25:50 -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.73249e676efe532d97eeb51d18f58fed@haskell.org> #10773: Add Control.Monad.IO.Class from transformers to base -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: feature request | Status: closed Priority: high | Milestone: 8.0.1 Component: Core Libraries | 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 Rev(s): Phab:D1147 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: This has been merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 27 14:26:52 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Nov 2015 14:26:52 -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.0bc70812ab638ba1d601ab87a28993f0@haskell.org> #10365: Implement Semigroup as a superclass of Monoid Proposal (Phase 1) -------------------------------------+------------------------------------- Reporter: gidyn | Owner: quchen Type: feature request | Status: closed Priority: high | Milestone: 8.0.1 Component: libraries/base | Version: 7.10.1 Resolution: fixed | 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 Wiki Page: | prime:Libraries/Proposals/SemigroupMonoid| -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Alright then. I believe this issue is then resolved. Thanks everyone! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 27 14:28:26 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Nov 2015 14:28:26 -0000 Subject: [GHC] #10735: Smooth out the differences between `compiler/utils/Pretty.hs` and `libraries/pretty` In-Reply-To: <045.0d6bd344b086b712375d48496c897cf9@haskell.org> References: <045.0d6bd344b086b712375d48496c897cf9@haskell.org> Message-ID: <060.d4bea102ef9558437874818138ffc85b@haskell.org> #10735: Smooth out the differences between `compiler/utils/Pretty.hs` and `libraries/pretty` -------------------------------------+------------------------------------- Reporter: thomie | Owner: thomie Type: task | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #1062, #1176, | Differential Rev(s): Phab:D1130, #7666, #8809 | Phab:D1132 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.1 => 8.2.1 Comment: It seems unlikely that this is going to happen for 8.0. Punting to 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 27 14:35:06 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Nov 2015 14:35:06 -0000 Subject: [GHC] #10279: panic on haskell-src-exts In-Reply-To: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> References: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> Message-ID: <066.83f651c79668ff6730c444948c9307b2@haskell.org> #10279: panic on haskell-src-exts -------------------------------------+------------------------------------- Reporter: throwaway123 | Owner: ezyang Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.1 Resolution: wontfix | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1342 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => wontfix Old description: > Compiling `Bug.hs`: > > {{{ > {-# LANGUAGE QuasiQuotes #-} > > import Language.Haskell.Exts.QQ (dec) > > main :: IO () > main = return () > where > foo = [dec| bar = 3 |] > }}} > by `ghc --make -v -dcore-lint Bug.hs` gives > {{{ > ghc --make -v -dcore-lint Bug.hs > Glasgow Haskell Compiler, Version 7.10.1, stage 2 booted by GHC version > 7.8.4 > Using binary package database: > /usr/lib/ghc-7.10.1/package.conf.d/package.cache > wired-in package ghc-prim mapped to ghc- > prim-0.4.0.0-7c945cc0c41d3b7b70f3edd125671166 > wired-in package integer-gmp mapped to integer- > gmp-1.0.0.0-3c947e5fb6dca14804d9b2793c521b67 > wired-in package base mapped to > base-4.8.0.0-1b689eb8d72c4d4cc88f445839c1f01a > wired-in package rts mapped to builtin_rts > wired-in package template-haskell mapped to template- > haskell-2.10.0.0-e895139a0ffff267d412e3d0191ce93b > wired-in package ghc mapped to > ghc-7.10.1-325809317787a897b7a97d646ceaa3a3 > wired-in package dph-seq not found. > wired-in package dph-par not found. > Hsc static flags: > wired-in package ghc-prim mapped to ghc- > prim-0.4.0.0-7c945cc0c41d3b7b70f3edd125671166 > wired-in package integer-gmp mapped to integer- > gmp-1.0.0.0-3c947e5fb6dca14804d9b2793c521b67 > wired-in package base mapped to > base-4.8.0.0-1b689eb8d72c4d4cc88f445839c1f01a > wired-in package rts mapped to builtin_rts > wired-in package template-haskell mapped to template- > haskell-2.10.0.0-e895139a0ffff267d412e3d0191ce93b > wired-in package ghc mapped to > ghc-7.10.1-325809317787a897b7a97d646ceaa3a3 > wired-in package dph-seq not found. > wired-in package dph-par not found. > *** Chasing dependencies: > Chasing modules from: *Bug.hs > Stable obj: [] > Stable BCO: [] > Ready for upsweep > [NONREC > ModSummary { > ms_hs_date = 2015-04-09 10:01:43.312180074 UTC > ms_mod = Main, > ms_textual_imps = [import (implicit) Prelude, > import Language.Haskell.Exts.QQ ( dec )] > ms_srcimps = [] > }] > *** Deleting temp files: > Deleting: > compile: input file Bug.hs > Created temporary directory: /tmp/ghc7356_0 > *** Checking old interface for Main: > [1 of 1] Compiling Main ( Bug.hs, Bug.o ) > *** Parser: > *** Renamer/typechecker: > *** Simplify: > *** CorePrep: > *** ByteCodeGen: > Loading package ghc-prim-0.4.0.0 ... linking ... done. > *** gcc: > /usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE > -L/usr/lib/ghc-7.10.1/integ_2aU3IZNMF9a7mQ0OzsZ0dS --print-file-name > libgmp.so > Loading package integer-gmp-1.0.0.0 ... linking ... done. > Loading package base-4.8.0.0 ... linking ... done. > Loading package array-0.5.1.0 ... linking ... done. > Loading package filepath-1.4.0.0 ... linking ... done. > Loading package deepseq-1.4.1.1 ... linking ... done. > Loading package time-1.5.0.1 ... linking ... done. > Loading package bytestring-0.10.6.0 ... linking ... done. > *** gcc: > /usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE > -L/usr/lib/ghc-7.10.1/unix_G4Yo1pNtYrk8nCq1cx8P9d --print-file-name > librt.so > *** gcc: > /usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE > -L/usr/lib/ghc-7.10.1/unix_G4Yo1pNtYrk8nCq1cx8P9d --print-file-name > libutil.so > *** gcc: > /usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE > -L/usr/lib/ghc-7.10.1/unix_G4Yo1pNtYrk8nCq1cx8P9d --print-file-name > libdl.so > *** gcc: > /usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE > -L/usr/lib/ghc-7.10.1/unix_G4Yo1pNtYrk8nCq1cx8P9d --print-file-name > libpthread.so > Loading package unix-2.7.1.0 ... linking ... done. > Loading package directory-1.2.2.0 ... linking ... done. > Loading package old-locale-1.0.0.7 ... linking ... done. > Loading package old-time-1.1.0.3 ... linking ... done. > Loading package text-1.2.0.4 ... linking ... done. > Loading package polyparse-1.11 ... linking ... done. > Loading package cpphs-1.19 ... linking ... done. > Loading package pretty-1.1.2.0 ... linking ... done. > Loading package haskell-src-exts-1.16.0.1 ... linking ... done. > Loading package syb-0.4.4 ... linking ... done. > Loading package template-haskell-2.10.0.0 ... linking ... done. > Loading package transformers-0.4.2.0 ... linking ... done. > Loading package mtl-2.2.1 ... linking ... done. > Loading package nats-1 ... linking ... done. > Loading package th-lift-0.7.2 ... linking ... done. > Loading package containers-0.5.6.2 ... linking ... done. > Loading package safe-0.3.8 ... linking ... done. > Loading package th-expand-syns-0.3.0.6 ... linking ... done. > Loading package th-reify-many-0.1.3 ... linking ... done. > Loading package th-orphans-0.11.1 ... linking ... done. > Loading package haskell-src-meta-0.6.0.9 ... linking ... done. > Loading package haskell-src-exts-qq-0.6.1 ... linking ... done. > > Bug.hs:8:16:*** Deleting temp files: > Deleting: /tmp/ghc7356_0/ghc7356_1.s > Warning: deleting non-existent /tmp/ghc7356_0/ghc7356_1.s > *** Deleting temp dirs: > Deleting: /tmp/ghc7356_0 > ghc: panic! (the 'impossible' happened) > (GHC version 7.10.1 for x86_64-unknown-linux): > qual_pkg haskell-src-exts-1.16.0.1 > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} > on my machine: > {{{ > $ uname -a > Linux io 3.19.3-1-ARCH #1 SMP PREEMPT Thu Mar 26 14:56:16 CET 2015 x86_64 > GNU/Linux > > $ gcc -v > Using built-in specs. > COLLECT_GCC=gcc > COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/lto- > wrapper > Target: x86_64-unknown-linux-gnu > Configured with: /build/gcc/src/gcc-4.9-20150304/configure --prefix=/usr > --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man > --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ > --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared > --enable-threads=posix --with-system-zlib --enable-__cxa_atexit > --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx- > pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id > --enable-cloog-backend=isl --enable-lto --enable-plugin --enable-install- > libiberty --with-linker-hash-style=gnu --disable-multilib --disable- > werror --enable-checking=release > Thread model: posix > gcc version 4.9.2 20150304 (prerelease) (GCC) > > $ ghc-pkg list > /usr/lib/ghc-7.10.1/package.conf.d > Cabal-1.22.2.0 > array-0.5.1.0 > async-2.0.2 > base-4.8.0.0 > bin-package-db-0.0.0.0 > binary-0.7.3.0 > bytestring-0.10.6.0 > containers-0.5.6.2 > cpphs-1.19 > deepseq-1.4.1.1 > directory-1.2.2.0 > filepath-1.4.0.0 > ghc-7.10.1 > ghc-paths-0.1.0.9 > ghc-prim-0.4.0.0 > haddock-api-2.16.0 > haddock-library-1.2.0 > haskeline-0.7.2.1 > haskell-src-exts-1.16.0.1 > haskell-src-exts-qq-0.6.1 > haskell-src-meta-0.6.0.9 > hoopl-3.10.0.2 > hpc-0.6.0.2 > integer-gmp-1.0.0.0 > minisat-0.1.1 > mtl-2.2.1 > nats-1 > old-locale-1.0.0.7 > old-time-1.1.0.3 > polyparse-1.11 > pretty-1.1.2.0 > process-1.2.3.0 > rts-1.0 > safe-0.3.8 > satchmo-core-0.8.0 > stm-2.4.4 > syb-0.4.4 > template-haskell-2.10.0.0 > terminfo-0.4.0.1 > text-1.2.0.4 > th-expand-syns-0.3.0.6 > th-lift-0.7.2 > th-orphans-0.11.1 > th-reify-many-0.1.3 > time-1.5.0.1 > transformers-0.4.2.0 > unix-2.7.1.0 > xhtml-3000.2.1 > }}} New description: Compiling `Bug.hs`: {{{#!hs {-# LANGUAGE QuasiQuotes #-} import Language.Haskell.Exts.QQ (dec) main :: IO () main = return () where foo = [dec| bar = 3 |] }}} by `ghc --make -v -dcore-lint Bug.hs` gives {{{ ghc --make -v -dcore-lint Bug.hs Glasgow Haskell Compiler, Version 7.10.1, stage 2 booted by GHC version 7.8.4 Using binary package database: /usr/lib/ghc-7.10.1/package.conf.d/package.cache wired-in package ghc-prim mapped to ghc- prim-0.4.0.0-7c945cc0c41d3b7b70f3edd125671166 wired-in package integer-gmp mapped to integer- gmp-1.0.0.0-3c947e5fb6dca14804d9b2793c521b67 wired-in package base mapped to base-4.8.0.0-1b689eb8d72c4d4cc88f445839c1f01a wired-in package rts mapped to builtin_rts wired-in package template-haskell mapped to template- haskell-2.10.0.0-e895139a0ffff267d412e3d0191ce93b wired-in package ghc mapped to ghc-7.10.1-325809317787a897b7a97d646ceaa3a3 wired-in package dph-seq not found. wired-in package dph-par not found. Hsc static flags: wired-in package ghc-prim mapped to ghc- prim-0.4.0.0-7c945cc0c41d3b7b70f3edd125671166 wired-in package integer-gmp mapped to integer- gmp-1.0.0.0-3c947e5fb6dca14804d9b2793c521b67 wired-in package base mapped to base-4.8.0.0-1b689eb8d72c4d4cc88f445839c1f01a wired-in package rts mapped to builtin_rts wired-in package template-haskell mapped to template- haskell-2.10.0.0-e895139a0ffff267d412e3d0191ce93b wired-in package ghc mapped to ghc-7.10.1-325809317787a897b7a97d646ceaa3a3 wired-in package dph-seq not found. wired-in package dph-par not found. *** Chasing dependencies: Chasing modules from: *Bug.hs Stable obj: [] Stable BCO: [] Ready for upsweep [NONREC ModSummary { ms_hs_date = 2015-04-09 10:01:43.312180074 UTC ms_mod = Main, ms_textual_imps = [import (implicit) Prelude, import Language.Haskell.Exts.QQ ( dec )] ms_srcimps = [] }] *** Deleting temp files: Deleting: compile: input file Bug.hs Created temporary directory: /tmp/ghc7356_0 *** Checking old interface for Main: [1 of 1] Compiling Main ( Bug.hs, Bug.o ) *** Parser: *** Renamer/typechecker: *** Simplify: *** CorePrep: *** ByteCodeGen: Loading package ghc-prim-0.4.0.0 ... linking ... done. *** gcc: /usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -L/usr/lib/ghc-7.10.1/integ_2aU3IZNMF9a7mQ0OzsZ0dS --print-file-name libgmp.so Loading package integer-gmp-1.0.0.0 ... linking ... done. Loading package base-4.8.0.0 ... linking ... done. Loading package array-0.5.1.0 ... linking ... done. Loading package filepath-1.4.0.0 ... linking ... done. Loading package deepseq-1.4.1.1 ... linking ... done. Loading package time-1.5.0.1 ... linking ... done. Loading package bytestring-0.10.6.0 ... linking ... done. *** gcc: /usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -L/usr/lib/ghc-7.10.1/unix_G4Yo1pNtYrk8nCq1cx8P9d --print-file-name librt.so *** gcc: /usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -L/usr/lib/ghc-7.10.1/unix_G4Yo1pNtYrk8nCq1cx8P9d --print-file-name libutil.so *** gcc: /usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -L/usr/lib/ghc-7.10.1/unix_G4Yo1pNtYrk8nCq1cx8P9d --print-file-name libdl.so *** gcc: /usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -L/usr/lib/ghc-7.10.1/unix_G4Yo1pNtYrk8nCq1cx8P9d --print-file-name libpthread.so Loading package unix-2.7.1.0 ... linking ... done. Loading package directory-1.2.2.0 ... linking ... done. Loading package old-locale-1.0.0.7 ... linking ... done. Loading package old-time-1.1.0.3 ... linking ... done. Loading package text-1.2.0.4 ... linking ... done. Loading package polyparse-1.11 ... linking ... done. Loading package cpphs-1.19 ... linking ... done. Loading package pretty-1.1.2.0 ... linking ... done. Loading package haskell-src-exts-1.16.0.1 ... linking ... done. Loading package syb-0.4.4 ... linking ... done. Loading package template-haskell-2.10.0.0 ... linking ... done. Loading package transformers-0.4.2.0 ... linking ... done. Loading package mtl-2.2.1 ... linking ... done. Loading package nats-1 ... linking ... done. Loading package th-lift-0.7.2 ... linking ... done. Loading package containers-0.5.6.2 ... linking ... done. Loading package safe-0.3.8 ... linking ... done. Loading package th-expand-syns-0.3.0.6 ... linking ... done. Loading package th-reify-many-0.1.3 ... linking ... done. Loading package th-orphans-0.11.1 ... linking ... done. Loading package haskell-src-meta-0.6.0.9 ... linking ... done. Loading package haskell-src-exts-qq-0.6.1 ... linking ... done. Bug.hs:8:16:*** Deleting temp files: Deleting: /tmp/ghc7356_0/ghc7356_1.s Warning: deleting non-existent /tmp/ghc7356_0/ghc7356_1.s *** Deleting temp dirs: Deleting: /tmp/ghc7356_0 ghc: panic! (the 'impossible' happened) (GHC version 7.10.1 for x86_64-unknown-linux): qual_pkg haskell-src-exts-1.16.0.1 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} on my machine: {{{ $ uname -a Linux io 3.19.3-1-ARCH #1 SMP PREEMPT Thu Mar 26 14:56:16 CET 2015 x86_64 GNU/Linux $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/lto- wrapper Target: x86_64-unknown-linux-gnu Configured with: /build/gcc/src/gcc-4.9-20150304/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --with-system-zlib --enable-__cxa_atexit --disable- libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-cloog-backend=isl --enable-lto --enable-plugin --enable-install- libiberty --with-linker-hash-style=gnu --disable-multilib --disable-werror --enable-checking=release Thread model: posix gcc version 4.9.2 20150304 (prerelease) (GCC) $ ghc-pkg list /usr/lib/ghc-7.10.1/package.conf.d Cabal-1.22.2.0 array-0.5.1.0 async-2.0.2 base-4.8.0.0 bin-package-db-0.0.0.0 binary-0.7.3.0 bytestring-0.10.6.0 containers-0.5.6.2 cpphs-1.19 deepseq-1.4.1.1 directory-1.2.2.0 filepath-1.4.0.0 ghc-7.10.1 ghc-paths-0.1.0.9 ghc-prim-0.4.0.0 haddock-api-2.16.0 haddock-library-1.2.0 haskeline-0.7.2.1 haskell-src-exts-1.16.0.1 haskell-src-exts-qq-0.6.1 haskell-src-meta-0.6.0.9 hoopl-3.10.0.2 hpc-0.6.0.2 integer-gmp-1.0.0.0 minisat-0.1.1 mtl-2.2.1 nats-1 old-locale-1.0.0.7 old-time-1.1.0.3 polyparse-1.11 pretty-1.1.2.0 process-1.2.3.0 rts-1.0 safe-0.3.8 satchmo-core-0.8.0 stm-2.4.4 syb-0.4.4 template-haskell-2.10.0.0 terminfo-0.4.0.1 text-1.2.0.4 th-expand-syns-0.3.0.6 th-lift-0.7.2 th-orphans-0.11.1 th-reify-many-0.1.3 time-1.5.0.1 transformers-0.4.2.0 unix-2.7.1.0 xhtml-3000.2.1 }}} -- Comment: Sadly it appears there isn't any good fix here. Instead, we must simply document our way around the problem. To quote osa1 on Phab:D1342, > I realized while thinking about this today that this new API is not a solution to `NameG` problems caused by new `UnitId` business, because query functions like `reifyPackage` are running in `Q`, so running TH is needed for these functions. > > But the whole point of using `NameG` instead of generating names using quotations was to avoid running TH. > > So this API doesn't solve the problem. > > We were chatting with @ezyang on IRC and he showed me two things: > > 1. Cabal now has a macro `CURRENT_PACKAGE_KEY` which will keep things working even when `NameG` is used. (it only helps if we refer to the current package of course, but that's enough for most of the use cases) > > 2. With next major release we'll have this: https://git.haskell.org/ghc.git/commitdiff/f16ddcee0c64a92ab911a7841a8cf64e3ac671fd which will solve all the problems caused by `NameG` and `UnitIds`. > > Long story short, this patch is not needed. What we need is to document things. And also `template-haskell` package needs some cleaning. For example, we can hide `Name` stuff. We can move some types that are used by TH generated code to an internal module to prevent users from using them. For example, why `mkNameG_v` even in `Language.Haskell.TH.Syntax`? It's not documented, it's not supposed to be used by users. The whole package is a mess. > > Oh, also, the package database I'm using in this patch is not the database I should be using. Because such a database doesn't even exist. I actually asked about this here: https://phabricator.haskell.org/D1342#38429 and got this answer: https://phabricator.haskell.org/D1342#38441 which was misleading. Consequently I'll be closing this as wontfix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 27 14:35:56 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Nov 2015 14:35:56 -0000 Subject: [GHC] #10803: New SignatureSections extension In-Reply-To: <042.499b2af8de1376e7739ef3516bd5a45e@haskell.org> References: <042.499b2af8de1376e7739ef3516bd5a45e@haskell.org> Message-ID: <057.6776c8bb965fdfd7e8dfd32554036088@haskell.org> #10803: New SignatureSections extension -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: feature request | Status: patch Priority: normal | Milestone: 8.2.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:D1185 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.1 => 8.2.1 Comment: This won't be happening for 8.0. Punting to 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 27 14:36:28 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Nov 2015 14:36:28 -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.7bd1fd6c1de7460c6dd15b7a59323c96@haskell.org> #10755: Add `MonadPlus IO` and `Alternative IO` instances -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: closed Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: Resolution: fixed | 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 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: This is done. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 27 14:38:49 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Nov 2015 14:38:49 -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.f80dc25cd97838e425e8dc1c7fbdf7c2@haskell.org> #10600: -fwarn-incomplete-patterns doesn't work with -fno-code -------------------------------------+------------------------------------- Reporter: akio | Owner: ezyang Type: bug | Status: patch Priority: normal | Milestone: 8.2.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 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.1 => 8.2.1 Comment: This won't happen for 8.0. Punting. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 27 14:40:06 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Nov 2015 14:40:06 -0000 Subject: [GHC] #11063: ghc -split-objs fails on Unicode file names In-Reply-To: <048.f9c863f2837410de9414e540724123e7@haskell.org> References: <048.f9c863f2837410de9414e540724123e7@haskell.org> Message-ID: <063.57612d743463da98b7289d2f289f3cca@haskell.org> #11063: ghc -split-objs fails on Unicode file names -------------------------------------+------------------------------------- Reporter: strake888 | Owner: strake888 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: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1442 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: This has been merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 27 14:44:38 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Nov 2015 14:44:38 -0000 Subject: [GHC] #7602: Threaded RTS performing badly on recent OS X (10.8?) In-Reply-To: <047.d4c76195d3e5b80e244f99bd757e13e7@haskell.org> References: <047.d4c76195d3e5b80e244f99bd757e13e7@haskell.org> Message-ID: <062.7afd3051b2ab2593cbc2ffb550f77625@haskell.org> #7602: Threaded RTS performing badly on recent OS X (10.8?) -------------------------------------+------------------------------------- Reporter: simonmar | Owner: thoughtpolice Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Runtime System | Version: Resolution: | Keywords: thread-local | state, TLS clang Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: 7678 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): thoughtpolice, did this ever happen? If not can we try to merge your patch for 8.0? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 27 15:17:17 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Nov 2015 15:17:17 -0000 Subject: [GHC] #10458: GHCi fails to load shared object (the 'impossible' happened) In-Reply-To: <046.4114d092404072b00fcfc0e155d0e19b@haskell.org> References: <046.4114d092404072b00fcfc0e155d0e19b@haskell.org> Message-ID: <061.a869ffa2d8ab40aea12d7f668d1e6f15@haskell.org> #10458: GHCi fails to load shared object (the 'impossible' happened) ---------------------------------+-------------------------------------- Reporter: rleslie | Owner: trommler Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by trommler): Replying to [comment:17 trommler]: > Haskell libraries are linked with `-Bsymbolic` and I wonder if that would indeed make #8935 come back. No, forget that. `-Bsymbolic` has nothing to do with #8935. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 27 15:18:12 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Nov 2015 15:18:12 -0000 Subject: [GHC] #11136: Associated type family: panic due to mismatch in arity of default instances In-Reply-To: <045.d6613b05f82c438d5c7fef89ff48ed45@haskell.org> References: <045.d6613b05f82c438d5c7fef89ff48ed45@haskell.org> Message-ID: <060.3e436b8d82e635578cfed53a4b9c4111@haskell.org> #11136: Associated type family: panic due to mismatch in arity of default instances -------------------------------------+------------------------------------- Reporter: airini | Owner: simonpj 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: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"49aae125686db914a73199d4f789370313892f8f/ghc" 49aae12/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="49aae125686db914a73199d4f789370313892f8f" Check arity on default decl for assoc types Fixes Trac #11136. We should check arity before doing tcTyClTyVars, because the latter crahes if the arity isn't right. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 27 15:22:40 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Nov 2015 15:22:40 -0000 Subject: [GHC] #10458: GHCi fails to load shared object (the 'impossible' happened) In-Reply-To: <046.4114d092404072b00fcfc0e155d0e19b@haskell.org> References: <046.4114d092404072b00fcfc0e155d0e19b@haskell.org> Message-ID: <061.820e93959e2c8ef4cc273520c91e7b0a@haskell.org> #10458: GHCi fails to load shared object (the 'impossible' happened) ---------------------------------+-------------------------------------- Reporter: rleslie | Owner: trommler Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by trommler): Replying to [comment:19 mboes]: > Replying to [comment:17 trommler]: > > > I'll take a look. > > Any luck? I have a first version of a fix at https://github.com/trommler/ghc/tree/T10458 I still need to create a regression test that does not depend on extra C libraries. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 27 15:25:54 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Nov 2015 15:25:54 -0000 Subject: [GHC] #11136: Associated type family: panic due to mismatch in arity of default instances In-Reply-To: <045.d6613b05f82c438d5c7fef89ff48ed45@haskell.org> References: <045.d6613b05f82c438d5c7fef89ff48ed45@haskell.org> Message-ID: <060.d413001847f5ce935a362e8c1b808584@haskell.org> #11136: Associated type family: panic due to mismatch in arity of default instances -------------------------------------+------------------------------------- Reporter: airini | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: indexed- crash | types/should_fail/T11136 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => indexed-types/should_fail/T11136 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 27 16:04:29 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Nov 2015 16:04:29 -0000 Subject: [GHC] #11120: Missing type representations In-Reply-To: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> References: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> Message-ID: <062.e71bbeaa048b86e50a16e8a43d5fe549@haskell.org> #11120: Missing type representations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: high | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:2 simonpj]: > > 1. You say (in Note [Grand plan for Typeable]) that there is trouble > > making the TyCon/Module information for the types in GHC.Types. But > > what precisely goes wrong? I agree that it seems a bit fishy, but I > > don't actually see the spot where trouble lurks. Did you try this? > > The difficulty is we can't generate the `TyCon` and `Module` for things in > `GHC.Types` when `TyCon` and `Module` are not yet defined. Perhaps I'm being dense, but why is this problematic? What panic or other undesirable situation will arise? To be clear: I'm proposing to keep `TyCon` and `Module` and such in `GHC.Types`. But also to put the representations for things defined in `GHC.Types` in `GHC.Types`. > The Grand Plan > comment says: > > It's hard to generate the TyCon/Module bindings when the types TyCon > and Module aren't yet available; i.e. when compiling GHC.Types > > Now what we ''could'' do (and it'd probably be a goodea) would be to put > * TyCon > * Module > * Char > * List > * TrName > > in `GHC.Types`, These are already in `GHC.Types`. > and move the other types (eg `Float`, `Double`) out, > so that their type-reps *can* be derived by the normal mechanism. That seems possible. But I don't think it's necessary, as I've explained above. > > > > 3. Let's assume that we really can't clean up this mess. It still seems > > that several TyCons are missing from Data.Typeable.Internal. Like > > promoted nil and cons, and Nat, and Symbol. At the least, we should > > put a loud comment in the export list of GHC.Types saying that > > everything defined there must be accompanied by a definition in > > Data.Typeable.Internal. > > You are right. The above might ameliorate the problem. > If it'd make your kind-equality work easier by all means do this. This isn't holding me up. I just had to shuffle a bunch of `GHC.Types` and `GHC.Prim` stuff around and wanted to do it right, so I had to understand the `Typeable` stuff. And that led to questions. > > > 2. Even more bizarre would be putting TyCon/Module info for GHC.Prim > > stuff (I'm thinking about the super-magical TYPE) right in GHC.Prim. > > But currently `TyCon` uses list and `Char`. Do you want to put them in `GHC.Prim`? No. I want definitions in `GHC.Prim` to depend on `TyCon` and friends, which would remain in `GHC.Types`. This is highly bizarre. But it doesn't seem to break anything. And indeed I have this in my branch (`TYPE` is in `GHC.Prim` but `Levity` is in `GHC.Types`) and nothing complains. > How would that differ, really, from what we have now. > > And `TyCon` and `Module` both require actual code, whereas `GHC.Prim` types have > no code. Yes, my proposal means hard-coding `TyCon`s for `TYPE` and `#` (the only lifted types left in `GHC.Prim` in my branch). These would be `Id`s in `MkId` presumably. > > To respond to your suggestion more clearly I'd need more info > on what you have in mind. > > > 4. `Data.Typeable.Internal` uses `mkGhcTypesTyCon`, which refers to `GHC.Types` > > I don't understand the issue here. `mkGhcTypesTyCon` uses `GHC.Types` as the module whenever it's used. But sometimes it's for `GHC.Prim` types, not `GHC.Types` types. > > > That looks like the tycon's fingerprint is bogus whenever the module is compiled with `-dsuppress-uniques`. But I always understood `-dsuppress-uniques` to be a flag used only to control output, and that it should affect only the pretty-printer. So I'm very dubious of this code. > > Good point. But failing to suppress means that `-ddump-simpl` will show some unique values. Maybe that's ok. It's mainly use to reduce test- suite wobbles. I'm honestly not sure what to do here, but not too bothered either way. But isn't the fingerprint Very Important? As in: don't we rely critically on fingerprints being unique when doing type comparison? If I understand this correctly, the current implementation means that `-dsuppress-uniques` makes the whole `Typeable` story unsound. And `-dsuppress-uniques` is meant to be a pretty-printing flag. To reduce testsuite wibbles, we should just add something to the post- processor we already have. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 27 16:04:31 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Nov 2015 16:04:31 -0000 Subject: [GHC] #11139: Add Semigroup warnings Message-ID: <045.137d4fe03f2b7f30b6016e929e364857@haskell.org> #11139: Add Semigroup warnings -------------------------------------+------------------------------------- Reporter: quchen | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Similar to #8004, do the following for Semigroup/Monoid: 1. Warn when an instance of a class has been given, but the type does not have a certain superclass instance 2. Warn when top-level definitions conflict with future Prelude names -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 27 16:08:38 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Nov 2015 16:08:38 -0000 Subject: [GHC] #11139: Add Semigroup warnings In-Reply-To: <045.137d4fe03f2b7f30b6016e929e364857@haskell.org> References: <045.137d4fe03f2b7f30b6016e929e364857@haskell.org> Message-ID: <060.9788a350184fabd0d47ba3a54bc5ce5c@haskell.org> #11139: Add Semigroup warnings -------------------------------------+------------------------------------- Reporter: quchen | Owner: Type: task | Status: patch Priority: normal | Milestone: 8.0.1 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 Rev(s): Phab:D1539 Wiki Page: | -------------------------------------+------------------------------------- Changes (by quchen): * status: new => patch * differential: => Phab:D1539 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 27 16:13:39 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Nov 2015 16:13:39 -0000 Subject: [GHC] #11140: add command-line option to GHC to dump raw parse trees of Haskell programs Message-ID: <044.9ca7a94e52e643694da7336bc4c35d24@haskell.org> #11140: add command-line option to GHC to dump raw parse trees of Haskell programs -------------------------------------+------------------------------------- Reporter: bollu | Owner: Type: bug | Status: new Priority: low | 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 Rev(s): | Wiki Page: -------------------------------------+------------------------------------- As of now, GHC has no option to dump the parse tree of a given Haskell source file. `-ddump-parsed` only displays the pretty-printed AST structure, and cannot be used to inspect parse trees. An existing implementation of such a feature is present in apply- refact(https://github.com/mpickering/apply-refact) by invoking the tool as `refactor --debug`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 27 19:47:50 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Nov 2015 19:47:50 -0000 Subject: [GHC] #11139: Add Semigroup warnings In-Reply-To: <045.137d4fe03f2b7f30b6016e929e364857@haskell.org> References: <045.137d4fe03f2b7f30b6016e929e364857@haskell.org> Message-ID: <060.d3d0c8b9767fef85029096dd49c6d870@haskell.org> #11139: Add Semigroup warnings -------------------------------------+------------------------------------- Reporter: quchen | Owner: quchen Type: task | Status: patch Priority: normal | Milestone: 8.0.1 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 Rev(s): Phab:D1539 Wiki Page: | -------------------------------------+------------------------------------- Changes (by quchen): * owner: => quchen -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 27 19:48:33 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Nov 2015 19:48:33 -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.429d6c0f4d098be7fd94d9f1620568c7@haskell.org> #10365: Implement Semigroup as a superclass of Monoid Proposal (Phase 1) -------------------------------------+------------------------------------- Reporter: gidyn | Owner: quchen Type: feature request | Status: closed Priority: high | Milestone: 8.0.1 Component: libraries/base | Version: 7.10.1 Resolution: fixed | 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 Wiki Page: | prime:Libraries/Proposals/SemigroupMonoid| -------------------------------------+------------------------------------- Comment (by quchen): AMP for Semigroup is in review status on Phab:D1539, Trac #11139 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 27 19:50:42 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Nov 2015 19:50:42 -0000 Subject: [GHC] #11139: Add Semigroup warnings In-Reply-To: <045.137d4fe03f2b7f30b6016e929e364857@haskell.org> References: <045.137d4fe03f2b7f30b6016e929e364857@haskell.org> Message-ID: <060.909fa408543aeacd7eebd5a80c36034f@haskell.org> #11139: Add Semigroup warnings -------------------------------------+------------------------------------- Reporter: quchen | Owner: quchen Type: task | Status: patch Priority: normal | Milestone: 8.0.1 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 Rev(s): Phab:D1539 Wiki Page: | -------------------------------------+------------------------------------- Changes (by quchen): * cc: ekmett (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 27 22:30:09 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Nov 2015 22:30:09 -0000 Subject: [GHC] #11141: Better error message when instance signature is incorrect Message-ID: <045.f1d2b4f44677ae9d82fd3cf9ea1acdfd@haskell.org> #11141: Better error message when instance signature is incorrect -------------------------------------+------------------------------------- Reporter: ezyang | 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: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I was recently trying to solve an ambiguity error in a type class instance I was writing, and ended up with some code that looked like this (the ambiguity error has been eliminated for simplicity): {{{ {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE InstanceSigs #-} {-# LANGUAGE ScopedTypeVariables #-} module A where data F a = F a instance Show a => Show (F a) where show :: forall a. Show a => F a -> String show (F x) = show x }}} This instance signature is incorrect: it's not necessary to add a universal quantifier to scope over type variables defined in the instance head; they are automatically in scope. But GHC unhelpfully reports: {{{ ezyang at sabre:~$ Dev/ghc-7.10.2/usr/bin/ghci A.hs GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling A ( A.hs, interpreted ) A.hs:8:13: Could not deduce (Show a0) from the context (Show a) bound by the type signature for show :: Show a => F a -> String at A.hs:8:13-45 The type variable ?a0? is ambiguous When checking that: forall a. Show a => forall a1. Show a1 => F a1 -> String is more polymorphic than: forall a. Show a => F a -> String When checking that instance signature for ?show? is more general than its signature in the class Instance sig: forall a. Show a => forall a1. Show a1 => F a1 -> String Class sig: forall a. Show a => F a -> String In the instance declaration for ?Show (F a)? Failed, modules loaded: none. }}} Why did I get the wrong idea about how instance signatures work? Well, GHC doesn't warn if you write this: {{{ instance Show a => Show (F a) where show :: Show a => F a -> String show (F x) = show x }}} Because this turns into a full type signature 'Show a, Show a => F a -> String' (the first a and the second a end up getting unified.) I'm not sure if it should warn; it's an easy mistake to make if you are treating instance methods like plain function definitions (of course you have to write the full type signature...) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 27 23:03:50 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Nov 2015 23:03:50 -0000 Subject: [GHC] #11142: Type-level skolem capture leads to core lint error Message-ID: <047.20b4d77975ac1b8abb3a0fd9c718929f@haskell.org> #11142: Type-level skolem capture leads to core lint error -------------------------------------+------------------------------------- Reporter: goldfire | 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: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following ill-typed code is accepted. {{{ {-# LANGUAGE PolyKinds, RankNTypes #-} module Bug where data SameKind :: k -> k -> * foo :: forall b. (forall (a :: k). SameKind a b) -> () foo = undefined }}} Indeed, Core Lint catches this. But the type-checker should. The problem is that `SameKind` forces `a` and `b` to have the same kind. But they can't, because `a`'s kind is out of scope at `b`'s binding site. The program should be rejected. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 27 23:26:05 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Nov 2015 23:26:05 -0000 Subject: [GHC] #11122: Ambiguous inferred type causes a panic In-Reply-To: <049.1088c8ba6b56b1d64805be5246c7971a@haskell.org> References: <049.1088c8ba6b56b1d64805be5246c7971a@haskell.org> Message-ID: <064.2d47e00cfea0741f3327249ee0cb857d@haskell.org> #11122: Ambiguous inferred type causes a panic -------------------------------------+------------------------------------- Reporter: tuplanolla | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: duplicate | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10615 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): Here is a self-contained reproducer. {{{#!hs {-# LANGUAGE NoMonomorphismRestriction #-} {-# LANGUAGE PartialTypeSignatures #-} module T11122 where data Parser a instance Functor Parser where fmap = undefined many p = undefined digit = undefined parseTest = undefined -------------------------------------------- parser :: Parser _ --parser :: Parser Int parser = read <$> many digit data Wrapper = Wrapper Int deriving Show wrapperParser = Wrapper <$> parser main :: IO () main = parseTest wrapperParser "0" }}} This is the error message that HEAD generates: {{{ $ ghc-7.11.20151123 Test.hs [1 of 1] Compiling Test ( Test.hs, Test.o ) Test.hs:21:1: error: No instance for (Read t) When checking that ?parser? has the inferred type parser :: forall t. Parser t Probable cause: the inferred type is ambiguous Test.hs:28:18: error: Ambiguous type variable ?f0? arising from a use of ?wrapperParser? prevents the constraint ?(Functor f0)? from being solved. Probable fix: use a type annotation to specify what ?f0? should be. These potential instances exist: instance Functor (Array i) -- Defined in ?GHC.Arr? instance Functor IO -- Defined in ?GHC.Base? instance Functor Parser -- Defined at Test.hs:8:10 ...plus four others (use -fprint-potential-instances to see them all) In the first argument of ?parseTest?, namely ?wrapperParser? In the expression: parseTest wrapperParser "0" In an equation for ?main?: main = parseTest wrapperParser "0" }}} I don't know if that means the problem is fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 28 08:40:00 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Nov 2015 08:40:00 -0000 Subject: [GHC] #11143: Feature request: Add index/read/write primops with byte offset for ByteArray# Message-ID: <048.a76989facca9d2ef0c59d6b7bfd86029@haskell.org> #11143: Feature request: Add index/read/write primops with byte offset for ByteArray# -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.2.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): | Wiki Page: -------------------------------------+------------------------------------- Currently, primops for indexing `ByteArray#` and reading/writing `MutableByteArray#` have the following form: {{{#!hs indexTYPEArray# :: ByteArray# -> Int# -> TYPE# readTYPEArray# :: MutableByteArray# s -> Int# -> State# s -> (#State# s, TYPE##) writeTYPEArray# :: MutableByteArray# s -> Int# -> TYPE# -> State# s -> State# s }}} where second argument of type `Int#` is an offset measured in terms of the size of `TYPE#`. This is inconvinient if I want to store values of different types inside `ByteArray#`: I have to read values of type `Int8` and then glue them together with some bitwise operations. I suggest adding number of primops, similar to existing ones, which would accept offset in bytes from the start of the `ByteArray#`: {{{#!hs -- | Read 8-bit integer; offset in bytes. indexByteInt8Array# :: ByteArray# -> Int# -> Int# -- | Read 16-bit integer; offset in bytes. indexByteInt16Array# :: ByteArray# -> Int# -> Int# -- | Read 32-bit integer; offset in bytes. indexByteInt32Array# :: ByteArray# -> Int# -> Int# -- | Read 8-bit integer; offset in bytes. readInt8Array# :: MutableByteArray# s -> Int# -> State# s -> (#State# s, Int##) -- | Read 16-bit integer; offset in bytes. readInt16Array# :: MutableByteArray# s -> Int# -> State# s -> (#State# s, Int##) -- | Read 32-bit integer; offset in bytes. readInt32Array# :: MutableByteArray# s -> Int# -> State# s -> (#State# s, Int##) }}} and so on... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 28 11:16:07 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Nov 2015 11:16:07 -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.6f98d04b44423cacd895a4dc9002095c@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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mboes): * cc: mboes (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 28 18:04:14 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Nov 2015 18:04:14 -0000 Subject: [GHC] #11135: Migrate more of Data.Functor.* from transformers to base. In-Reply-To: <042.83233f22e5175dafd0dee94fc12c4d5f@haskell.org> References: <042.83233f22e5175dafd0dee94fc12c4d5f@haskell.org> Message-ID: <057.3d845d89bdf27c4fc7a190b2f1190373@haskell.org> #11135: Migrate more of Data.Functor.* from transformers to base. -------------------------------------+------------------------------------- Reporter: hvr | Owner: strake888 Type: task | Status: new Priority: highest | Milestone: 8.0.1 Component: libraries/base | 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by strake888): * owner: => strake888 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 28 18:39:22 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Nov 2015 18:39:22 -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.b759e788a5a853de71ed8138fdc313f5@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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:4 jstolarek]: > But I only get the first one. Is this expected? I think so. GHC gives up if type-checking the type & class definitions fails. Otherwise, who knows what terrible type errors might happen? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 28 18:52:44 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Nov 2015 18:52:44 -0000 Subject: [GHC] #11144: Custom type errors need tidying Message-ID: <047.a70ace9deaae48e87a4a0b7813d45f8c@haskell.org> #11144: Custom type errors need tidying -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is an excerpt from `testsuite/tests/typecheck/should_fail/CustomTypeErrors02.stderr`: {{{ CustomTypeErrors02.hs:17:1: error: The type 'a_aES -> a_aES' cannot be represented as an integer. When checking that ?err? has the inferred type err :: (TypeError ...) }}} We should tidy these types before printing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 28 21:51:11 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Nov 2015 21:51:11 -0000 Subject: [GHC] #2940: Do CSE after CorePrep In-Reply-To: <046.ba154de3cf0c400fb0723e1948282304@haskell.org> References: <046.ba154de3cf0c400fb0723e1948282304@haskell.org> Message-ID: <061.04a4ee0e92808023acb880356a2ef031@haskell.org> #2940: Do CSE after CorePrep -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: lowest | Milestone: 8.0.1 Component: Compiler | Version: 6.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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Simon, I was experimenting with CSE and unless I'm missing something I think current CSE is basically useless and we can just remove it. As far as I understand from the implementation, current CSE implementation never introduces a let binding. So for example if I have something like: {{{#!haskell g x = (x + 1, x + 1) }}} Current implementation never does CSE here. What's worse is that even if I have a let binding like this: {{{#!haskell g x = let x_1 = x + 1 in (x_1, x + 1) }}} Most of the time CSE can't do anything, because some other pass inlines/unfolds `x_1` here(even with -O0). `g` above is compiled to this: {{{#!haskell g :: Int -> (Int, Int) g = \ (x_atS :: Int) -> (case x_atS of _ { I# x_a1IL -> I# (+# x_a1IL 1#) }, case x_atS of _ { I# x_a1IL -> I# (+# x_a1IL 1#) }) }}} See how let binding is removed. CSE can't do anything here. Funny thing is even if I mark this let binding as `NOINLINE` CSE can't work, because of Note [CSE for INLINE and NOINLINE]. This is what happens when I mark `x_1` as `NOINLINE`: {{{#!haskell g' :: Int -> (Int, Int) g' = \ (x_av2 :: Int) -> let { x_1_s1Jd :: Int x_1_s1Jd = case x_av2 of _ { I# x_a1IL -> I# (+# x_a1IL 1#) } } in (case x_av2 of _ { I# x_a1IL -> I# (+# x_a1IL 1#) }, x_1_s1Jd) }}} There's a clear CSE opportunity missed because of Note [CSE for INLINE and NOINLINE]. So unless we actually run this after `CorePrep` it just can't do anything. I tried on a couple of examples and it seems like current CSE implementation actually maintains invariants at least some of the time. For example, it works find on the code in the code above. Do we have something like `CoreLint` but fore `CorePrep` invariants? ---- In the examples I tried CSE never worked before the `CorePrep` step. After `CorePrep` it worked some of the time. For example, `g` above is compiled to this: {{{#!haskell -- RHS size: {terms: 17, types: 8, coercions: 0} g :: Int -> (Int, Int) g = \ (x_s2nV :: Int) -> let { sat_s2o3 :: Int sat_s2o3 = case x_s2nV of wild_s2o0 { I# x1_s2o1 -> case +# x1_s2o1 1# of sat_s2o2 { __DEFAULT -> I# sat_s2o2 } } } in let { sat_s2nZ :: Int sat_s2nZ = sat_s2o3 } in (sat_s2o3, sat_s2o3) }}} `h` also CSEs nicely if we run it after `CorePrep`: {{{#!haskell -- RHS size: {terms: 23, types: 8, coercions: 0} h :: Int# -> (Int, Int) h = \ (x_s2nq :: Int#) -> case +# x_s2nq 1# of sat_s2nt { __DEFAULT -> case *# sat_s2nt 2# of sat_s2nu { __DEFAULT -> let { sat_s2nv :: Int sat_s2nv = I# sat_s2nu } in case sat_s2nt of sat_s2nr { __DEFAULT -> let { sat_s2ns :: Int sat_s2ns = I# sat_s2nt } in (sat_s2ns, sat_s2nv) } } } }}} It doesn't work on `rev`, because of how `CorePrep` generates a program without any CSE opportunity: {{{#!haskell -- RHS size: {terms: 23, types: 19, coercions: 0} Main.rev :: [GHC.Types.Bool] -> [GHC.Types.Bool] Main.rev = \ (xs_s2nl :: [GHC.Types.Bool]) -> let { sat_s2np :: [GHC.Types.Bool] sat_s2np = case GHC.List.reverse1 @ GHC.Types.Bool xs_s2nl (GHC.Types.[] @ GHC.Types.Bool) of sat_s2no { __DEFAULT -> GHC.List.filter @ GHC.Types.Bool (GHC.Base.id @ GHC.Types.Bool) sat_s2no } } in case GHC.List.reverse1 @ GHC.Types.Bool xs_s2nl (GHC.Types.[] @ GHC.Types.Bool) of sat_s2nm { __DEFAULT -> case GHC.List.reverse1 @ GHC.Types.Bool sat_s2nm (GHC.Types.[] @ GHC.Types.Bool) of sat_s2nn { __DEFAULT -> GHC.Base.++ @ GHC.Types.Bool sat_s2nn sat_s2np } } }}} Ideally we'd like to generate a binding for `GHC.List.reverse1 @ GHC.Types.Bool xs_s2nl (GHC.Types.[] @ GHC.Types.Bool)` but since this expression is not bound to a let-binder we can't CSE. (This would work if had the invariant of having only variables(and literals) in scrutinee position) For the record, this is what's generated by CSE after `CorePrep`: {{{#!haskell rev :: [Bool] -> [Bool] rev = \ (xs_s2nl :: [Bool]) -> let { sat_s2np :: [Bool] sat_s2np = case reverse1 @ Bool xs_s2nl ([] @ Bool) of sat_s2no { __DEFAULT -> filter @ Bool (id @ Bool) sat_s2no } } in case reverse1 @ Bool xs_s2nl ([] @ Bool) of sat_s2nm { __DEFAULT -> case reverse1 @ Bool sat_s2nm ([] @ Bool) of sat_s2nn { __DEFAULT -> ++ @ Bool sat_s2nn sat_s2np } } }}} ---- I want to work on running CSE after CorePrep, but before that I'm planning implementing a CoreLint-like pass for checking CorePrep invariants. Simon, does that make sense? Any ideas? Am I missing anything in my observations? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 29 04:48:35 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Nov 2015 04:48:35 -0000 Subject: [GHC] #7478: setSessionDynFlags does not always work In-Reply-To: <044.a3899b7bd6c11925eee15996dee68777@haskell.org> References: <044.a3899b7bd6c11925eee15996dee68777@haskell.org> Message-ID: <059.72a3757a0d10e8e21b97f57b04f949bf@haskell.org> #7478: setSessionDynFlags does not always work -------------------------------------+------------------------------------- Reporter: edsko | Owner: bherzog Type: bug | Status: closed Priority: high | 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: ghc-api/T7478 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1017 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): As a data point, I just ran into this because T7478 unexpectedly passes on my Mac. So perhaps the test should be updated... but I have no idea about this end of the operation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 29 05:12:01 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Nov 2015 05:12:01 -0000 Subject: [GHC] #11145: Template Haskell quotes of data instance GADTs is totally broken Message-ID: <047.f4269d89570623ef8681f049d5eec6b8@haskell.org> #11145: Template Haskell quotes of data instance GADTs is totally broken -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new 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 Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When I say {{{ data family Fuggle x y [d| data instance Fuggle Int (Maybe (a,b)) where MkFuggle :: Fuggle Int (Maybe Bool) |] }}} I get (with `-ddump-splices`) {{{ [d| data instance Fuggle Int (Maybe (a_ajz6, b_ajz7)) where MkFuggle_ajz5 :: Fuggle Int (Maybe Bool) |] ======> data instance Fuggle Int (Maybe (a_ajAf, b_ajAg)) = (b_ajAg ~ Maybe Bool, a_ajAf ~ Int) => MkFuggle_ajAe }}} But that's not at all what I said! Admittedly, what I said was garbage, but it should fail outright. Is this addressed by Phab:D1465? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 29 09:46:58 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Nov 2015 09:46:58 -0000 Subject: [GHC] #11111: error message for ":show" in GHCi does not show "paths" In-Reply-To: <048.d85779489b94a6313e0fda1d4a24b87c@haskell.org> References: <048.d85779489b94a6313e0fda1d4a24b87c@haskell.org> Message-ID: <063.c70a7a1ea5bcb911427b04167262a087@haskell.org> #11111: error message for ":show" in GHCi does not show "paths" -------------------------------------+------------------------------------- Reporter: massysett | Owner: bgamari Type: bug | Status: new 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: #11110 | Differential Rev(s): Phab:D1538 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * keywords: newcomer => * owner: => bgamari * differential: => Phab:D1538 * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 29 10:27:21 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Nov 2015 10:27:21 -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.0271b847f065796f45d41c59b806d5fe@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 Rev(s): Wiki Page: | ---------------------------------------+------------------------------ Comment (by andrewufrank): a simpler example - pureMD5 does give the same result (again on an armhf with ghc 7.10.2.20151030 {{{ Glasgow Haskell Compiler, Version 7.10.2.20151030, stage 2 booted by GHC version 7.10.2.20151030 Using binary package database: /usr/lib/ghc/package.conf.d/package.cache Using binary package database: /home/frank/.ghc/arm- linux-7.10.2.20151030/package.conf.d/package.cache wired-in package ghc-prim mapped to ghc- prim-0.4.0.0-087c70fa92d0fbd8056dbc5853433ed1 wired-in package integer-gmp mapped to integer- gmp-1.0.0.0-c6adc6639382c14317a5926d860e24d8 wired-in package base mapped to base-4.8.2.0-6d4788b4fac4bef0277f64a0a9ece0ab wired-in package rts mapped to builtin_rts wired-in package template-haskell mapped to template- haskell-2.10.0.0-96406e1c046e7d3794950273552e30d5 wired-in package ghc mapped to ghc-7.10.2.20151030-28f5d1fe7d4210612a8dc6732b57dced wired-in package dph-seq not found. wired-in package dph-par not found. Hsc static flags: *** Deleting temp files: Deleting: *** Deleting temp dirs: Deleting: ghc: no input files }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 29 12:21:57 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Nov 2015 12:21:57 -0000 Subject: [GHC] #11102: `ghc --supported-extension` shall not list `TemplateHaskell` when unsupported In-Reply-To: <042.75105e05b4b7229d1c36f2c44b9a694f@haskell.org> References: <042.75105e05b4b7229d1c36f2c44b9a694f@haskell.org> Message-ID: <057.08f28f6e11814c722da7920a9abf6cca@haskell.org> #11102: `ghc --supported-extension` shall not list `TemplateHaskell` when unsupported -------------------------------------+------------------------------------- Reporter: hvr | Owner: bgamari 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 Rev(s): phab:D1484 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"85fcd035f73679927a0539d5f6c9b919517365e1/ghc" 85fcd035/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="85fcd035f73679927a0539d5f6c9b919517365e1" Implement new -XTemplateHaskellQuotes pragma Since f16ddcee0c64a92ab911a7841a8cf64e3ac671fd / D876, `ghc-stage1` supports a subset of `-XTemplateHaskell`, but since we need Cabal to be able detect (so `.cabal` files can be specified accordingly, see also GHC #11102 which omits `TemplateHaskell` from `--supported-extensions`) whether GHC provides full or only partial `-XTemplateHaskell` support, the proper way to accomplish this is to split off the quotation/non-splicing `TemplateHaskell` feature-subset into a new language pragma `TemplateHaskellQuotes`. Moreover, `-XTemplateHaskellQuotes` is considered safe under SafeHaskell This addresses #11121 Reviewers: goldfire, ezyang, dterei, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1511 GHC Trac Issues: #11121 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 29 12:21:57 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Nov 2015 12:21:57 -0000 Subject: [GHC] #11121: Introduce `-XTemplateHaskellQuotes` pragma for subset of TH In-Reply-To: <042.c278176d2dd239200103849cc54d10cc@haskell.org> References: <042.c278176d2dd239200103849cc54d10cc@haskell.org> Message-ID: <057.69f10bb0c94af75171360356149d370e@haskell.org> #11121: Introduce `-XTemplateHaskellQuotes` pragma for subset of TH -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: patch 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: #10382, #11102 | Differential Rev(s): Phab:D1511 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"85fcd035f73679927a0539d5f6c9b919517365e1/ghc" 85fcd035/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="85fcd035f73679927a0539d5f6c9b919517365e1" Implement new -XTemplateHaskellQuotes pragma Since f16ddcee0c64a92ab911a7841a8cf64e3ac671fd / D876, `ghc-stage1` supports a subset of `-XTemplateHaskell`, but since we need Cabal to be able detect (so `.cabal` files can be specified accordingly, see also GHC #11102 which omits `TemplateHaskell` from `--supported-extensions`) whether GHC provides full or only partial `-XTemplateHaskell` support, the proper way to accomplish this is to split off the quotation/non-splicing `TemplateHaskell` feature-subset into a new language pragma `TemplateHaskellQuotes`. Moreover, `-XTemplateHaskellQuotes` is considered safe under SafeHaskell This addresses #11121 Reviewers: goldfire, ezyang, dterei, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1511 GHC Trac Issues: #11121 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 29 12:21:57 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Nov 2015 12:21:57 -0000 Subject: [GHC] #10249: GHCi leaky abstraction: error message mentions `ghciStepIO` In-Reply-To: <051.818ff8bc84030bedfa7f9663d4a7c3ef@haskell.org> References: <051.818ff8bc84030bedfa7f9663d4a7c3ef@haskell.org> Message-ID: <066.8e54e3ff6acf568f2b37a7e0a57bd4d6@haskell.org> #10249: GHCi leaky abstraction: error message mentions `ghciStepIO` -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: thomie Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | ghci/scripts/T10249 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1527, Wiki Page: | Phab:D1528 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"71c0cc1531c3e548e47f435432ed31cb79512607/ghc" 71c0cc15/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="71c0cc1531c3e548e47f435432ed31cb79512607" GHCi should not defer typed holes In the function `tcUserStmt` in compiler/typecheck/TcRnDriver.hs, before going over the different ways ('plans') to lift an expression typed at the prompt into the GHCi monad, `Opt_DeferTypeErrors` is disabled. Here is the accompanying comment: ``` -- Ensure that type errors don't get deferred when type checking the -- naked expression. Deferring type errors here is unhelpful because the -- expression gets evaluated right away anyway. It also would potentially -- emit redundant type-error warnings, one from each plan. ; plan <- unsetGOptM Opt_DeferTypeErrors $ ``` Since `Opt_DeferTypeErrors` implies `Opt_DeferTypedHoles`, `Opt_DeferTypedHoles` should be disabled here as well. This improves the error message for T10248 (it doesn't mention ghciStepIO anymore). This is a partial fix for #10249, and a complete fix for #11130. Depends on D1526 Reviewers: simonpj, austin, bgamari Reviewed By: simonpj Subscribers: simonpj Differential Revision: https://phabricator.haskell.org/D1527 GHC Trac Issues: #10249, #11130 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 29 12:21:57 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Nov 2015 12:21:57 -0000 Subject: [GHC] #11130: GHCi should not defer typed holes In-Reply-To: <045.84e51b5d00d3a4acd23d3673c087a32a@haskell.org> References: <045.84e51b5d00d3a4acd23d3673c087a32a@haskell.org> Message-ID: <060.320bc8cdbd5d6eabd3d00e3634f43f5f@haskell.org> #11130: GHCi should not defer typed holes -------------------------------------+------------------------------------- Reporter: thomie | Owner: thomie Type: bug | 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: Incorrect | Test Case: warning at compile-time | ghci/scripts/T10248 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1527 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"71c0cc1531c3e548e47f435432ed31cb79512607/ghc" 71c0cc15/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="71c0cc1531c3e548e47f435432ed31cb79512607" GHCi should not defer typed holes In the function `tcUserStmt` in compiler/typecheck/TcRnDriver.hs, before going over the different ways ('plans') to lift an expression typed at the prompt into the GHCi monad, `Opt_DeferTypeErrors` is disabled. Here is the accompanying comment: ``` -- Ensure that type errors don't get deferred when type checking the -- naked expression. Deferring type errors here is unhelpful because the -- expression gets evaluated right away anyway. It also would potentially -- emit redundant type-error warnings, one from each plan. ; plan <- unsetGOptM Opt_DeferTypeErrors $ ``` Since `Opt_DeferTypeErrors` implies `Opt_DeferTypedHoles`, `Opt_DeferTypedHoles` should be disabled here as well. This improves the error message for T10248 (it doesn't mention ghciStepIO anymore). This is a partial fix for #10249, and a complete fix for #11130. Depends on D1526 Reviewers: simonpj, austin, bgamari Reviewed By: simonpj Subscribers: simonpj Differential Revision: https://phabricator.haskell.org/D1527 GHC Trac Issues: #10249, #11130 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 29 12:50:41 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Nov 2015 12:50:41 -0000 Subject: [GHC] #11121: Introduce `-XTemplateHaskellQuotes` pragma for subset of TH In-Reply-To: <042.c278176d2dd239200103849cc54d10cc@haskell.org> References: <042.c278176d2dd239200103849cc54d10cc@haskell.org> Message-ID: <057.c9a72fc393f705e60df36fe7e41ef000@haskell.org> #11121: Introduce `-XTemplateHaskellQuotes` pragma for subset of TH -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: patch 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: #10382, #11102 | Differential Rev(s): Phab:D1511 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 29 13:56:59 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Nov 2015 13:56:59 -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.f62f8878b916a8fd78e524179b6fe820@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 Rev(s): Wiki Page: | ---------------------------------------+------------------------------ Comment (by andrewufrank): the problem in pureMD5 seems to be in the part {{{ #ifdef FastWordExtract getNthWord n b = inlinePerformIO (unsafeUseAsCString b (flip peekElemOff n . castPtr)) #else getNthWord :: Int -> B.ByteString -> Word32 getNthWord n = right . G.runGet G.getWord32le . B.drop (n * sizeOf (undefined :: Word32)) where right x = case x of Right y -> y #endif -- {-# INLINE getNthWord #-} }}} i have removed the inline pragma and it compiles. the armhf is not FastWordExtract (at least not set in the cabal) and thus uses code which is typically for the intel processor not used. i hope this helps to fix the problem. thank you! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 29 14:27:12 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Nov 2015 14:27:12 -0000 Subject: [GHC] #11028: Refactor ConDecl In-Reply-To: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> References: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> Message-ID: <061.9f6d78bc353dc39fa4b262c09df2ce45@haskell.org> #11028: Refactor ConDecl -------------------------------------+------------------------------------- Reporter: simonpj | Owner: alanz 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alanz): I am now using `rnHsSigType` to rename the RHS of a `ConDeclGADT`, passing in a `ConDeclCtx`. This ends up calling {{{#!hs rnHsTyKi _ doc ty@(HsForAllTy { hst_bndrs = tyvars, hst_body = tau }) = bindLHsTyVarBndrs doc Nothing tyvars $ \ tyvars' -> do { (tau', fvs) <- rnLHsType doc tau ; warnUnusedForAlls (inTypeDoc ty) tyvars' fvs ; return ( HsForAllTy { hst_bndrs = tyvars', hst_body = tau' } , fvs) } }}} `warnUnusedForAlls` does not use the passed in context, but `inTypeDoc ty` instead, causing tests such as T5331 to fail. Possible solutions seem to be 1. use the passed in context for the `warnUnusedForalls`, which has the disadvantage of giving a less precise location. 2. Combine the `doc` and the `inTypeDoc ty` contexts for the warning. 3. Update the expected warning in the test, the forall context is good enough. Which is the best option, or is there another solution? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 29 14:50:19 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Nov 2015 14:50:19 -0000 Subject: [GHC] #1262: RecursiveDo in Template Haskell In-Reply-To: <062.2857e038d8ba06eaa6e83d19ada8ff7e@haskell.org> References: <062.2857e038d8ba06eaa6e83d19ada8ff7e@haskell.org> Message-ID: <077.28785c09a793394b956394ff1080e094@haskell.org> #1262: RecursiveDo in Template Haskell -------------------------------------+------------------------------------- Reporter: philip.weaver@? | Owner: Type: feature request | Status: new Priority: normal | Milestone: ? Component: Template Haskell | Version: 6.6 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by massysett): * cc: massysett (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 29 15:37:59 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Nov 2015 15:37:59 -0000 Subject: [GHC] #11130: GHCi should not defer typed holes In-Reply-To: <045.84e51b5d00d3a4acd23d3673c087a32a@haskell.org> References: <045.84e51b5d00d3a4acd23d3673c087a32a@haskell.org> Message-ID: <060.2afc7e971947a71923d2ebec1092667f@haskell.org> #11130: GHCi should not defer typed holes -------------------------------------+------------------------------------- Reporter: thomie | Owner: thomie Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | ghci/scripts/T10248 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1527 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 29 15:48:35 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Nov 2015 15:48:35 -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.54f0e12391f38ad8c17eaea0e746d5cc@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 Rev(s): Phab:D343 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * cc: osa1 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 29 15:57:38 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Nov 2015 15:57:38 -0000 Subject: [GHC] #11144: Custom type errors need tidying In-Reply-To: <047.a70ace9deaae48e87a4a0b7813d45f8c@haskell.org> References: <047.a70ace9deaae48e87a4a0b7813d45f8c@haskell.org> Message-ID: <062.6b0b2b3166257a3ef4a4012db98cf8b0@haskell.org> #11144: Custom type errors need tidying -------------------------------------+------------------------------------- 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: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1547 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * differential: => Phab:D1547 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 29 20:29:44 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Nov 2015 20:29:44 -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.e44d1acf1afec07a4bbbd346d6b38379@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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mimi.vx): proposed patch by Scot Bahling - https://github.com/mimi1vx/terminfo/commit/68674ed51d94bdee6ea3ea10c1494352c8143da2.patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 29 20:38:01 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Nov 2015 20:38:01 -0000 Subject: [GHC] #11132: Remove deprecated quasiquote syntax In-Reply-To: <049.b5cabc5003b189dcfb4647d31724ba19@haskell.org> References: <049.b5cabc5003b189dcfb4647d31724ba19@haskell.org> Message-ID: <064.2aea17ee1b39418c070b388cca518cbc@haskell.org> #11132: Remove deprecated quasiquote syntax -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering Type: task | 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 Rev(s): Phab:D1530 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: This has been merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 29 22:26:05 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Nov 2015 22:26:05 -0000 Subject: [GHC] #11111: error message for ":show" in GHCi does not show "paths" In-Reply-To: <048.d85779489b94a6313e0fda1d4a24b87c@haskell.org> References: <048.d85779489b94a6313e0fda1d4a24b87c@haskell.org> Message-ID: <063.8a90008cd53e3bb0cbb1343c65db961c@haskell.org> #11111: error message for ":show" in GHCi does not show "paths" -------------------------------------+------------------------------------- Reporter: massysett | Owner: bgamari Type: bug | Status: new 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: #11110 | Differential Rev(s): Phab:D1538 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"f101a822966c52e96438db52c5fff2c7384f0c4c/ghc" f101a822/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f101a822966c52e96438db52c5fff2c7384f0c4c" ghci: Refactor handling of :show In so doing ensure that the help text can't fall out of sync with the implementation. Test Plan: Validate and play in ghci Reviewers: austin, thomie Reviewed By: austin, thomie Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1538 GHC Trac Issues: #11111 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 29 22:26:05 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Nov 2015 22:26:05 -0000 Subject: [GHC] #8004: Applicative/Monad proposal related warnings (AMP phase 1) In-Reply-To: <045.ee77ea6713da1cec5c3314c4ae999d7f@haskell.org> References: <045.ee77ea6713da1cec5c3314c4ae999d7f@haskell.org> Message-ID: <060.f9df1369aa6aa56f8402a33e908f4440@haskell.org> #8004: Applicative/Monad proposal related warnings (AMP phase 1) -------------------------------------+------------------------------------- Reporter: quchen | Owner: quchen Type: feature request | Status: closed Priority: high | Milestone: 7.8.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: #4834 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"290def72f54db7969258b4541aaefc87b54ce448/ghc" 290def72/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="290def72f54db7969258b4541aaefc87b54ce448" Implement warnings for Semigroups as parent of Monoid This patch is similar to the AMP patch (#8004), which offered two functions: 1. Warn when an instance of a class has been given, but the type does not have a certain superclass instance 2. Warn when top-level definitions conflict with future Prelude names These warnings are issued as part of the new `-Wcompat` warning group. Reviewers: hvr, ekmett, austin, bgamari Reviewed By: hvr, ekmett, bgamari Subscribers: ekmett, thomie Differential Revision: https://phabricator.haskell.org/D1539 GHC Trac Issues: #11139 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 29 22:26:05 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Nov 2015 22:26:05 -0000 Subject: [GHC] #11139: Add Semigroup warnings In-Reply-To: <045.137d4fe03f2b7f30b6016e929e364857@haskell.org> References: <045.137d4fe03f2b7f30b6016e929e364857@haskell.org> Message-ID: <060.86815dd84d51b06298839b0a839a2790@haskell.org> #11139: Add Semigroup warnings -------------------------------------+------------------------------------- Reporter: quchen | Owner: quchen Type: task | Status: patch Priority: normal | Milestone: 8.0.1 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 Rev(s): Phab:D1539 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"290def72f54db7969258b4541aaefc87b54ce448/ghc" 290def72/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="290def72f54db7969258b4541aaefc87b54ce448" Implement warnings for Semigroups as parent of Monoid This patch is similar to the AMP patch (#8004), which offered two functions: 1. Warn when an instance of a class has been given, but the type does not have a certain superclass instance 2. Warn when top-level definitions conflict with future Prelude names These warnings are issued as part of the new `-Wcompat` warning group. Reviewers: hvr, ekmett, austin, bgamari Reviewed By: hvr, ekmett, bgamari Subscribers: ekmett, thomie Differential Revision: https://phabricator.haskell.org/D1539 GHC Trac Issues: #11139 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 29 22:31:15 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Nov 2015 22:31:15 -0000 Subject: [GHC] #11111: error message for ":show" in GHCi does not show "paths" In-Reply-To: <048.d85779489b94a6313e0fda1d4a24b87c@haskell.org> References: <048.d85779489b94a6313e0fda1d4a24b87c@haskell.org> Message-ID: <063.3b6e617c9f90949a7cce6783920a11cb@haskell.org> #11111: error message for ":show" in GHCi does not show "paths" -------------------------------------+------------------------------------- Reporter: massysett | Owner: bgamari Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: GHCi | 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: #11110 | Differential Rev(s): Phab:D1538 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: Fixed with the above commit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 29 22:32:49 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Nov 2015 22:32:49 -0000 Subject: [GHC] #11139: Add Semigroup warnings In-Reply-To: <045.137d4fe03f2b7f30b6016e929e364857@haskell.org> References: <045.137d4fe03f2b7f30b6016e929e364857@haskell.org> Message-ID: <060.d0e0882820b4f474af293ed505aea585@haskell.org> #11139: Add Semigroup warnings -------------------------------------+------------------------------------- Reporter: quchen | Owner: quchen Type: task | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1539 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Done. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 30 01:20:07 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Nov 2015 01:20:07 -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.32a4fed3239e5fed7987a305045f73ed@haskell.org> #10902: Refactor type families in Template Haskell -------------------------------------+------------------------------------- Reporter: goldfire | Owner: johnleo 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by johnleo): Proposal: In `ghc/libraries/template-haskell/Language/Haskell/TH/Syntax.hs` create a new data type: {{{#!hs data TypeFamilyBase = TypeFamilyBase Name [TyVarBndr] FamilyResultSig (Maybe InjectivityAnn) }}} In `data Dec` in the same file replace the definitions of `OpenTypeFamilyD` and `ClosedTypeFamilyD` with the following: {{{#!hs | OpenTypeFamilyD TypeFamilyBase | ClosedTypeFamilyD TypeFamilyBase [TySynEqn] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 30 07:12:03 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Nov 2015 07:12:03 -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.bafafdc423cff50d03cac267d55a7498@haskell.org> #10902: Refactor type families in Template Haskell -------------------------------------+------------------------------------- Reporter: goldfire | Owner: johnleo 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jstolarek): That looks good. Although I would prefer the new data type to be called `TypeFamilyHead` (as Richard proposed) rather than `TypeFamilyBase`. I find it more intuitive - after all the new data type stores the contents of type family head! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 30 10:06:32 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Nov 2015 10:06:32 -0000 Subject: [GHC] #11134: Limit frequency of idle GCs In-Reply-To: <047.b7adbd5e9207ae18bb8e48502cfb8e5f@haskell.org> References: <047.b7adbd5e9207ae18bb8e48502cfb8e5f@haskell.org> Message-ID: <062.509504ffb70c910f6a5e996bfd018a07@haskell.org> #11134: Limit frequency of idle GCs -------------------------------------+------------------------------------- Reporter: dcturner | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): Yes, sounds like a good idea to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 30 10:50:44 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Nov 2015 10:50:44 -0000 Subject: [GHC] #11146: Manual eta expansion leads to orders of magnitude less allocations Message-ID: <046.e20145b8e1978b205b8160f6e3f4254c@haskell.org> #11146: Manual eta expansion leads to orders of magnitude less allocations -------------------------------------+------------------------------------- Reporter: niteria | 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 Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While working on deterministic free variable computation I run into some performance issues. I narrowed it down to code that when eta expanded performed less allocations. I ended up writing a benchmark and for large examples the eta expanded versions performs orders of magnitude less allocations. The results of my test: {{{ EtaExpanded test3 50,450,112 bytes allocated in the heap real 0.89 EtaReduced test3 3,661,740,240 bytes allocated in the heap real 3.66 }}} The whole source is here: https://github.com/niteria/deterministic-fvs, I'm also attaching the two interesting implementations. I experimented with it a little and GHC eta-expanded when I didn't have mutually recursive bindings. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 30 10:51:49 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Nov 2015 10:51:49 -0000 Subject: [GHC] #11146: Manual eta expansion leads to orders of magnitude less allocations In-Reply-To: <046.e20145b8e1978b205b8160f6e3f4254c@haskell.org> References: <046.e20145b8e1978b205b8160f6e3f4254c@haskell.org> Message-ID: <061.127e755fa5fe8e7842d40b783652cb74@haskell.org> #11146: Manual eta expansion leads to orders of magnitude less allocations -------------------------------------+------------------------------------- Reporter: niteria | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by niteria): * Attachment "FVCommon.hs" added. FVCommon.hs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 30 10:52:20 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Nov 2015 10:52:20 -0000 Subject: [GHC] #11146: Manual eta expansion leads to orders of magnitude less allocations In-Reply-To: <046.e20145b8e1978b205b8160f6e3f4254c@haskell.org> References: <046.e20145b8e1978b205b8160f6e3f4254c@haskell.org> Message-ID: <061.7a6105172d15fd8e297fdf51e83705f6@haskell.org> #11146: Manual eta expansion leads to orders of magnitude less allocations -------------------------------------+------------------------------------- Reporter: niteria | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by niteria): * Attachment "FV.hs" added. EtaExpanded/FV.hs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 30 10:53:06 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Nov 2015 10:53:06 -0000 Subject: [GHC] #11146: Manual eta expansion leads to orders of magnitude less allocations In-Reply-To: <046.e20145b8e1978b205b8160f6e3f4254c@haskell.org> References: <046.e20145b8e1978b205b8160f6e3f4254c@haskell.org> Message-ID: <061.03ac7d51ad56e04841ddd017693f3624@haskell.org> #11146: Manual eta expansion leads to orders of magnitude less allocations -------------------------------------+------------------------------------- Reporter: niteria | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by niteria): * Attachment "FV.2.hs" added. EtaReduced/FV.hs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 30 10:53:35 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Nov 2015 10:53:35 -0000 Subject: [GHC] #11147: Linker errors related to response files change Message-ID: <044.85d2e27846676d6e2aaab356e8c6dc01@haskell.org> #11147: Linker errors related to response files change -------------------------------------+------------------------------------- Reporter: waern | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 7.11 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: Building GHC | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hi, Building GHC HEAD in Nix on Linux currently fails with linker errors. See https://github.com/NixOS/nixpkgs/issues/10752 The problem goes away if one reverts GHC commit 296bc70b5ff6c853f2782e9ec5aa47a52110345e. I don't know what the issue is, and I can't be 100% sure it's really a GHC problem and not a Nix one, but I thought it best to record this here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 30 10:54:14 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Nov 2015 10:54:14 -0000 Subject: [GHC] #11146: Manual eta expansion leads to orders of magnitude less allocations In-Reply-To: <046.e20145b8e1978b205b8160f6e3f4254c@haskell.org> References: <046.e20145b8e1978b205b8160f6e3f4254c@haskell.org> Message-ID: <061.b33e8dfb10724c7f6754ca5ed9387b3d@haskell.org> #11146: Manual eta expansion leads to orders of magnitude less allocations -------------------------------------+------------------------------------- Reporter: niteria | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by niteria): * Attachment "Tests.hs" added. Tests.hs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 30 10:55:05 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Nov 2015 10:55:05 -0000 Subject: [GHC] #11147: Linker errors related to response files change In-Reply-To: <044.85d2e27846676d6e2aaab356e8c6dc01@haskell.org> References: <044.85d2e27846676d6e2aaab356e8c6dc01@haskell.org> Message-ID: <059.46c9fbd20bad25b0b7c437884797b6f7@haskell.org> #11147: Linker errors related to response files change ----------------------------------------+----------------------------- Reporter: waern | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+----------------------------- Changes (by waern): * cc: david.waern@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 30 11:18:21 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Nov 2015 11:18:21 -0000 Subject: [GHC] #11148: T9563 doesn't pass with reversed uniques Message-ID: <046.b847015ce18a169600f5428c8d6709c6@haskell.org> #11148: T9563 doesn't pass with reversed uniques -------------------------------------+------------------------------------- Reporter: niteria | 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 Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It fails with {{{ T9563.hs:18:1: error: ? Can't make a derived instance of ?Generic1 (G Int b Float)?: No family instance for ?G Int b Float? ? In the stand-alone deriving instance for ?Generic1 (G Int b Float)? }}} Steps to reproduce: 1. Change line `TEST_HC_OPTS = -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-$(GhcPackageDbFlag) -rtsopts $(EXTRA_HC_OPTS)` to `TEST_HC_OPTS = -dinitial-unique=16777206 -dunique-increment=-1 -fforce- recomp -dcore-lint -dcmm-lint -dno-debug-output -no- user-$(GhcPackageDbFlag) -rtsopts $(EXTRA_HC_OPTS)` in `mk/test.mk` 2. `make TESTS=T9563` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 30 11:21:09 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Nov 2015 11:21:09 -0000 Subject: [GHC] #11148: T9563 doesn't pass with reversed uniques In-Reply-To: <046.b847015ce18a169600f5428c8d6709c6@haskell.org> References: <046.b847015ce18a169600f5428c8d6709c6@haskell.org> Message-ID: <061.4f50f5e7e26459ef30452ae459a5b67b@haskell.org> #11148: T9563 doesn't pass with reversed uniques -------------------------------------+------------------------------------- Reporter: niteria | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by niteria): * cc: simonmar, simonpj (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 30 11:23:27 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Nov 2015 11:23:27 -0000 Subject: [GHC] #11146: Manual eta expansion leads to orders of magnitude less allocations In-Reply-To: <046.e20145b8e1978b205b8160f6e3f4254c@haskell.org> References: <046.e20145b8e1978b205b8160f6e3f4254c@haskell.org> Message-ID: <061.3b17d8708b58ff090802329ec1732071@haskell.org> #11146: Manual eta expansion leads to orders of magnitude less allocations -------------------------------------+------------------------------------- Reporter: niteria | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by niteria): * cc: simonmar, simonpj (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 30 11:39:53 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Nov 2015 11:39:53 -0000 Subject: [GHC] #11147: Linker errors related to response files change In-Reply-To: <044.85d2e27846676d6e2aaab356e8c6dc01@haskell.org> References: <044.85d2e27846676d6e2aaab356e8c6dc01@haskell.org> Message-ID: <059.09bc1eadd88ca7f5ece7a6e609ae1bd7@haskell.org> #11147: Linker errors related to response files change ----------------------------------------+----------------------------- Reporter: waern | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+----------------------------- Comment (by bgamari): Hmm, can you attach `config.log` from your installation attempt? I wonder whether configure is finding `librt`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 30 11:52:40 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Nov 2015 11:52:40 -0000 Subject: [GHC] #11146: Manual eta expansion leads to orders of magnitude less allocations In-Reply-To: <046.e20145b8e1978b205b8160f6e3f4254c@haskell.org> References: <046.e20145b8e1978b205b8160f6e3f4254c@haskell.org> Message-ID: <061.cb6c2a18e57e916c5dd8692545f5ef06@haskell.org> #11146: Manual eta expansion leads to orders of magnitude less allocations -------------------------------------+------------------------------------- Reporter: niteria | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Let me be cheeky: Where is the bug in the report? It is not a secret that eta-expanded definitions tend to perform better, unless you make use of sharing somewhere. So maybe you did expect the compiler to make that transformation for you? But for that to happen, the compiler needs to be very sure that it is safe to do so (e.g. no loss of sharing), and in a modular compiler, that is often not possible. Do you have a (hopefully small and self-contained) bit of code where you think ?duh, obviously the compiler should be a allowed to eta-expand here?, but it does not? Do things are better if all the relevant code is in one module, with an explicit export list that does not include any of the functions you?d like to see eta-expanded? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 30 13:38:50 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Nov 2015 13:38:50 -0000 Subject: [GHC] #11028: Refactor ConDecl In-Reply-To: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> References: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> Message-ID: <061.761dd15a22a74e908ccf8e553da2af5d@haskell.org> #11028: Refactor ConDecl -------------------------------------+------------------------------------- Reporter: simonpj | Owner: alanz 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): What is the regression? I think it's that for {{{ data W where W1 :: forall a. W }}} we get {{{ T5331.hs:11:16: Warning: Unused quantified type variable ?a? In the type `forall a. W? }}} instead of {{{ T5331.hs:11:16: Warning: Unused quantified type variable ?a? In the definition of data constructor ?W1? }}} If so, I think that's fine -- accept it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 30 13:41:10 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Nov 2015 13:41:10 -0000 Subject: [GHC] #11149: Unify fixity/associativity of <>-ish pretty-printing operators Message-ID: <042.a660c98bcc278791754b9d72890aec37@haskell.org> #11149: Unify fixity/associativity of <>-ish pretty-printing operators -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Throughout GHC's source there are related pretty-printing operators with subtly different `infixr/infixl`-declarations. It would be desirable to unify those and possibly use `Semigroup((<>))` instead (where `<>` represents a semigroup/monoid operation anyway) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 30 13:43:23 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Nov 2015 13:43:23 -0000 Subject: [GHC] #11028: Refactor ConDecl In-Reply-To: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> References: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> Message-ID: <061.7481c4a40fec15aa081c87c6eca495a9@haskell.org> #11028: Refactor ConDecl -------------------------------------+------------------------------------- Reporter: simonpj | Owner: alanz 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alanz): Ok, will do. Option 3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 30 14:01:02 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Nov 2015 14:01:02 -0000 Subject: [GHC] #11028: Refactor ConDecl In-Reply-To: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> References: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> Message-ID: <061.bd12786275f28bab163f18643f9b8a6a@haskell.org> #11028: Refactor ConDecl -------------------------------------+------------------------------------- Reporter: simonpj | Owner: alanz 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alanz): I will add this to phab for review once `wip/spj-wildcard-refactor` lands -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 30 14:29:09 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Nov 2015 14:29:09 -0000 Subject: [GHC] #11146: Manual eta expansion leads to orders of magnitude less allocations In-Reply-To: <046.e20145b8e1978b205b8160f6e3f4254c@haskell.org> References: <046.e20145b8e1978b205b8160f6e3f4254c@haskell.org> Message-ID: <061.6debd2bfff70aea4b811339fdf3e543a@haskell.org> #11146: Manual eta expansion leads to orders of magnitude less allocations -------------------------------------+------------------------------------- Reporter: niteria | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): > Where is the bug in the report? I'm not convinced this is a bug. I've created this in response to this comment: https://phabricator.haskell.org/D1537#inline-12820. > Do you have a (hopefully small and self-contained) bit of code where you think ?duh, obviously the compiler should be a allowed to eta-expand here?, but it does not? I can't tell if GHC should be allowed to eta-expand in my example, but the fact that it decided to eta-expand in a very similar situation where I didn't have mutually recursive functions suggests that it might be able to. > Do things are better if all the relevant code is in one module, with an explicit export list that does not include any of the functions you?d like to see eta-expanded? Yes, it's enough to not export the functions I want eta-expanded. Unfortunately that's exactly what I want do in Phab:D1537 because I'm composing a computation from smaller pieces from several modules. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 30 15:00:29 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Nov 2015 15:00:29 -0000 Subject: [GHC] #11149: Unify fixity/associativity of <>-ish pretty-printing operators In-Reply-To: <042.a660c98bcc278791754b9d72890aec37@haskell.org> References: <042.a660c98bcc278791754b9d72890aec37@haskell.org> Message-ID: <057.8401c94959c86c37b1bc2d9e28cc155a@haskell.org> #11149: Unify fixity/associativity of <>-ish pretty-printing operators -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by hvr: Old description: > Throughout GHC's source there are related pretty-printing operators with > subtly different `infixr/infixl`-declarations. > > It would be desirable to unify those and possibly use `Semigroup((<>))` > instead (where `<>` represents a semigroup/monoid operation anyway) New description: Throughout GHC's source there are related pretty-printing operators with subtly different `infixr/infixl`-declarations. It would be desirable to unify those and possibly use `Semigroup((<>))` instead (where `<>` represents a semigroup/monoid operation anyway) Otoh, existing code using `<>` assumes a different fixity, so it may make sense to start by renaming the unconventional `<>`s into something else. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 30 15:02:03 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Nov 2015 15:02:03 -0000 Subject: [GHC] #11149: Unify fixity/associativity of <>-ish pretty-printing operators In-Reply-To: <042.a660c98bcc278791754b9d72890aec37@haskell.org> References: <042.a660c98bcc278791754b9d72890aec37@haskell.org> Message-ID: <057.2e94717dee91405b6e93a8ec8c338528@haskell.org> #11149: Unify fixity/associativity of <>-ish pretty-printing operators -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by hvr: Old description: > Throughout GHC's source there are related pretty-printing operators with > subtly different `infixr/infixl`-declarations. > > It would be desirable to unify those and possibly use `Semigroup((<>))` > instead (where `<>` represents a semigroup/monoid operation anyway) > > Otoh, existing code using `<>` assumes a different fixity, so it may make > sense to start by renaming the unconventional `<>`s into something else. New description: This ticket is motivated by GHC's new `-fwarn-semigroup`, and that `<>` is moving into `Prelude` with future GHCs. Throughout GHC's source there are related pretty-printing operators with subtly different `infixr/infixl`-declarations. It would be desirable to unify those and possibly use `Semigroup((<>))` instead (where `<>` represents a semigroup/monoid operation anyway) Otoh, existing code using `<>` assumes a different fixity, so it may make sense to start by renaming the unconventional `<>`s into something else. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 30 15:09:54 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Nov 2015 15:09:54 -0000 Subject: [GHC] #11149: Unify fixity/associativity of <>-ish pretty-printing operators In-Reply-To: <042.a660c98bcc278791754b9d72890aec37@haskell.org> References: <042.a660c98bcc278791754b9d72890aec37@haskell.org> Message-ID: <057.e797aee5fab48767f9548fe0ce4fb6f7@haskell.org> #11149: Unify fixity/associativity of <>-ish pretty-printing operators -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by hvr: Old description: > This ticket is motivated by GHC's new `-fwarn-semigroup`, and that `<>` > is moving into `Prelude` with future GHCs. > > Throughout GHC's source there are related pretty-printing operators with > subtly different `infixr/infixl`-declarations. > > It would be desirable to unify those and possibly use `Semigroup((<>))` > instead (where `<>` represents a semigroup/monoid operation anyway) > > Otoh, existing code using `<>` assumes a different fixity, so it may make > sense to start by renaming the unconventional `<>`s into something else. New description: This ticket is motivated by GHC's new `-fwarn-semigroup`, and that `<>` is moving into `Prelude` with future GHCs. Throughout GHC's source there are related pretty-printing operators with subtly different `infixr/infixl`-declarations. It would be desirable to unify those and possibly use `Semigroup((<>))` instead (where `<>` represents a semigroup/monoid operation anyway) Otoh, existing code using `<>` assumes a different fixity, so it may make sense to start by renaming the unconventional `<>`s into something else. Modules affected: - `Outputable` (ghc) - `Pretty` (ghc) - `Language.Haskell.TH.PprLib` (template-haskell) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 30 15:20:45 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Nov 2015 15:20:45 -0000 Subject: [GHC] #11146: Manual eta expansion leads to orders of magnitude less allocations In-Reply-To: <046.e20145b8e1978b205b8160f6e3f4254c@haskell.org> References: <046.e20145b8e1978b205b8160f6e3f4254c@haskell.org> Message-ID: <061.146259649128105b8834ed6cc5d88da3@haskell.org> #11146: Manual eta expansion leads to orders of magnitude less allocations -------------------------------------+------------------------------------- Reporter: niteria | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Could you also add `Types.hs`? It's used in all of the modules you added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 30 15:31:33 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Nov 2015 15:31:33 -0000 Subject: [GHC] #11146: Manual eta expansion leads to orders of magnitude less allocations In-Reply-To: <046.e20145b8e1978b205b8160f6e3f4254c@haskell.org> References: <046.e20145b8e1978b205b8160f6e3f4254c@haskell.org> Message-ID: <061.7c8b1cf05ec6e7ab831df4b76297a31c@haskell.org> #11146: Manual eta expansion leads to orders of magnitude less allocations -------------------------------------+------------------------------------- Reporter: niteria | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by niteria): * Attachment "Types.hs" added. Types.hs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 30 16:05:48 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Nov 2015 16:05:48 -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.e1fc9215c706f27a185d1d108e1fddc1@haskell.org> #10902: Refactor type families in Template Haskell -------------------------------------+------------------------------------- Reporter: goldfire | Owner: johnleo 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by johnleo): Sure, `TypeFamilyHead` is fine. I wasn't sure what the standard GHC convention is, and "base" would be more typical for a "base type". Is "type family head" mentioned somewhere in other source code or documentation? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 30 16:30:49 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Nov 2015 16:30:49 -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.69f9b8e9bf828be2bf29b5a5505f2996@haskell.org> #10726: Upgrade MingW-w64 distributions for windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: task | Status: patch Priority: high | Milestone: 8.0.1 Component: Build System | Version: 7.11 Resolution: | 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 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): D'oh, you're right, I forgot about `-D__USE_FFI__`. Running `ghc-stage2 --interactive -D__USE_FFI__ -isrc src/Data/Number/LogFloat.hs` does indeed trigger the same error. Another curiosity: I rebuilt GHC with the following change: {{{#!patch diff --git a/rts/RtsSymbols.c b/rts/RtsSymbols.c index 8413d31..31b190e 100644 --- a/rts/RtsSymbols.c +++ b/rts/RtsSymbols.c @@ -123,6 +123,8 @@ SymI_HasProto(isalnum) \ SymI_HasProto(isascii) \ RTS___MINGW_VFPRINTF_SYM \ + SymI_HasProto(log1p) \ + SymI_HasProto(expm1) \ SymI_HasProto(strcmp) \ SymI_HasProto(memmove) \ SymI_HasProto(realloc) \ }}} And still experienced the same `unknown symbol log1p` error as before. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 30 17:05:52 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Nov 2015 17:05:52 -0000 Subject: [GHC] #11123: Arm: checkProddableBlock: invalid fixup in runtime linker In-Reply-To: <044.92e8587d5182968d745cf903b273dfec@haskell.org> References: <044.92e8587d5182968d745cf903b273dfec@haskell.org> Message-ID: <059.4edac3667fe165939dfa829bd43ed1ea@haskell.org> #11123: Arm: checkProddableBlock: invalid fixup in runtime linker ----------------------------------------+----------------------------- 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: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+----------------------------- Comment (by hsyl20): Isn't it fixed with Phab:D1470? In master, the proddable block is wrong when we copy the section: {{{ 4799: addProddableBlock(oc, ehdrC + offset, size); }}} should be {{{ 4799: addProddableBlock(oc, start, size); }}} Maybe this would be enough to solve the issue. (If it does, I don't see why we only have it on ARM though). As for "other" sections (cf comment:3), they are skipped during the relocation, so I guess the failing relocation is not for the 2 sections we see in the last part of the log in comment:2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 30 17:38:49 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Nov 2015 17:38:49 -0000 Subject: [GHC] #2940: Do CSE after CorePrep In-Reply-To: <046.ba154de3cf0c400fb0723e1948282304@haskell.org> References: <046.ba154de3cf0c400fb0723e1948282304@haskell.org> Message-ID: <061.797dc17b1d29e1358e2a36f664cf46f2@haskell.org> #2940: Do CSE after CorePrep -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: lowest | Milestone: 8.0.1 Component: Compiler | Version: 6.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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): See [wiki:MoreCSE]. I'm inclined to think that it'd be better to do CSE ''earlier'' not ''later''. The main idea (on the [wiki:MoreCSE] page) is this: * Make float-out more aggressive by (a) let-binding every sub-expression, and (b) floating let-bindings out even if they don't escape a lambda. So in your first example {{{ g x = (x + 1, x + 1) }}} we'd get {{{ g x = let v1 = x+1 in let v2 = x+2 in (v1,v2) }}} * Now do CSE as now. The extra let-bindings should give a lot more more opportunities. * Float inwards to reverse the effect of the first pass if CSE did not bite. Also talk to Joachim who wrote [wiki:MoreCSE]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 30 18:00:36 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Nov 2015 18:00:36 -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.9baec7dc6da1f67a8ac93473bd8668f5@haskell.org> #10902: Refactor type families in Template Haskell -------------------------------------+------------------------------------- Reporter: goldfire | Owner: johnleo 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jstolarek): > Is "type family head" mentioned somewhere in other source code or documentation? Yes, I think it's a commonly used term. For example, you can take a look at [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/type- families.html type family section in the User's Guide]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 30 18:28:35 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Nov 2015 18:28:35 -0000 Subject: [GHC] #11135: Migrate more of Data.Functor.* from transformers to base. In-Reply-To: <042.83233f22e5175dafd0dee94fc12c4d5f@haskell.org> References: <042.83233f22e5175dafd0dee94fc12c4d5f@haskell.org> Message-ID: <057.94c95be96b3cdd5f716230e222761898@haskell.org> #11135: Migrate more of Data.Functor.* from transformers to base. -------------------------------------+------------------------------------- Reporter: hvr | Owner: strake888 Type: task | Status: patch Priority: highest | Milestone: 8.0.1 Component: libraries/base | 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:D1543 Wiki Page: | Phab:D1544 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D1543 Phab:D1544 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 30 19:32:22 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Nov 2015 19:32:22 -0000 Subject: [GHC] #11146: Manual eta expansion leads to orders of magnitude less allocations In-Reply-To: <046.e20145b8e1978b205b8160f6e3f4254c@haskell.org> References: <046.e20145b8e1978b205b8160f6e3f4254c@haskell.org> Message-ID: <061.794e40852fdff7e75ee895b28a8805d4@haskell.org> #11146: Manual eta expansion leads to orders of magnitude less allocations -------------------------------------+------------------------------------- Reporter: niteria | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): > Yes, it's enough to not export the functions I want eta-expanded. Unfortunately that's exactly what I want do in ?Phab:D1537 because I'm composing a computation from smaller pieces from several modules. Then GHC (likely Call Arity \o/) seems to be smart enough to do the expansion if it is allowed to operate on the whole code at once, as desired. But with the code spread over several modules, there isn?t really much GHC can do here. You could try to make it `INLINE` more aggressively, or simply do the eta-expansion as you do now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 30 19:42:36 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Nov 2015 19:42:36 -0000 Subject: [GHC] #2940: Do CSE after CorePrep In-Reply-To: <046.ba154de3cf0c400fb0723e1948282304@haskell.org> References: <046.ba154de3cf0c400fb0723e1948282304@haskell.org> Message-ID: <061.a7df77018c2d0d730a495d90716b65d2@haskell.org> #2940: Do CSE after CorePrep -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: lowest | Milestone: 8.0.1 Component: Compiler | Version: 6.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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): I did? Oh dear. It must have been before I started to dislike CSE very much, because it gets in the way of rules, and can creasing sharing (e.g. by cse?ing `[0..1000]`). Or maybe it was precisely when I startd to dislike CSE... :-) Speaking about the phases CSE should happen: I very much believe we need a CSE phase as an Stg-to-Stg-transformation, to avoid reallocating `Left`s in the code for a `Either`?s `fmap`, for example. (There is a ticket for this, cannot find it right now.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 30 19:53:59 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Nov 2015 19:53:59 -0000 Subject: [GHC] #11127: Update cabal submodule to 1.22.5 In-Reply-To: <045.b86ccf3972e67654868d36d88f8530d9@haskell.org> References: <045.b86ccf3972e67654868d36d88f8530d9@haskell.org> Message-ID: <060.6285e8fcb8af736de6387cbf722452fd@haskell.org> #11127: Update cabal submodule to 1.22.5 -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Type: task | Status: closed Priority: high | Milestone: 7.10.3 Component: libraries | Version: (other) | Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => wontfix Comment: I asked Mikhail and then Ryan to tag a release last week. Sadly this still hasn't happened and I really can't afford to push 7.10.3 off any farther given the proximity of 8.0. Sorry Luke, I'm afraid I won't be able to fulfill this request. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 30 19:57:11 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Nov 2015 19:57:11 -0000 Subject: [GHC] #11127: Update cabal submodule to 1.22.5 In-Reply-To: <045.b86ccf3972e67654868d36d88f8530d9@haskell.org> References: <045.b86ccf3972e67654868d36d88f8530d9@haskell.org> Message-ID: <060.fa7225872bcaf123825860f770531ce8@haskell.org> #11127: Update cabal submodule to 1.22.5 -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Type: task | Status: closed Priority: high | Milestone: 7.10.3 Component: libraries | Version: (other) | Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by refold): I've just got a mail from Ryan and he says that he'll do a release today. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 30 20:25:32 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Nov 2015 20:25:32 -0000 Subject: [GHC] #2940: Do CSE after CorePrep In-Reply-To: <046.ba154de3cf0c400fb0723e1948282304@haskell.org> References: <046.ba154de3cf0c400fb0723e1948282304@haskell.org> Message-ID: <061.e0612e63448cba0a8c7cfd4bcd956306@haskell.org> #2940: Do CSE after CorePrep -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: lowest | Milestone: 8.0.1 Component: Compiler | Version: 6.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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Why do we need to do CSE in STG level to avoid allocation in `Either`s `fmap`? What does STG give us extra over Core? Do you mean not having type terms help? If so, how? {{{#!haskell -- RHS size: {terms: 14, types: 17, coercions: 0} Main.$fFunctorEither1_$cfmap :: forall a_aOH a1_avU b_avV. (a1_avU -> b_avV) -> Either1 a_aOH a1_avU -> Either1 a_aOH b_avV Main.$fFunctorEither1_$cfmap = \ (@ a_aOH) (@ a1_aOL) (@ b_aOM) (ds_dR3 :: a1_aOL -> b_aOM) (ds1_dR4 :: Either1 a_aOH a1_aOL) -> case ds1_dR4 of _ { Left1 x_avi -> Main.Left1 @ a_aOH @ b_aOM x_avi; Right1 y_avk -> Main.Right1 @ a_aOH @ b_aOM (ds_dR3 y_avk) } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 30 21:49:09 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Nov 2015 21:49:09 -0000 Subject: [GHC] #11123: Arm: checkProddableBlock: invalid fixup in runtime linker In-Reply-To: <044.92e8587d5182968d745cf903b273dfec@haskell.org> References: <044.92e8587d5182968d745cf903b273dfec@haskell.org> Message-ID: <059.7eb4438dd030ede97a4f4f288329fb39@haskell.org> #11123: Arm: checkProddableBlock: invalid fixup in runtime linker ----------------------------------------+----------------------------- 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: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+----------------------------- Comment (by erikd): I just applied Phab:D1470 and built it on my Arm board. I am no longger getting a problem with `checkProddableBlock` but I am getting a large amount of errors like: {{{ ghc-stage2: Symbol `exp' requires Thumb linkage which is not currently supported. ghc-stage2: Symbol `log' requires Thumb linkage which is not currently supported. ghc-stage2: Symbol `sin' requires Thumb linkage which is not currently supported. }}} for symbols in libc. This is completely un-related to Phab:D1470. It looks like the libc on this machine switched from Arm linkage to Thumb linkage during a recent upgrade. @bgamari any clues? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 30 21:56:51 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Nov 2015 21:56:51 -0000 Subject: [GHC] #11127: Update cabal submodule to 1.22.5 In-Reply-To: <045.b86ccf3972e67654868d36d88f8530d9@haskell.org> References: <045.b86ccf3972e67654868d36d88f8530d9@haskell.org> Message-ID: <060.09b12a5d307d75add72bbc336ad85284@haskell.org> #11127: Update cabal submodule to 1.22.5 -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Type: task | Status: new Priority: high | Milestone: 7.10.3 Component: libraries | Version: (other) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by refold): * status: closed => new * resolution: wontfix => Comment: Cabal-1.22.5.0 has just been released. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 30 22:12:05 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Nov 2015 22:12:05 -0000 Subject: [GHC] #2940: Do CSE after CorePrep In-Reply-To: <046.ba154de3cf0c400fb0723e1948282304@haskell.org> References: <046.ba154de3cf0c400fb0723e1948282304@haskell.org> Message-ID: <061.01732ac42f7052addf56ddc229b4a347@haskell.org> #2940: Do CSE after CorePrep -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: lowest | Milestone: 8.0.1 Component: Compiler | Version: 6.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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Quite right. If one of us can now find the corresponding ticket, then we can continue there, and not hijack the discussion here :-)... there it is: #9291. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 30 22:27:14 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Nov 2015 22:27:14 -0000 Subject: [GHC] #11123: Arm: checkProddableBlock: invalid fixup in runtime linker In-Reply-To: <044.92e8587d5182968d745cf903b273dfec@haskell.org> References: <044.92e8587d5182968d745cf903b273dfec@haskell.org> Message-ID: <059.8071bbbd4c2d7001855c862649677e9f@haskell.org> #11123: Arm: checkProddableBlock: invalid fixup in runtime linker ----------------------------------------+----------------------------- 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: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+----------------------------- Comment (by erikd): Disassembling libm using `objdump -D /lib/arm-linux- gnueabihf/libm-2.19.so` shows that the `sin` function is indeed Thumb code (indicated by instruction offsets that are not a multiple of 2): {{{ 00015850 : 15850: b570 push {r4, r5, r6, lr} 15852: ed2d 8b0e vpush {d8-d14} 15856: b08a sub sp, #40 ; 0x28 15858: eeb0 8b40 vmov.f64 d8, d0 1585c: ac01 add r4, sp, #4 1585e: 4620 mov r0, r4 15860: f7f0 fd48 bl 62f4 ... }}} This problem is encountered when ghci loads a Haskell module which calls maths functions in `libm`. {{{ Loading package ghc-prim-0.5.0.0 ... linking ... ghc-stage2: Symbol `__aeabi_idiv' requires Thumb linkage which is not currently supported. }}} However on IRC, @rwbarton suggests: {{{ .... the rts linker should use its own copy of sin to satisfy a use in a .o file }}} so maybe this is still a bug in Phab:D1470. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 30 22:45:20 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Nov 2015 22:45:20 -0000 Subject: [GHC] #9291: Don't reconstruct sum types if the type subtly changes In-Reply-To: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> References: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> Message-ID: <061.0f0833b9c23b4d6257a5926f40a4f4ee@haskell.org> #9291: Don't reconstruct sum types if the type subtly changes -------------------------------------+------------------------------------- Reporter: schyler | Owner: Type: feature request | 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * cc: osa1 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 30 22:45:56 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Nov 2015 22:45:56 -0000 Subject: [GHC] #7596: Opportunity to improve CSE In-Reply-To: <046.cff0215a26be1de4993e285f1d4ab495@haskell.org> References: <046.cff0215a26be1de4993e285f1d4ab495@haskell.org> Message-ID: <061.7aee28fcb26a5f850ed4b534beb4cd49@haskell.org> #7596: Opportunity to improve CSE -------------------------------------+------------------------------------- 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: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * cc: osa1 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 30 22:48:57 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Nov 2015 22:48:57 -0000 Subject: [GHC] #11146: Manual eta expansion leads to orders of magnitude less allocations In-Reply-To: <046.e20145b8e1978b205b8160f6e3f4254c@haskell.org> References: <046.e20145b8e1978b205b8160f6e3f4254c@haskell.org> Message-ID: <061.5d751d1eea6342135b1ef5c717a860c0@haskell.org> #11146: Manual eta expansion leads to orders of magnitude less allocations -------------------------------------+------------------------------------- Reporter: niteria | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I just tried `INLINE`ing all the functions defined in `FV` and `FV2`, it didn't make any difference. (maybe because GHC was already inlining?) (tried with -O2) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 30 22:49:02 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Nov 2015 22:49:02 -0000 Subject: [GHC] #11146: Manual eta expansion leads to orders of magnitude less allocations In-Reply-To: <046.e20145b8e1978b205b8160f6e3f4254c@haskell.org> References: <046.e20145b8e1978b205b8160f6e3f4254c@haskell.org> Message-ID: <061.641dfa00bb486bba6175ec750bafee4c@haskell.org> #11146: Manual eta expansion leads to orders of magnitude less allocations -------------------------------------+------------------------------------- Reporter: niteria | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * cc: osa1 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler